ozpost shipping module

ALiepinieks:

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).

ALiepinieks:

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.

ALiepinieks:

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.

ALiepinieks:

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.

ALiepinieks:

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

ALiepinieks:

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

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

ALiepinieks:

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.

ALiepinieks:

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.

ALiepinieks:

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?

ALiepinieks:

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. :smile:

Cheers
Rod

RodG:

...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

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

ALiepinieks:

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 ? :D

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.

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

oops, make that 11%

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 : )

wow that really looks horrible. perhaps some formatting is in order...

for those using excel, here is a link if you'd like to d/l the excel spreadsheet (which is much easier to read!).
my apologies, it's getting late and that previous copy/paste was horrendous.
anyway, here it is: http://www.21designs.com.au/research/zc/ideas/ozpost_mod_thinktank_v0.1.zip
andy

ALiepinieks:

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!

Unfortunately, you appear to have obtained your information from the simplistic explanation of the problem from reading the cubing.txt file, rather than looking at the actual code. Yes, you are missing something (sorry about that). :D

The code itself is considerably more complex (but still far from perfect) in that for each item that gets added to the 'stack' the "height" of the parcel is compared with the length, and when the height exceeds the length the parcel is re-orientated, so the height becomes the new length, and the smallest of the remaining dimensions becomes the new 'height' and the stacking process continues. Eventually it reaches a point where both the height and the length will both exceed the 105cm limit, at which time the the longest of the two dimensions is split in half creating two columns of (length/2) x (widthx2) x height.
The parcel is then re-orentated once again and the process repeats, until both the length and the girth limits are reached, at which time the 'parcel' is split into two (lengthwise) .... and that is where the code pretty much 'gives up' and I really can't recall what it does from there..

Probably the easiest way to see this in operation is to create a test product of 10cm x 10cm x 10cm, then progressively increase the number of these items in the cart whilst observing the parcel size as displayed on the modified tpl_shipping_estimator page.

The "empty space" that is mentioned in the cubing.txt is a different issue and comes about when the items are of a dissimilar size. As an example, assume there are only three items in the cart:

Item#1 30cm x 30cm x 5 cm
Item#2 10cm x 10cm x 5cm
Item#3 5cm x 5cm x 5cm

These items allow for a 'single' stack with no re-orentation.

If simply 'wrapped' this 'parcel' would be pyramid shaped. However, we are not wrapping these items, we are 'boxing' them.

So, when stacked, the box size would need a length and width to cater for the maximum dimensions of any given item, namely 30cm x 30 cm. (Item#1)

Each item is only 5cm high, so the total height will be 15cm (5cm x 3), ergo, the box required is assumed to be 30cm x 30cm x 15cm.

However in a 'real world' situation, the two smallest items (in this example) will actually fit side by side atop of the largest item. So the ACTUAL required box size will be 30cm x 30cm x (5cm x 2).

In other words, the assumed/calculated box will contain 30cm x 30cm x 5cm of 'air' - To eliminate this, problem each of the smaller items need to be compared with all other smaller items in order to determine which, if any of them can be placed side by side on top of a larger item.

A more complex example using just two items:

Item#1 30cm x 30cm x 5 cm
Item#2 10cm x 10cm x 5cm

A person places one of item#1 in the cart, and 10 of item#2.

The stacking code will calculate a parcel 30cm x 30cm x 50cm.

In practice, we can fit nine of item#2 on top if item#1 (tiled), so the actual box size needed will be 30cm x 30xm x (5cm for item#1 + 5cm for the 1st nine Item#2 + 5cm for the remaining Item#2 )
= 30cm x 30cm x 15cm.

The 'calculated' box is therefore 30cm x 30cm x 35cm larger than it really needs to be. That is a lot of 'air'.

It is this 'tetris' like fitting/packing that causes the headaches, and as per my original statement, the more dissimilar sized the items are, the bigger this problem becomes.

I also mentioned that solving these issues is considered to be the holy grail of shipping modules the world over. I don't expect you to solve the problem (taking into account all possible scenarios) in a single weekend .. it is going to take a least seven days :yes:

Cheers
Rod.

ps. I haven't had time to study your proposal yet, but I do intend to over the next few days.

i certainly understand more thouroughly now, and no, i haven't had an opportunity to look at any code just yet.
while i'd love to elaborate... unfortunately the wife has demanded we watch a movie, so no work for me tonight : )
will review your examples later tonight (shhh)/tomorrow.

speak soon.
andy

ALiepinieks:

the wife has demanded we watch a movie, so no work for me tonight : )

