ozpost shipping module

[RodG]

ok, so i too (well not really me, more the client who owns the site!) am having fits over the fact there's no parcel splitting,

I'm sure that both of you will have even bigger fits when you find the parcel splitting methods being used are prone to splitting parcels in impossible ways.

For example, Item #1 weighs 19Kgs, Item#2 weighs 2kgs.
Quote returned is for two parcels weighing 10.5kgs each, which is a significant difference in cost compared to actual postage cost.

It is better to not have a quote at all, than be given an inaccurate quote (in my opinion).

and i'm curious what i should look out for if i revert back to the old aust post mod, assuming there is a) little to no support for it,

As well as the problem mentioned above, using the older module no longer has the capability to quote using anything with a 'fixed price', this includes the use of pre-paid satchels, and anything relating to registration and insurance costs.

and b) there were good reason for rewriting the new mod.

There were several reasons for writing a new mod. One of the prime reasons was to reduce (and eventually eliminate) the dependance on the drc.edeliver servers.

Other reasons included modifying the server code so that it returns shipping *options* instead of a single quote for each method supplied to it. (Makes things many times more efficient for shopping cart use).

The use of XML means that the server can be more easily used by other ecommerce stores, not to mention simplied processing on the client side.

In short, the rewrite of the client code (the zencart module) is/was to bring it in line with the new server features.

is it really wise for me to revert back to this old mod simply to split parcels (in your opinion of course)?

I would have to say no, primarily based on the first point I made, the parcel splitting is prone to producing inaccurate quotes.

my only other alternative presently seems to be to add another shipping option, however as my clients place of business is right next door to an australia post outlet, they're very reluctant to use anything else :)

An alternate shipping option is probably a good idea, even if only made active if the ozpost module is unable to provide a valid quote (for any reason).

Another option, would be to take advantage of the ozpost 'flat rate' fallback setting. Admittedly this is far from perfect, but depending on how often the oversize/overweight scenario exists with your client and the products being sold, it should be possible to come up with a 'flat rate' price that doesn't send your client broke by being consistantly too low, and at the same time isn't so high that it'll scare potential customers away. Always being mindful that this 'flat rate' quote will only come into effect if the parcel size/weight is going to be too large for Australia Post to accept in the first place.

Cheers
Rod

[RodG]

one more question i guess; if "downgrading", should i uninstall the old module first? install notes on the old module say this is wise when upgrading, not sure about the reverse.
any other important tips? sorry if i'm asking a bit much now, very tight deadline : )

cheers
andy

The older "AustPost - improved" module and the new "ozpost" module can be (and are) completely separate/different modules. Both can be installed (and even active) at the same time. (This may cause a bit of confusion to the customers though).

Cheers
Rod

[ALiepinieks]

wow, thanks for the very comprehensive reply. i have decided not to use the old module, predominantly for the reasons you suggested (invalid quotes)

i in fact just got back from this client and we had a very long discussion about the whole situation. we are investigating 2 options which i put forward to him, wanted to know if you had any comments on either (assuming you have the time to comment!). i quite understand neither may in fact be viable once we embark on the research:

1) take the smaller items (such as essence bottles which are only 10cm x 3cm x 3cm in width) and divide the smallest measurement by a factor, multiplying the next smallest measurement by the same factor, and using this as the actual dimension. in this example, any order over 35 units would exceed AP's max length (3 x 35 = 105cm), however by adjusting the measurments to ensure the same cubic weight is returned but with one measurement much lower, more items can be squeezd into a box, somewhat akin to stacking the items 3 dimensionally. his argument is that a box should be able to hold at least 100 units (around 12.5kg), which he sends via australia post from time to time no problems. by making the dimensions (say) 10cm x 1cm x 9cm, we in fact return a more accurate quote based on real world estimates.

2) have a look at your "stacking" code and see what another set of eyes might achieve. not even begun to consider this, as i don't even know where or how it is performed, but while i also am no mathematical genius, i have had many opportunities to extend myself in this department in other similar scenarios so wouldn't mind having a crack.

as an aside, we found the fastway module to use in harmony with australia posts offerings, and although it does provide a nice "fit" (as far as plugging a hole for australia posts limitations), it is still not 100% so i will be pursuing something, even if not the 2 options mentioned above.

once again, thanks for your replies to-date, hope i'm not being too demanding!

cheers
andy

