ozpost shipping module

[RodG]

Hi again Rod

Thanks for adding 4012. We're small but very important :).

I agree :)

Regarding the satchels quote:

I understand and it does seem a conundrum. The server is just trying to fit the board in the cheapest satchel it can find, to the buyers benefit. It doesn't know I am too lazy and cheap to keep an entire range of Pre-Paids on hand. Clearly it doesn't know me as well as you do!

Well, not yet, but as with anything I code, I try to make the program as clever as I am (which equates to being as cheap and as lazy as everyone else) <grin> .

Here's my thought for what it's worth.

The satchels cost the same no matter where you are or where you are posting even outside the express network so you don't really need a server quote. They are more like a fixed price option.

This is true, up until the time Australia Post increases their fees, at which time everyone will need to manually update their prices, which negates the benefits of using a server. Beleive it or not, some merchants are so 'out of touch' they still offer economy air as an overseas shipping method (Australia Post dropped this about 3 years ago).

Perhaps if you could have any of the four satchels selected optionally with the merchant inputting their own pricing.

Thus if I select 5kg satchels in the menu (all I stock) at $22.00 (including handling) the price could be displayed whenever a product within the dimensions was being quoted.

Of course this might be a bit of a nightmare (?) to program.

Not really a 'nightmare', but it does place more dependance on the client code, which out of necessity I need to keep as simple as possible for portability purposes).

Nonetherless, it IS an option to be considered.

Another option (easy to implement, but I'm not convinced that there isn't a better way) is for the server to provide quotes for *all* satchels (that are suitable), and leave it for the client to filter the ones they don't need. This is much like the current method, but it will have the 'bad' side effect of offering (say) the 3kg and the 500gm stachels instead of just the 500gm ones, if suitible. IOW, it will present the customer an option that they don't really need. It WILL solve the current problems though.. but it is a matter of choosing the lesser of two evils, in my opinion.

My 'other' solution is to update the client code (again), to include another setting to tell the server to continue to work the way it is, or to return all satchel quotes as indicated above, thus making it a user choice.. This is the 'near ideal' solution, other than it does introduce yet another setting that would probably confuse most people as to its purpose.

As you can see, several possible silutions, but so far nothing I'm 100% happy with. (Which is why I seek other ideas and inputs).

Otherwise, I guess I would need to see if AP were willing to sell me, a humble retailer, some of their very important and special 3kg and 5kg XL satchels which apparently are only available to "contract/account" customers who have slept with an independent member of the Commonwealth parliament
http://auspost.com.au/business/expre....html#satchels

LOL.

Have you asked at your local PO recently? As of last May the 5kg XL satchels were made available to most outlets for general use.

6 quotes and still outside the Express Network (probably update overnight I guess).

I may need to take another look into the outside express network (my update should have taken immediate effect)... as for the duplicate quotes, it appears that you have more than one 'australia post' module installed/activated.. This is probably because you needed to make such a large jump in versions, and in the change from V1.x.x to V2.x.x I needed to keep the code entirely separate for developement purposes, therefore is is/was possible to have two versions running at the same time. Just disable the older version.

Cheers
Rod


Thanks again. At least I now understand what I didn't know.

cheers

cheers[/quote]

[Arliss61]

Rod

Yep had the old Aust Post module running in tandem.

Looking better now - although 4012 still seems to be outside the Next Day network.

A possibility for overcoming the satchels issues (which ones do you have/offer) is to clone the Store Pick Up "Walk In" module so that the text you input in

includes/languages/english/modules/shipping/storepickup.php

shows your satchel. The price can be controlled from Admin - Modules - Shipping.

