ozpost shipping module

[RodG]

Hi RodG,
Thanks for quick fixed. Normal packaging seem to be fine now... but there are still problem when package need to be split up.

Sorry, but this is pretty much where this thread ends. I'm not going to go into my usual tirade about the holy grail of shipping/packaging modules, but I will emphasise that *I* have personally spent 100's of hours looking into it before coming to the conclusion that it is way beyond my capabilities, and as such, *ozpost* does not support parcel splitting in any way, shape or form.

However, due to a percieved or potential consumer demand I have added the toggle to use the zencart weight system for quotes rather than the ozpost system.

The zencart weight system *does* support parcel splitting, and the ozpost module doesn't know/care how this is performed, all it does is take the data supplied by the zencart core code, which would typically be something like 2 x 15kg parcels - with NO DIMENSIONS, so the ozpost module does the best quote it can with this information, namely, it gets the price of one parcel of minimal dimensions at the given weight, then multiplies it by the number of parcels.

In other words, problems and/or inaccuracies introduced by allowing the module to use data from a source other than its own is outside of the realm of anything that I can possibly fix.

total 30kgs and as fastway only allows 25kgs each package, what I done is i sent max package weight to 25kg in admin>configuration>shipping/packaging. and set yes in ozpost modules to allows split package.

I would assume that in this case, the quote being asked for would be 2x 15kg parcels (even though this may not be practically possible). Again, you are on your own here.... Strictly speaking this needs to be taken care of by the zencart team, but they are also aware of the complexities of parcel splitting, which is probably why we'll never see much more than is alreadfy provided for.

As I say, I have personally given up seeking the holy grail of packing modules

when I do estimate shipping, it shows 2 red label + 3 savers (used to show 6 savers). (I am not sure if + 3 saver mean 3 saver for each red label or just 3 for both... if 3 for each then total of 6 label) (which I believe it should be 4, max of 5 depends how item is split), but even 2 red + 3 saver label it shows price of $93.40!!

and I believe 2 red label plus 6 savers should only be $47.20 in total.

The (I assume) would have been for 2 identical, so if it shows
2 red label + 3 savers that will be per parcel. The price shown would be the calculated price, times 2. eg, if the red labels are $2.00 and the savers are $1.00, the quoted cost would be ((2x2.00)+(3x1.00)) x 2 = $14.00

Please have a look at calculation when package is split.. thanks

Seriously no. I really do wash my hands when it comes to parcel splitting and the problems thereof. Too many hours have been wasted already.

I remembered I used to test before and it was fine.

Before what, I don't know.

Sorry if I'm less than helpful on this one, but the toggle to switch between the 'ozpost' method of weights/dimensions, or to use internal methods has been added so that end users can select which of the two imperfect methods is going to be the most suitable for them. If neither are suitable, then perhaps a different method/module entirely would be more suited?

Knowing that perfect isn't possible, my personal preference is to simply let the parcels 'grow' until valid quotes aren't possible, at which time I have it quote on a cost per Kg basis. This won't work with all stores though.

Also, I'm not suggesting this is the case with you, but many people will intentionally add products/items to the cart with the intent of seeing if it can be 'broken'... I can state right now that yes, it can be very easy to add products that will cause certain limits to be exceeded or quotes fail for one reason or another, in fact for the number of things that can go 'wrong' it is almost a surprise it ever works at all <g> ... However, having said that, the important thing is how does it perform with real world orders?

Unless going on a mad shopping spree I rarely ever order more than one or two items from a store at any given time, and I don't think I'm the exception to the rule either - So what I'm saying here is that some percieved and potential problems rarely occur in a real world scenario anyway, and this is one case where it pays to not delve too deeply into it, lest you get caught in the same time wasting traps that I did.

Cheers
Rod

[ks_b]

Hi RodG

ok don't worry about package splitting... I do some more test and there is still problem with saver label calculation

I show correct number of saver label but the calculation is wrong.

1st saver label is correct, extra $3.80
2nd saver label is wrong, (charged $11.60 for the label) when it should be another $3.80
3rd saver label is wrong (charged $19.20 for the label) when it should be another $3.80
4th saver label is wrong (charged $27 for the last label) it should be $3.80

This is what the system calculated:
red label only = $12.10 (correct)
red label + 1 saver label = $15.90 (correct $12.10 + $3.80)
red label + 2 saver label = $27.50 (wrong! should be $12.10 + $3.80 + $3.80 = $19.70)
red label + 3 saver label = $46.70 (wrong, should be $12.10 +$3.80 + $3.80 + $3.80 = $23.50)
red label + 4 saver label = $73.70 (wrong, should be $12.10 + $3.80 + $3.80 + $3.80 + $3.80 = $27.30)

from the pattern look like it double the number saver label in calculation.

you can test with my site using this product
http://www.mybeershop.com.au/index.p...products_id=96