Wanna swap wives? Mine demands I stop watching movies and go back to work :laugh:

Cheers
Rod

ALiepinieks:

no, i haven't had an opportunity to look at any code just yet.

I've just taken a quick look at your proposal and noted that you have taken the more traditional approach of trying to fit the maximum number of variable sized items into a known (maximum) parcel size ... at least that is the way it appears to me. (I wasn't aware that this was the more traditional approach when I devised my methology). Trying to follow this methology makes my head spin far more than my approach which pretty much ignores the maximum limitations until they are actually reached, and then re-organising to compensate, so all I can really say is I really wish you well, what you are doing is beyond my skill level, and I don't mind admitting it.

My only other comment, which you need to know before you start actually coding anything is that the girth is defined as
widthx2 + heightx2, or, if you prefer, (height+width)x2 where the height & width are the two smallest of the three dimensions.

Cheers
Rod

ok, so i chose the road well travelled; spent the weekend swimming, watching the cricket (oops) and watching movies.

anyway, up to my neck in this today and i have one question (so far) since perusing the code. where do the session variables "$_SESSION['slength']" etc. come from? I cannot find any reference to them in the standard ZC fileset, and they simply return a null value when called from tpl_modules_shipping_estimator.php, so i either have an old version of your ozpost mod, or i have missed a file somewhere. any ideas?

i am referring specifically to line 28 in the aforementioned file: <?php echo $totalsDisplay." Dims: " . $_SESSION['slength'] . "x" . $_SESSION['swidth'] . "x" . $_SESSION['sheight'] . " Boxes: " . $_SESSION['boxes'] ; ?>

i was simply trying to "debug" the total parcel dimensions as you allluded to without writing the code myself, but this makes me worry that i'm not starting from the point as i should be.

cheers
andy

ALiepinieks:

i have one question (so far) since perusing the code. where do the session variables "$_SESSION['slength']" etc. come from? I cannot find any reference to them in the standard ZC fileset,

They are set/defined in the /shipping/modules/austpost.php file

ALiepinieks:

and they simply return a null value when called from tpl_modules_shipping_estimator.php, so i either have an old version of your ozpost mod, or i have missed a file somewhere. any ideas?

I neglected to re-include them in the ozpost files found in the downloads section. The following link will take you to a zip file that has these re-inserted.
http://www.zen-cart.com/forum/showpost.php?p=794222&postcount=300

ALiepinieks:

i was simply trying to "debug" the total parcel dimensions as you allluded to without writing the code myself, but this makes me worry that i'm not starting from the point as i should be.

cheers
andy

Bear in mind that the 'ozpost' module doesn't use the same stacking code as the AustPost module that I have been previously discussing. It has been simplified to avoid any form of parcel (and possible item) splitting.

Cheers
Rod

oh i see. i must apologise then, because since taking your advice on NOT using the old austpost module, i have only ever been referring to the new ozpost module. sorry if i mislead you, however the info you provided was handy in any case as it gave me a few other ideas with my methodology for stacking.

i am about 50% finished on my first draft, which is somewhat more simplified than my initial examples given some lateral thinking over breakfast, lunch and dinner :)

it seems to slot into your existing code without too much hassle, and although i haven't finished testing, or determined the method for re-using parcel cavities leftover from larger items, there are only about 250 lines of code (which includes verbose commentary) replacing about 100 lines of existing code, so it's still fairly lightweight.

anyway, the following basic features do seem to be working at present:

1. parcel splitting by both dead weight or cubic weight (whichever applies)
2. parcel identification, weight and number of SKU's
3. which parcel has which products
4. quite obviously, all of the above is iterated on screen if using the existing 'debug' mode