Downside is that it will still be offered for everything - very small products (overkill) and very large (won't fit).

I am aware from http://shop.vcsweb.com/ that there are only a small number of sites using the paid Ozpost solution, so my problem is probably pretty rare.

If I was oo.com.au I'd pay a programmer to make a more elegant fix but for now this will probably do:

[RodG]

Looking better now - although 4012 still seems to be outside the Next Day network.

I've just (re)checked, and 4012 is definitely now identified as being inside the next day delivery network, so I can only guess that it was the destination postcode that was outside (apparently).

For my tests, I used postcodes 3000 (Melbourne) and 5555 (Ashford).
Only the quote to 5555 indicated that it was outside the express network.

A possibility for overcoming the satchels issues (which ones do you have/offer) is to clone the Store Pick Up "Walk In" module so that the text you input in shows your satchel. The price can be controlled from Admin - Modules - Shipping.
Downside is that it will still be offered for everything - very small products (overkill) and very large (won't fit).

This is also an alternatve for those merchants that don't wish to support the ozpost project.
For me, this would have an even bigger impact in that I'd need to replicate this same functionality for each of the different softwares. Admittedly, this is currently only ZenCart and OsCommerce, but I have a version almost ready for OpenCart, and hopefully several others by the end of 2011

I am aware from http://shop.vcsweb.com/ that there are only a small number of sites using the paid Ozpost solution, so my problem is probably pretty rare.

Just to clarify, it isn't just a small number of sites using the ozpost method, it is more a matter of the small number of (active) Australian zencart merchants period (which is why I need to bring other sofwares on board, because I suspect that all the other ecommerce solutions will also be small in number, but the combination of them all will produce positive gains for *all* of us.

As for your problem being pretty rare, I can't really say for sure. I became aware of what I consider to be my screwup (lack of foresight) in this regard a few minutes after releasing the initial V2.x.x code (Actually the 'problem' goes way back to V1, but it has become more troublesome with V2 with the additional 'hide' functions.
Other than yourself I have had one other person report that it caused a problem (same reasons as yourself), which actually makes it unrare considering the total number of users.

If I was oo.com.au I'd pay a programmer to make a more elegant fix but for now this will probably do:

A more elegant fix will be forthcoming because this 'hole' does bug me in that it can and does cause unexpected behaviour, not to mention the fact that It is in my best interests to make the module work in ways that the users would like and expect, so in this regard, I *am* the 'paid programmer'.

Cheers
Rod

[Arliss61]

Hi Rod

I've just (re)checked, and 4012 is definitely now identified as being inside the next day delivery network, so I can only guess that it was the destination postcode that was outside (apparently).

For my tests, I used postcodes 3000 (Melbourne) and 5555 (Ashford).
Only the quote to 5555 indicated that it was outside the express network.

You seem to have fixed the problem from the origin post code ie 4102 but there is still a problem at the destination end.

For example, from Brisbane (4012) the Express Network to Melbourne includes a range of post codes including 3000-3210; 3335-3338 plus several others incl Geelong and Ballarat.

In my test: 3000 (Melb CBD) and 3350 (Ballarat) were seen as Express but 3211 (Little River), 3220 (Bareena), 3182 (St Kilda) 3183 (Balaclava) 3168 (Clayton) are seen by the module as outside the Express Network. 5000 works too but not 5015 (Port Adelaide) or 5045 (Glenelg).

Maybe there is a problem with the coding of the ranges?

cheers

[RodG]

Maybe there is a problem with the coding of the ranges?

I've just added the remaining data tables.
If anything, any further errors will fail 'the other way' now, meaning that it is more likely to indicate next day deliverty IS possible in some cases where it may not be possible. Until now the default 'fail' mode was to indicate next day isn't possible, when in fact it was.

If you do spot any erronious exceptions please let me know and I'll see what I can do to rectify them.

Cheers
Rod

[RodG]

Another option (easy to implement, but I'm not convinced that there isn't a better way) is for the server to provide quotes for *all* satchels (that are suitable), and leave it for the client to filter the ones they don't need. This is much like the current method, but it will have the 'bad' side effect of offering (say) the 3kg and the 500gm stachels instead of just the 500gm ones, if suitible. IOW, it will present the customer an option that they don't really need. It WILL solve the current problems though.. but it is a matter of choosing the lesser of two evils, in my opinion.

My 'other' solution is to update the client code (again), to include another setting to tell the server to continue to work the way it is, or to return all satchel quotes as indicated above, thus making it a user choice.. This is the 'near ideal' solution, other than it does introduce yet another setting that would probably confuse most people as to its purpose.

OK, I think I've figured out the best way to do this.

1. By default, have the server returning quotes as it currently does (less chance of causing issues with older versions).

2. Update the client code with the following tests/checks
a) Are ALL satchel sizes enabled? If so, no changes needed
b) Are ALL satchel sizes disabled? If so, no changes needed.
c) Are only *some* satchel sizes enabled? If so, send additional data to the server so that either ALL suitable satchel quotes are returned (IOW, the smallest sachel possible, plus those that are larger, if any).

The downside being if the client only disables the XL satchels (the most likely case) and the item/parcel is 500gm suitable, the customer will still be presented with the 3kg satchels as well.

The other option for part 'c' would be to send enough data to the server (based on what is enabled/disabled) to enable the server to return quotes based on client selection and what is possible (as opposed to what is optimum).

Hmmmm.... probably not to hard after all.... Stay tuned...

Cheers
Rod