and send to postcode 2560
which is red label and 2 saver.

I think this is also the problem that cause the incorrect calculation of package splitting as well. That's why the price is way off....

Thanks

[RodG]

ok don't worry about package splitting... I do some more test and there is still problem with saver label calculation

I show correct number of saver label but the calculation is wrong.

Thanks for your patience and perseverance... Hopefully I got it fixed right this time (curse mutter, mutter)..

Please note that the figures don't match exactly due to the way the ozpost module rounds up to the nearest 10cents.

If problems persist (that are unrelated to parcel splitting) please don't hesitate to keep reporting them, because there really are so few of us using the module (dozens, not hundreds or 1000's) and as such we can't rely on others to report issues... I've really no idea how long Fastway was broken before you mentioned the problem).

Cheers
Rod

[ks_b]

Thank you for quick fix!

and I found one or two problems again...sorry if I am a pain, but I am not sure if you can fix this one...but I really hope you can!!

problem is with black label, when customer are in black label area, ozpost only quote as brown label price. I can see that it doing this because fastway calculation page shows black,brown, blue, yellow together and only show cheapest and highest price. and ozpost just extract info from fastway page right?

Same as satchel size A3 and A2... it doesn't pick up the weight which A3=3kg and A2=5kg....

is my understanding correct? and can this be fix? or its only can be fix if fastway actually show exact price etc?

Other than this everything else seem to work fine now even if package need to be split...

thanks

[RodG]

and I found one or two problems again...sorry if I am a pain,

Reporting problems isn't being a pain. It is the only way things will get fixed :-)

but I am not sure if you can fix this one...but I really hope you can!!

I'm not sure I can either.

problem is with black label, when customer are in black label area, ozpost only quote as brown label price.

This may sound a bit odd, but I really don't know one FastWay label from another.

I can see that it doing this because fastway calculation page shows black,brown, blue, yellow together and only show cheapest and highest price. and ozpost just extract info from fastway page right?

Correct.

Same as satchel size A3 and A2... it doesn't pick up the weight which A3=3kg and A2=5kg....
is my understanding correct?

Also correct, but, in the case of satchels, the ozpost server does its own checks to ensure the items is satchel suitable (and for which size satchel).

Without these additional checks ozpost would quote for satchels even when not suitable, as the FastWay page does.

and can this be fix? or its only can be fix if fastway actually show exact price etc?

Tough question, because as I say, the Fastway Labels don't really mean much to me, so I tend to work with the information provided, which as you have noted, only shows the cheapest and highest prices. My *assumption* (based on educated guesses from the FastWay price list(s), is that for any given source/destination there is only one option (or suitable label colour) and the price range are for normal users vs regular users. Up until now no one has suggested or implied that this is incorrect, or that there are other options that I'm not familiar with, so, if possible, if you could treat me like a moron for a little bit and detail exactly what it is you want need it to do, along with any possible suggestions on how to achieve it, I'd be more than happy to see what can be done externally and/or in addition to the results obtained from the FastWay servers.

Other than this everything else seem to work fine now even if package need to be split...
thanks

I still don't wish to discuss this ... it gives me nightmares...

Cheers
Rod

[ks_b]

sure I can tell you how fastway work with labels. If you look at this page here it quite straight forwards.

http://www.fastway.com.au/RFRatesPDF/1/RS-MEL[Mar10]_web.swf

so each colour represent different destination. most of labels is quote correctly on ozpost because they one destination represent only one colour with 2 price which is frequent and non frequent as you understand.

the problem ozpost having is the local delivery because it has 4 different colours (blue, yellow, black, brown) (that's why fastway calculation page show them all together) and each colour represent how often the user use fastway in a month. hint the more you use the cheaper it get.

if you looks at melbourne for example if you use min of 200 each month then you only have to pay $4.02 each label, min 100 then $5.61 and so on...

Suggestion...
I think only way you can do this is you have to put in the price of each label manually, I can see this is not too difficult as in ozpost user can select what label they want to use.... therefore if user select blue then they should have brown, black, yellow turned off and when fastway return (blue/yellow/black/brown) you can then check which colour option user selected and use that price.

Now the hard part is that different local has different prices... so to make ozpost work perfectly, you probably have to input all the price for different location.. you can look number of location here http://www.fastway.com.au/1Prices.html
good news is black and brown for all the location is the same price.
and blue is always quote correctly because it's the price for non frequent user.
only problem is yellow which I think you can just average it and it should be really close enough for all ozpost customer to be happy :)

I will need to do abit more research with satchel and i will let you know.

Hope this help.

[jazzah]

Assuming you are using a current version (v2.0.5 or V2.0.6) and don't mind modifying code. locate the file /includes/modules/shipiing/ozpost.php

Then using a text editor, locate the following lines:

case  "FWL";
                if(in_array("FastWay Labels", $this->allowed_methods)) $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
            break;

   case "FWS":
                if(in_array("FastWay Satchel", $this->allowed_methods))  $handlingFee = MODULE_SHIPPING_OZPOST_FWS_HANDLING ;
            break;

The modify or replace them with:

case  "FWL";
                if(in_array("FastWay Labels", $this->allowed_methods))  { 
                $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
                $quote->days = $quote->days + 1 ;
                }
            break;

   case "FWS":
                if(in_array("FastWay Satchel", $this->allowed_methods)) { 
                $handlingFee = MODULE_SHIPPING_OZPOST_FWS_HANDLING ;
                $quote->days = $quote->days + 1 ;
                }
            break;

Don't forget to make a backup of the file first, so if it goes wrong you won't find yourself stuck... just revert to the backup.

Cheers
Rod

Mmm now that I have upgraded this code doesn't work! I have had a bit of a hack at at and truly I mean hack and had no success!

Cheers
Jazzah

[ks_b]

Hi RodG,

are you still making changes to FastWay... for some reason, ozpost calculate number of fastway saver label wrong again.

12kg package should only use 2 saver labels but ozpost display 3 and also calculated price as 3 saver label.

Weight 12000gms Items 1 Weight 12600gms
Dimensions 77.00 x 44.00 x 23.00 77.00 x 44.00 x 23
Cube / Weight 77924cc / 19.481Kgs 77924cc / 19.481Kgs
Submitted: Length=77.00cm, Width=44.00cm, Height=23.00cm, Weight=12000gms, NumBoxes=1
Server response time 0.726ms
Server Returned:
FWL19.40Wed 24th of NovFastWay Labels (RED +3 Saver labels)

From debug info make assumption that it using cube/weight instead of normal weight?? But normally it didn't though...

regards,

[RodG]

the problem ozpost having is the local delivery because it has 4 different colours (blue, yellow, black, brown) (that's why fastway calculation page show them all together) and each colour represent how often the user use fastway in a month. hint the more you use the cheaper it get.

if you looks at melbourne for example if you use min of 200 each month then you only have to pay $4.02 each label, min 100 then $5.61 and so on...

OK, this makes sense, but is cerainly doesn't make it *easy* because there is no way to know what price any particular merchant is on (TNT overcome this by requiring an account number to be passed along with the other parameters so that 'personalised' quotes can be given).

Suggestion...
I think only way you can do this is you have to put in the price of each label manually,

Hmmm, wouldn't this need to be done by the merchant? (How would I make the code 'know' what each merchant pays for thier labels?)

I can see this is not too difficult as in ozpost user can select what label they want to use.... therefore if user select blue then they should have brown, black, yellow turned off and when fastway return (blue/yellow/black/brown) you can then check which colour option user selected and use that price.

The downside to this proposal is that it is tossing the maintenance back to the client in that they'll need to ensure their label prices are kept accurate, and one of the principles behind ozpost is that the merchant shouldn't need to worry themselves about price changes, as it is supposed to be handled by the server.

Now the hard part is that different local has different prices... so to make ozpost work perfectly, you probably have to input all the price for different location.. you can look number of location here http://www.fastway.com.au/1Prices.html

Although this is possible (and I would suggest, in time, even probably the way to go, as it would make us independent of the FastWay server). At this stage though I think it is going to take a lot more work rto do this than the project deserves.

good news is black and brown for all the location is the same price.
and blue is always quote correctly because it's the price for non frequent user.
only problem is yellow which I think you can just average it and it should be really close enough for all ozpost customer to be happy :)

I will need to do abit more research with satchel and i will let you know.

Hope this help.

It has helped in as much as confirming what I had expected, and that is, to take care of the issue I pretty much need to scrap using the FastWay servers and create/use our own table rate instead... At least that is what *I* have picked up from your suggestion (If I'm wrong, please try again).

I was hoping for some way to take care of the issue by utilising the data that is readily available from the FastWay servers, and then modifying it in some way to compensate for the shortcomings..

One thing I might suggest is that you use the "Frequent user" option with care because this will always return the lowest quote that it can. I am of the opinion that a merchant should charge the customer non frequent user prices anyway... if a merchant has earned price reductions for any reason they aren't really obligated to pass the savings on. The end consumer may not even know.

One last question... with the Erronious FastWay quote/options - are they in favour of the merchant of the customer? If the merchant, then perhaps we can ignore the problem... if it is underquoting though I will do almost anything I need to in order to prevent this from occuring.

Cheers
Rod

[RodG]

Hi RodG,
are you still making changes to FastWay...

Not since last night.

From debug info make assumption that it using cube/weight instead of normal weight?? But normally it didn't though...

This assumption is correct... it quotes on the cubic weight, not the deadweight. (I discovered the dimension data being sent to FastWay was being ignored) so for accuracy, It is now fed the cubed data (where applicable)

Cheers
Rod