ozpost shipping module

RodG:

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

ALiepinieks:

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

ALiepinieks:

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.

ALiepinieks:

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.

ALiepinieks:

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

ALiepinieks:

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.

ALiepinieks:

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.

ALiepinieks:

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

ALiepinieks:

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.

ALiepinieks:

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.

ALiepinieks:

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

ALiepinieks:

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.

ALiepinieks:

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.

ALiepinieks:

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

Cheers
Rod

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

RodG:

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.

RodG:

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

ALiepinieks:

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

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!

exoticcorpse:

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

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.

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

[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

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

For the same reason(s) the even older and even more obsolete 'AusPost' module is still available.

1. Us mere mortals (the people that submit the modules) have no way to delete/remove them.

2. Although not applicable in this case, some of the older modules may not wotk with the newer versions of zencart, and since some people still use the older zencart versions it makes sense to leave the module for them to use, and

3. The zencart team generally have no way of knowing (unless they are told) if an old module wotks with newer versions of zencart or not. Many will, so they can't simply remove them just because they weren't created or specified to wotk with the latest versions.

Having said that, perhaps if DrByte, Ajeh, or any of the other zencart team could see fit to delete or archive the "AusPost" and "AustPost - Improved" modules it could save a few people a few headaches, because neither of them work with any version of zencart these days.

Cheers
Rod

Mmm. Rod, firstly I want to make in crystal clear that I very much appreciate your work. I too have been using the AusPost module on a commercial client's site, and without it ZC simply would not have been an option.

But to hear that it is no longer working correctly (by accident really) was pretty concerning. I understand ZC is OS, and what that effectively means to my clients is cheap. Heck, if they could/would pay of course I would use a commercial product. But up until now I always believed that ZC could work with the right support and technical knowledge.

But this scenario with redundant modules is extremely troubling. The AusPost - improved module is still available, listed as compliant with v1.3.8 AND seems to install & work fine with v1.3.8a - I know because I have it installed on a pre-production site.

As having some experience in ecommerce IMHO anything to do with money needs to be pretty set-in-stone, so I see it as a huge flaw in the whole ZC logic to have redundant modules involved with financial calculations available that look to be compliant with the latest release. Imagine if one of the credit-card modules were to be totally compromised, surely the ZC team would have to remove it.

I hope that the Zen Cart team do indeed take this on-board. Sure, there are suggestive reasons why old code may still available to download (though overall I disagree), but surely there should be the capacity for the "owner" of the module to indicate to potential users that there are serious flaws with the code and inform the general public that is no longer being supported.

Suggestion 1.

I think an easy solution might be for the Zen Cart forum to have threads that are specific to each module and only contain information from the writers/owners/updaters of the code. Means that critical information is easy to find and gives end-users a clear date-stamped picture of the status of this module.

Suggestion 2.

I think that you should consider charging an "optional" support fee for your code. Not sure if you can do this according to the ZC laws, but as this module is pretty mission-critical for my installs (I'm based in Unley, not far from you of course) I not only need it to work but need to know what issues are happening with it. So by being "registered" with you means that you would "most likely" email me with updates on the status of the module.

The new version of my clients site uses a third-party commercial credit card payment system (upgraded from the Ceon module) for two reasons:

1. PCI-DSS compliance
2. Keeping this part working is their problem, not mine.

FWIW I would be more than happy to pay an annual fee for you to keep my contact email on your mail-out list. Food for thought.

On a more technical side, can you give me any more detail as to why a server-change (yours or theirs?) is preventing the AusPost module from working properly? The obvious reason I ask this is does the new OzPost module potentially suffer from the same issue?

Cheers, Adrian

RodG:

Having said that, perhaps if DrByte, Ajeh, or any of the other zencart team could see fit to delete or archive the "AusPost" and "AustPost - Improved" modules it could save a few people a few headaches, because neither of them work with any version of zencart these days.
Done .

RodG:

This is a known bug. Replace the file
/includes/modules/shipping/ozpost.php with the one attached to this reply.
Perhaps you can submit this updated version to the Addons area so all can benefit from it without having to read this thread first?
The last edition you uploaded was v1.0.2, dated 2009-04-21.

DrByte:

Perhaps you can submit this updated version to the Addons area so all can benefit from it without having to read this thread first?
The last edition you uploaded was v1.0.2, dated 2009-04-21.

There are a couple of reasons this bugfixed version hasn't been uploaded yet. I guess the main reason is that the bug it fixes is rather small and doesn't affect the majority of users. I've also been pretty flat out for the last 4 or 5 months and haven't really had time to create, dissolve and test a new distribution package.

Although the 'latest' version I've supplied people is 1.0.6, there hasn't been any other interim releases.. the update in version numbers have been for my own reference as I've been making other changes and improvements to the code. On reflection I probably would have (or should have) created 1.0.6 distribution package several months ago.. I simply didn't expect it to take me as long as it has with some of the later developments. Hindsight is 20/20

As for the old/obsolete "AusPost" and "AustPost - Improved" modules, thanks for removing those, I'm sure it'll help avoid a lot of confusion.

I will also add that these two modules are/were not related in any way (other than making use of the Australia Post quotation servers).

The 'original' AusPost module (by Gerard Serna?) was broken (due to server changes) long before I created the "AustPost - Improved" code, and the AustPost - improved code got broken in September due to server/hosting issues beyond my control. Meanwhile, the fully functional ozpost module has been available since last February.

In theory, I could have ported the broken part of the AustPost - Improved code over to the new servers, but as mentioned, I had been pretty flat out, and it took all my 'spare' time getting 'ozpost' wotking again.

I know I don't really need to tell you (or justify the sequence of events to you), but felt that this short(?) summary would at least help you (and others) appreciate why there is a lot of apparent confusion, especially to those that don't frequent the forums on a regular basis.

Bottom line: The current ozpost module available in the downloads section is fully functional. It does have a couple of known bugs, but these bugs will not affect the majority of users because it relates to a combination if shipping methods that are so rarely used it was almost six months before the problem was first reported.

The next planned update is for early in the new year, with some significant improvements and additional shipping methods avaialabe.

Cheers
Rod

lotii10396:

to hear that it is no longer working correctly (by accident really) was pretty concerning.

I wasn't happy about it either.

lotii10396:

But this scenario with redundant modules is extremely troubling.

As I've just stated in a post to DrByte, one of these redundant modules had nothing to do with me at all, yet that didn't stop people downloading it and coming to me for 'support' of it. All I could do is explain the situation as and when possible.

lotii10396:

The AusPost - improved module is still available, listed as compliant with v1.3.8 AND seems to install & work fine with v1.3.8a - I know because I have it installed on a pre-production site.

That module does actually still work, but it is no longer able to supply a complete set of quotes .. specifically it will stil lgive correct quotes for parcels, but not for any 'fixed cost' items, such as the prepaid satchels.

The reason is, because that particular module requires access to two different servers for the different shipping methods. One of those servers no longer exists.

lotii10396:

As having some experience in ecommerce IMHO anything to do with money needs to be pretty set-in-stone, so I see it as a huge flaw in the whole ZC logic to have redundant modules involved with financial calculations available that look to be compliant with the latest release. Imagine if one of the credit-card modules were to be totally compromised, surely the ZC team would have to remove it.

I do agree, but it still must be kept in mind that the zencart team can only do so much, based on information that is made available to them.

It is also a sticky situation in (for example) Gerard's "AusPost" contribution - That module had nothing to do with me, and my code could be seen as being in competiton with his (some parts of which probably are also still functional). So it isn't just not my place, but could also be seen as being ethically wrong to request that Gerads module be removed.

lotii10396:

I hope that the Zen Cart team do indeed take this on-board. Sure, there are suggestive reasons why old code may still available to download (though overall I disagree), but surely there should be the capacity for the "owner" of the module to indicate to potential users that there are serious flaws with the code and inform the general public that is no longer being supported.

The zencart team will do everything they can to ensure the integity of the zencart project - As has been noted, those older modules have now been deleted.

Also, as per my previous paragraph, I am not the 'owner' of the older 'AusPost' module - my module origianally started out as an alternative. Even though the owner of the older module doesn't appear to be around any longer, it isn't my position to ask the zencart team to remove someone elses module.

lotii10396:

Suggestion 1.

I think an easy solution might be for the Zen Cart forum to have threads that are specific to each module and only contain information from the writers/owners/updaters of the code. Means that critical information is easy to find and gives end-users a clear date-stamped picture of the status of this module.

We try (there is an 'official' ozpost threat, but that doesn't stop people starting different threads, and I won't ignore ozpost questions simply because they aren't asked in the official forum.

lotii10396:

Suggestion 2.

I think that you should consider charging an "optional" support fee for your code. Not sure if you can do this according to the ZC laws, but as this module is pretty mission-critical for my installs (I'm based in Unley, not far from you of course) I not only need it to work but need to know what issues are happening with it. So by being "registered" with you means that you would "most likely" email me with updates on the status of the module.

This is under consideration ... in fact the next code update will also handle TNT shipping quotes (all being well) and for this part of the code to be made functional some sort of registration will be mandatory.

lotii10396:

On a more technical side, can you give me any more detail as to why a server-change (yours or theirs?) is preventing the AusPost module from working properly?

In simple terms, we lost access to our primary server due to 3rd party abuse, and this was one of the two servers needed to obtain a full set of quotes. Migrating and updating all of our data to a new server took several weeks, and because 'austPost - Improved' had been considered (by us) to have been obsolete for well over 9 months it wasn't exactly high on our list. The code for current 'ozpost' module was one of the FIRST things we restored.. this was back online within 24 hours. We then moved on to restoring our other essential services, and by that time it appeared that most store owners using the austPost module had noticed there were problems, and upgrated to the newer ozpost.

By the time we'd recovered everything our logs showed only the odd request coming in the the AustPost module and I made the executive decision that it wasn't worth the time or effort to restore a little used and obsolete function.

You, or your client must be one of those with the rare/odd requests :-)

lotii10396:

The obvious reason I ask this is does the new OzPost module potentially suffer from the same issue?

Any code that relies on 3rd party servers has some degree of risk involved that the server could unexpectadly dissapear, the ozpost servers are no exception. However, we have been running our servers since 1997 and in all that time this is the first serious outage that we've ever had. We have backups and redunancy in place to cater for most scenarios - and had we not considered 'AustPost - Improved' to be obsolete you probably wouldn't even have noticed these recent issues, so yes, it could happen again, but is it likely too? No. We relay on it ourselves, as to many of our web clients.

Cheers
Rod

Been using ozpost for awhile now and i think its great! Thanks for the contribution of it.

My question is during the checkout process i have noticed for some strange reason i am getting double days listed for eg.

my shipping table reads this

Regular Parcel 4 4 days Est Delivery (Includes $0.00 Packaging & Handling ).
$7.15
Registered Parcel 5 5 days Est Delivery (Includes $0.00 Packaging & Handling +$ 2.8 fee).
$8.00
Express Parcel 1 1 days Est Delivery (Includes $0.00 Packaging & Handling ).

so i was just wondering where i can locate this specific PHP file to edit it maybe so it only displays 5 days , not 5 5 days ??

Thanks

devinej1:

my shipping table reads this
Regular Parcel 4 4 days Est Delivery (Includes $0.00 Packaging & Handling ).
$7.15
Registered Parcel 5 5 days Est Delivery (Includes $0.00 Packaging & Handling +$ 2.8 fee).
$8.00
Express Parcel 1 1 days Est Delivery (Includes $0.00 Packaging & Handling ).

so i was just wondering where i can locate this specific PHP file to edit it maybe so it only displays 5 days , not 5 5 days ??

Thanks

It appears that you are missing one (or more) of the icon files, as the doubling up is a result of the ALT text being shown instead/as well.

Solution1: Ensure you have the full set of icons (and they are located where the need to be).

Solution2: In the admin/shipping/ozpost settings set the "show icons" option to either "no" or "methods only".

Cheers
Rod

RodG:

It appears that you are missing one (or more) of the icon files, as the doubling up is a result of the ALT text being shown instead/as well.

Solution1: Ensure you have the full set of icons (and they are located where the need to be).

Solution2: In the admin/shipping/ozpost settings set the "show icons" option to either "no" or "methods only".

Cheers
Rod

Worked a treat, Thanks for your quick response Rod. Highly appreciated

Thanks! :clap:

Thanks Rod for the comprehensive reply, and good to see such swift and sensible action from the Zen Cart team. I will switch from Austpost-Improved to your new Ozpost code and keep an eye out for the next release.

As mentioned have a think about the registration side - I too are always time-short (aren't we all.....) so tend to be re-active rather than pro-active when it comes to code (ie dont change/update unless absolutely required) and being a Zen Cart install I can't justify spending too much of my time on the forums unless I am trying to sort a problem/add a new feature.

So having critical emails sent to me is a blessing and I use it wherever possible.

Cheers again, Adrian