[RodG]

1) take the smaller items (such as essence bottles which are only 10cm x 3cm x 3cm in width)
<snip>
by making the dimensions (say) 10cm x 1cm x 9cm, we in fact return a more accurate quote based on real world estimates.

I've no comments or thoughts about this method either way.

2) have a look at your "stacking" code and see what another set of eyes might achieve.

The 'stacking code', although 'crude' is/was actually quite accurate and effective, in fact if all items in the 'parcel' were of the same dimensions (and relatively small) it was probably as 'near perfect' as you could get while still keeping the code "simple".

Even with dissimilar sized items it did a 'pretty good' job, as long as the item sizes weren't *too* dissimilar.

It really started to fall apart if the individual items are/were already near the Australia Posts' maximum limits though.

not even begun to consider this, as i don't even know where or how it is performed, but while i also am no mathematical genius, i have had many opportunities to extend myself in this department in other similar scenarios so wouldn't mind having a crack.

I'm not sure if I should tell you this or not (I'm going to anyway). What you/we are trying to achieve here is known as 'The holy grail' of shipping modules. I wasn't aware of this when I first started working on the code, if I had, I probably wouldn't even have attempted it (and gotten as far I did). This isn't just for zencart either, but for any shipping module for any shopping cart currently being used.

The more items in the cart, and the more the item sizes differ, the greater the problem becomes. This generally isn't immediately obvious, but the further into the 'detail' you delve, the more the complexities involved start to show.

I'm not suggesting that it can't be done, just that it has currently proven to be an insolvable problem for those that have attempted it.

Maybe you'll be the one capable of doing it.. who knows?

once again, thanks for your replies to-date, hope i'm not being too demanding!

I wish you well in your endeavors, and no, you are not being too demanding ... in fact quite the opposite, I quite enjoy discussing this issue with people, because it helps highlight the problems involved to the majority of people that can't quite grasp why something apparently so 'easy' isn't quite as easy as it first appears.

Besides, if nothing else, you now have more information that you can present back to your client should they be expecting you to come up with an easy solution to the problem for them.

Cheers
Rod

[ALiepinieks]

...This generally isn't immediately obvious, but the further into the 'detail' you delve, the more the complexities involved start to show...

how true it is. just spent 4hrs trying to visualise a solution with about 8 pages of notes! you (well not you, but i) really don't realise how complicated it is to mathematically deal with all the nooks and crannies that appear when you have many different sized items in an order.

anyway, i've progressed far enough to know that i have something which (i feel) is a good alternative, albeit its not perfect. will post my findings this weekend with the hope i haven't overlooked something reeeeeally obvious : )

andy

[ALiepinieks]

hehehe... seems my troubles have gifted me with the zen follower tag. i always wondered what that meant, now i know : )

[RodG]

hehehe... seems my troubles have gifted me with the zen follower tag. i always wondered what that meant, now i know : )

So, does it mean you've asked too many questions, or given too many answers ?

Cheers
Rod

ps. I'll be interested in whatever shipping solution you come up with. Feel free to use the AustPost/ozpost module(s), and the ozpost server for any testing or development you require.

[ALiepinieks]

i'd like to say too many answers, but me thinks they are 70% questions, 20% answers, and 10% commentary : )

[ALiepinieks]

oops, make that 11%

[ALiepinieks]

Hi again all,

First draft here, no code yet, just principles.

I know it has been suggested that the stacking mechanism works quite well for smaller items, and without trying to be argumentative, I beg to differ.

Unless I'm missing something, the problem I have been encountering to-date lies in the fact that the current logic seems to assume that items can only be arranged in a single stack. As Rod alludes to in his "cubing.txt" file provided with the distro, a 3 dimensional carton can finish up with lots of empty space. I have actually found that for small items this has a greater impact, specifically because there is a single long row which is simply not "real world compatible". If I am missing something here I hope not, because this took some time!

Being able to create multiple stacks and then re-use lost space would in fact mean Australia Post could accomodate the types of delivery my client sends, as shown in some examples below. I have tried initially to provide examples with numerous products to show the difference.

Anyway, if anyone can let me know what you think; or not, I'd be most grateful :)

For those wanting a spreadsheet with all the formulae and logic included, happy to email it thru.

So, onto my half baked idea...

Max Height: 105cm
Max Girth: 140cm