referring to my comment about determining how to re-use remaining cavities, i'm uncertain if going the extra mile is really all that wise. in the real world, these can be used individually, or in combination with each other in any one of three dimensions, and while the complexity is bad enough from a coding point of view, i know if i was packing (say) 100 small items of (say) 20 varying sizes, there would be a very high chance i'd run out of space even though the code says 'you can do it!' asking a vendor to repack because the real world application isn't as perfect as the computational application is probably not the best way to go, so i will continue to test a number of extreme scenarios to ensure my stacking/packing attempts are not over-the-top.

anyway, 50% complete only means 50% complete writing the code. this is probably only 10% complete before it's safe to let loose on anyone, as there's a fair bit of testing to go through, and i'd like to revise it all for speed, size and logic once compelte as well. once i have something that's not embarrassing to look at though you can be sure you'll be the first to know.

thanks again for your help to-date ; )

andy

ALiepinieks:

oh i see. i must apologise then, because since taking your advice on NOT using the old austpost module, i have only ever been referring to the new ozpost module. sorry if i mislead you,

Apologies not neccesary, especially since it appears I'm probably to blame and misled you a little anyway.. It just wasn't realised until your last query regarding the session variables.

ALiepinieks:

however the info you provided was handy in any case as it gave me a few other ideas with my methodology for stacking.

And I now realise how you came to the conclusion that my stacking method wasn't very effective - because with the ozpost module, it isn't.

The older AustPost module is/was a lot more 'mature', which is why I supplied you the information on how THAT version actually worked.

As I said, I probably (unintentionally) misled you in that regard, so any apologies are really for me to give you.

The LAST thing I'd want to do is 'sabotage' what you are trying to achieve, 'cos if you succeed, you are saving me the effort of trying to redo it myself at some future stage.

ALiepinieks:

i am about 50% finished on my first draft, which is somewhat more simplified than my initial examples given some lateral thinking over breakfast, lunch and dinner :)

lateral thinking is certainly what is required.

ALiepinieks:

it seems to slot into your existing code without too much hassle,

Sweet. :-)

ALiepinieks:

anyway, the following basic features do seem to be working at present:

1. parcel splitting by both dead weight or cubic weight (whichever applies)
2. parcel identification, weight and number of SKU's
3. which parcel has which products
4. quite obviously, all of the above is iterated on screen if using the existing 'debug' mode

Have you had any thoughts or ideas on how to obtain, store and report
the quotes for the dissimilar sized parcels?

I must admit I haven't given this aspect of things a great deal of thought myself (yet) but I fear that it isn't going to be a particularly easy task either.

ALiepinieks:

referring to my comment about determining how to re-use remaining cavities, i'm uncertain if going the extra mile is really all that wise.

I tend to agree.

ALiepinieks:

i know if i was packing (say) 100 small items of (say) 20 varying sizes, there would be a very high chance i'd run out of space even though the code says 'you can do it!'

This is why I tend to agree .. in fact it is one of the main reasons I never pursued this line in my originial coding.

ALiepinieks:

anyway, 50% complete only means 50% complete writing the code. this is probably only 10% complete before it's safe to let loose on anyone,

Hey, that has never stopped MicroSoft... :D

ALiepinieks:

as there's a fair bit of testing to go through, and i'd like to revise it all for speed, size and logic once compelte as well.

Although a worthy consideration, I doubt that speed is going to be a serious concern. Most servers these days are plenty powerful enough to hide even the most inefficient code imaginable.

ALiepinieks:

once i have something that's not embarrassing to look at though you can be sure you'll be the first to know.

LOL, It was only a few days ago I refused to share some of my (very old, but functional) code because I felt it was too emabarrsing to look at.

There used to be a time I didn't care how code looked, as long as it worked. My how times have changed.

ALiepinieks:

thanks again for your help to-date ; )

As always, if there is anything I can do to make the work progress easier I'm happy to oblige. You seem to have things well under control though ..

Cheers
Rod