ozpost shipping module

[ALiepinieks]

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

quite obviously sending 1 large carton + the little bit of overflow there might be in a prepaid satchel is a better method. if i were to consider it (no wonder you left this little chestnut alone) i would imagine that i could return multiple quotes through a loop using a callback function to wait for each quote to return successfully, and once complete, the quote would then be merged with the parcel types itemised simply for clarity on the vendors behalf. unfortunately this would bring with it the caveat that multiple quotes use the same transport method (e.g. express, insured etc.), and this i haven't really got a clue on yet.

i'm also not sure the end-user needs to know the how (they don't really care about whether it's in a satchel or a box, they only care if its registered, insured, express etc. and of course, how much it's going to cost). this then brings another problem, regarding display. i had some really nice looking pics for each delivery method, and if i was to look into this they would have to be revised as there are simply too many possibilities to cater for every scenario. perhaps they could just be trimmed to parcel post, registerd, insured etc. with appropriate pics, but with no comment on the physical container.

to be honest, i'm not even at that point yet anyway; i'm still dumping variables onto screen and debugging, and considering i've spent about 8hrs on this already i will prbably have to leave it for other work that is beckoning right now.

perhaps i'll be able to revisit it in a few days.

in any case, in the event i do embark on parcel splitting (i'm still not sure i'll persist, it's driving me crazy already) i may take the easy road initially and simply split the parcels using the first parcel size encountered (which will obviously be the largest option selected through admin).

presently i'm storing the information in two arrays:

the first keeps info on every product id, weights dimensions etc. this array however has an additional field called 'boxid', which if set to '0' (the default before packing starts) means the item was not able to be packed. if set to 1,2,3... it simply menas this is which box the product is in.

the second is a summary array generated while packing, and this one stores parcel information cumulatively for each of the boxid's mentioned earlier. info recorded is id (of course!) dead weight, cubic weight and no. units.

so i don't think i'll have a problem getting the info there, it's really just a case of customising it to suit every application and then deciding what should be user customisable and what should not.

as i originally stated, i will more than likely implement this for my client initially, and spend some time tweaking it, seeing what works and what doesn't before committing to a 'published solution'. seeing as i hadn't given the varying parcel sizes much thought, any other ideas you may have on potential issues are welcomed (albeit with some disgust when i realise how much more work is needed!).

thanks again
andy

[RodG]

(no wonder you left this little chestnut alone)

LOL. Well,as I've been saying, the more we delve into the problem and issues, the more complex it actually becomes.

The 'ideal' solution really isn't considered to be a 'holy grail' without reason.

i would imagine that i could return multiple quotes through a loop using a callback function to wait for each quote to return successfully, and once complete, the quote would then be merged with the parcel types itemised simply for clarity on the vendors behalf.

That is the solution I first envisioned too.

unfortunately this would bring with it the caveat that multiple quotes use the same transport method (e.g. express, insured etc.), and this i haven't really got a clue on yet.

Not to mention the situation where 'leftovers' of the 'main' parcel could in some cases be small enough to be considered as a 'letter' or perhaps even suitable to fit into a prepaid satchel, where different rules apply.

i'm also not sure the end-user needs to know the how (they don't really care about whether it's in a satchel or a box, they only care if its registered, insured, express etc. and of course, how much it's going to cost). this then brings another problem,

Well, more than one problem actually...

regarding display. i had some really nice looking pics for each delivery method, and if i was to look into this they would have to be revised as there are simply too many possibilities to cater for every scenario.

Oh, I dunno, the current module only caters for around 30 different methods/scenarios, so what would 2 parcels give us ? 30x30? .. what about 3 parcels.. 30x30x30 ? Surely we can manage that? <grin>

The problem I was thinking about wasn't so much the end user, but moreso the merchant.. Assuming we end up with just 2 dissimilar parcels for any given order, the system needs to record what items were calculated to fit into what parcel so that the merchant can pack the parcels accordingly, otherwise they could end up with a totally different size/weight distribution that will throw the quotes way off.

