ozpost shipping module

[ALiepinieks]

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

[ALiepinieks]

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...ktank_v0.1.zip
andy

[RodG]

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

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

Cheers
Rod.

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

[ALiepinieks]

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

[RodG]

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

Cheers
Rod

[RodG]

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

[ALiepinieks]

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

[RodG]

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

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/showpo...&postcount=300

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

[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, 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

[RodG]

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.

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.

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.

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

Sweet. :-)

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.

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.

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.

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

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.

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.

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