Item Height Width Length Ordered
Unit A 1.50cm 3.50cm 8.00cm 50 unit/s e.g. Gas lighter
Unit B 5.00cm 5.00cm 5.00cm 20 unit/s e.g. Set of 12 coasters
Unit C 6.00cm 10.00cm 30.00cm 10 unit/s e.g Box of breakfast cereal
Unit D 12.00cm 20.00cm 30.00cm 1 unit/s e.g. Carton or box of nappies

Old method (for reference): Measure Pass/Fail
Total height: 247 Fail I must admit I am uncertain how you calculate total girth, so
Total girth: 223 Fail please do enlighten me if this is (undoubtedly) incorrect.

New method:
Item: Unit A Unit B Unit C Unit D Relates to step...
Qty: 50 unit/s 20 unit/s 10 unit/s 1 unit/s -
Unit girth: 23cm 20cm 80cm 100cm 2) Re: 1) in philosophical notes below
Stacks possible: 6 7 1 1 3) Re: 2) in philosophical notes below
Actual items/stack: 9 3 10 1 4) Re: 3) in philosophical notes below
Max items/stack: 70 21 17 8 5)
Actual stacks required: 6 7 1 1 - Re: 3) in philosophical notes below
New girth: 103cm 80cm 80cm 100cm -
New height: 14cm 15cm 60cm 12cm -
Remaining girth with full height: 37cm 60cm 60cm 40cm 6)
Remaining height with full girth: 92cm 90cm 45cm 93cm 7)

Rules / Steps:
01) Find the largest item by cubic weight for the entire order. I'll call these X in each loop that is required
02) Take the two largest dimensions of X, and calculate the girth required for one unit.
03) Calculate how many times X will fit inside the 140cm limit to return a "total stacks possible" figure (rounding down to the nearest integer)
04) Calculate how many need to be in a stack using the maximum number of stacks in point 3) (rounding up to the next nearest integer)
05) Use the remaining (smallest) dimension to work out how many are actually capable of fitting into a stack before exceeding the 105cm limit.
06) If 4) is less than 5), continue, otherwise fail.
06) Using the new girth (no. stacks x largest girth dimension) + other girth dimension) x 2), calculate the girth remaining
07) Using the total actual height (Actual items/stack x smallest dimension), find out the height remaining
08) Proceed to the next largest item by cubic weight and repeat steps 01) thru 07). Calculating however uses remaining height and original girth.
09) If X does't completely fit, try again, but fit what we can.
10) If X still doesn't completely fit, repeat 8) and 9), using remaining girths and heights leftover. If still nothing or only some items fit, fail.

Extrapolated: Loop Summary
Step Loop 1 Loop 2 Loop 3 Loop 4 PHP
Remaining height used: 105cm 93cm 33cm 18cm Actual figures used
Remaining girth used: 140cm 140cm 140cm 140cm Actual figures used
1) Unit D Unit C Unit B Unit A Item
2) 100cm 80cm 20cm 23cm Unit girth
3) 1 1 7 6 Max stacks
4) 1 10 3 9 Items/stack
5) 1 15 6 12 Max items/stack
6) Continue Continue Continue Continue Continue/Fail
7) 93cm 33cm 18cm 5cm Remaining height after calc
8) 40cm 60cm 60cm 37cm Remaining girth after calc

Philosophical points to note:
1) All initial selections are based on a "largest first principle", simply to minimise processing in the event it's simply way too big.
2) Your original concept of using the "short stack" seems appropriate, seeing as height always seemed to be the most limiting factor.
3) Multiple stacks vs. Odd numbers dividing out to a fractional No. of items per stack, I round up and then recalculate the stacks. I do this
because I felt residual space would always be more precious on the height side. Obviously open to suggestion here.
4) Loop retries are not included in this example. I do however intend storing residual girths/widths in an array, allowing unlimited retires
until all remaining "cavities" have been exhausted
5) The examples here reflext only a few big items, and predominantly small ones to show the massive difference these changes would make.
I have neither the time nor the patience to do any further testing tonight, but rest assured the mission will continue over the weekend : )
6) I am sure there is a better way to do this. This is just a first draft of my thoughts. Figured I was better off putting it out there before
spending oodles of time before seeing if anyone has any comments. I also understand this may simply be overcomplicated for those without
a real need for the changes I'm considering. If so, please ignore everything I've written : )