perhaps they could just be trimmed to parcel post, registerd, insured etc. with appropriate pics, but with no comment on the physical container.

Also, that won't solve the merchant packing issue.

to be honest, i'm not even at that point yet anyway;

I do realise this, and I'm really not trying to make things even more complicated for you - I know it is a one step at a time process.

I am however 'tossing' these ideas your way in the hopes that you may think of ways to avoid or circumvent such stumbling blocks before you actually hit them (having been there and done that).

i'm still dumping variables onto screen and debugging, and considering i've spent about 8hrs on this already i will prbably have to leave it for other work that is beckoning right now.

perhaps i'll be able to revisit it in a few days.

<grin> OK, I'll let you off the hook in having it completed in 7 days.

I'll give you 10 days instead LOL.

in any case, in the event i do embark on parcel splitting (i'm still not sure i'll persist, it's driving me crazy already)

I sure hope others are reading this thread and are now really starting to appreciate the complexity of what first appears should be an 'easy' thing to do.

I've seriously lost count at the number of 'complaints' I've recieved over the years about the parcel splitting 'not working properly' and asking what can be done to 'fix it'.

This is also why when I re-did the ozpost module I didn't even try. My (proposed) solution to the problem is to add additional carriers (courier companys) to the module, so when the Australia Post limits are exceeded it provides quotes from a carrier that WILL accept them.

Due to several reasons (time being one of them, lack of information from the carriers being another) this solution is still to be implemented.
However, thanks to information received from another zencart participant recently I'm hoping to have quotes from TNT avaialble sometime before the new year. :-)

I *wasn't* going to make this information public until I had something functional, but I figured I'd mention it to you now just in case it will make a difference as to which way you should head.

presently i'm storing the information in two arrays:
the first keeps info on every product id, weights dimensions etc. this array however has an additional field called 'boxid', which if set to '0' (the default before packing starts) means the item was not able to be packed. if set to 1,2,3... it simply means this is which box the product is in.

These arrays will ultimately need to be stored back into the database (more headaches).

so i don't think i'll have a problem getting the info there, it's really just a case of customising it to suit every application

Even this is an issue.. I know for a fact that some 'ozpost' users are selling feathers, and others are selling kitchen sinks, etc. The range to consider is huge.

and then deciding what should be user customisable and what should not.

I know many will disagree with me on this, but I find the less 'customisation' required, the easier it is for everyone concerned.

seeing as i hadn't given the varying parcel sizes much thought, any other ideas you may have on potential issues are welcomed (albeit with some disgust when i realise how much more work is needed!).

I *think* I/we have now covered all of the issues that I know of (bearing in mind that I started backing out of the entire parcel splitting approach a long time ago).

Having better stacking code is always going to be good (and beneficial), but I do honestly believe that the 'ideal packing solution' AKA 'The holy Grail of shipping modules' that comes about with good stacking AND parcel splitting suitable to all possible item combinations has so many potential problems associated with it that a working solution may never be found. The 'best' we can hope for is something that is workable and usable for any given client's products within a limited range of options.

As I've said many times, I'm not stating any of this to discourage you in any way whatsoever, I'm discussing it with you in the hopes that it gives *other* people a far greater insight into the extent of the problem, and that the 'solution' really isn't as easy as it first appears.

Anyway, enjoy your few days rest, we'll be expecting a prototype from you before the new year

Cheers
Rod

[ALiepinieks]

No reason for this post other than I'm taking a 30min break before my last stint tonight (only for a few days anyway).

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.

i've sat here and played out several rather complex scenarios, as well as a few simple ones all on paper, effectively drawing a 2 dimensional box (with the x axis representing length, y axis representing girth; crude i know) and stacking each item, following my code and all variables along the way.

in each case, I needed a minimum of 3 additional dynamic arrays to store gaps, and by the time i started writing code i could see this was going to quadruple the size of the changes i'd already made, for a result that we have both suggested might be 'too perfect'.

this wasn't what i set out to do.

so, considering i've managed to get some decent stacking, and what i believe to be some utilisation of 'leftovers' i'm going to call it a day and simply implement the ability to split parcels, along with the improvement on stacking to your new ozpost mod.

i do believe there is room for improvement in my existing stacking methodology, specifically with numerous items of varying sizes (especially when there's not many of each differently sized item e.g. 30 items, 25 different sizes) without going over the top. this would involve changing most of my existing code, and while i considered this i will simply document it and leave it for a few rainy days.

in short, i think about 75% of order types will utilise about 75% of the space theoretically available. the worst case scenario i could come up with was in fact one that wouldn't benefit from better stacking, and that was a product that was 51% of both the available girth and height, for which alternative freight options might simply be better suited anyway depending on the location of shipping.

either way, i'm back into it tonight for one last crack before taking a few days break.

cheers
andy

i would rather focus now on multiple quotes and their presentation to the user/administrator, as i believe this to be quite a useful feature.

[ALiepinieks]

the system needs to record what items were calculated to fit into what parcel so that the merchant can pack the parcels accordingly

...agreed, one of the reasons i am currently storing all product vs parcel information. i had always intended on providing an improved packing list, although once again, hadn't given any thought to the details...

writing back to the db is not something i would have thought to be too difficult, however this also is a completely baseless comment seeing as i haven't looked at it yet

anyway, glad i've got that 7 day monkey off my back, new years is already starting to look tight : )

andy

[RodG]

writing back to the db is not something i would have thought to be too difficult, however this also is a completely baseless comment seeing as i haven't looked at it yet

Actually it's not really difficult at all.

The most difficult part (which is also quite easy if you know what you are doing) is making it 'foolproof' for the end user to add the newly required tables and/or fields.

Cheers
Rod

[exoticcorpse]

Hi Rod. This is a really great module, and has been working hassle free for me for a good 12 months now. However, in the last few weeks I have noticed my customers have been overcharged for postage on letter/large letter size products. It no longer charges the letter rate and jumps straight to parcel. I can assure you I have letter enabled and the products are the right weights and dimensions as it was working in the past. Would this be due to an external problem? Can anybody else test and let me know if they're experiencing the same thing?
Thanks!

[RodG]

Hi Rod. This is a really great module, and has been working hassle free for me for a good 12 months now.

If you've been using the same module for the last 12 months then you are NOT using 'ozpost' , you are using 'AustPost'.

Due to a forced (and unexpected) change in servers, the old AustPost module hasn't been able to give accurate/valid quotes since September 2009.

I recommend you upgrade. Click on the ozpost link in my signature line for easy access to the new module.

Cheers
Rod

[aussiewebguy]

Hi Rod. Thanks for your work on the ozpost module - it's great!

When I activate Letters for overseas (Letters is not selected for Australia) it also shows up for Australian customers during checkout. Is is possible to disable Letters for Australian customers while keeping it as an option for overseas customers?

The reason for this is I want all Australian letters to be sent as registered but to give overseas customers the cheaper option if they want it.

Thanks in advance,

Greg.

[lotii10396]

I know this might seem a *dumb* question but if this Ozpost module replaces the AustPost - Improved Module, why is the *old* one still being offered as a download?

From what I can tell (only by accident did I read this thread too...) is that I should *not* be using AustPost - improved but instead using Ozpost.

????

Adrian

[RodG]

[quote=aussiewebguy;816911
When I activate Letters for overseas (Letters is not selected for Australia) it also shows up for Australian customers during checkout. Is is possible to disable Letters for Australian customers while keeping it as an option for overseas customers?[/quote]

This is a known bug. Replace the file
/includes/modules/shipping/ozpost.php with the one attached to this reply.

Cheers
Rod