ozpost shipping module

I am having an issue with the tnt part of the module. It calculates and shows TNT Shipping rates in debug mode but switch off debug mode and the tnt shipping calculation doesn't show in checkout. I am using Zen Cart 1.3.9h no upgrades. Fresh install 2 weeks ago. Using Ozpost 2.1.1. https://www.superiormarinegroup.com.au/catalog

Olsta:

I am having an issue with the tnt part of the module. It calculates and shows TNT Shipping rates in debug mode but switch off debug mode and the tnt shipping calculation doesn't show in checkout. I am using Zen Cart 1.3.9h no upgrades. Fresh install 2 weeks ago. Using Ozpost 2.1.1. www.superiormarinegroup.com.au/catalog

It seems to be working at the moment (Road express only).
your debug shows other TNT methods available, so I assume you have disabled those.

BTW, your tpl_modules_shipping_estimator.php file hasn't been updated with the latest copy from the ozpost distribution package... it takes care of some of the messy formatting.

Cheers
Rod

Ozpost.net News

   **17th November 2010 CHANGES TO ESTIMATED DAYS DELIVERY  - OZPOST.NET **

In keeping with a number of requests, ozpost.net has recently altered the way it estimates the delivery times shipping quotes.
Until now, each carrier returned this information in their own formats that generally had nothing in common with each other. Some would quote a specific number of days, some would quote a range of days, and others an estimated date. Feedback appears to indicate that most people (merchants and most importantly, the customers) appear to prefer the date format rather than the estimated days format, so I have opted to make all estimates conform to this format...

Along with this change comes a couple of new configuration options that will be included in the next client program updates. Meanwhile, these options can be added to existing/older clients by loading the file /includes/modules/shipping/ozpost.php into a text editor and searching for the line that reads like:

$result = $this->_getURL($this->SERVER, "/postage.php?weight=$parcel......................................");

Insert between "?" and "weight="

deadline=xx&maildays=y&

So the line now reads something like:
$result = $this->_getURL($this->SERVER, "/postage.php?deadline=xx&maildays=y&weight=$parcel.............

The "deadline" (xx) is the cutoff time (hour 0-23) for sameday mailings (overnight delivery)... The default is set for 10am (local store time).

The "maildays" value (y) indicates the days that you do your mailings..
A bitmapped value where:
Mon = 1
Tue = 2
Wed = 4
Thu = 8
Fri = 16

A value of '0 or 31' indicates every weekday, otherwise simply add the numbers that match your maildays..

examples: Mon, Wed & Friday only = 1 + 4 + 16 so maildays=21
Tue & Thursdays only = 2 + 8, so maildays=10
All except Mondays = 2 + 4 + 8 +16 so maildays=30
Tue, Wed, Thurs only = 2 + 4 + 8 so maildays=14

The default value is '0' (all weekdays)

IF YOU ARE HAPPY WITH THE DEFAULT VALUES YOU DON'T NEED TO MODIFY ANYTHING!!!!!!

If you have any further questions or problems please ask.

Thanks
Rod

Hi Rod

I prefer the 'estimated days' method. I'm still running an old version because of my mods for 'packing' and not really in a position to install and modify the latest version at the moment. (EDIT: v2.0.6 modded)

Problem for me immediately is that I'm now getting '0 days estimated delivery' for my shipping quotes. (EDIT: I changed code to state 'estimated delivery')

Is the 0 days thing to be expected or is there something else that is going wrong?

Cheers
Greig

Hi Rod,

Thanks for your continued support on ths excellent mod :)

I have a slight problem...
My "Prepaid express satchel 500g" is only displaying as a "Prepaid satchel 500g".

It has the correct price displayed and the alt text is correct "500g Express Satchel" but it has the wrong image associated.

Also when selected it displays as Australia Post (500gm Satchel):
Not Express Satchel..

I'm using the .png icons

The site is: stillmomentsnursery.com
ozpost V2.1.1

Thanks
Tim

GAM:

Is the 0 days thing to be expected or is there something else that is going wrong?

This has been a particularly troublesome one for me to maintain backwards compatibility with, mainly because pretty much every different release has had some kind of change to the part of the code that dealt with the output formatting of the disparate data from the various carriers.

No, the '0' thing was not to be expected and should now be fixed (for v2.0.6 at least). Other versions have either already been fixed, or I'm not yet aware they are still broken).

Cheers
Rod

Hi Rod

Thanks, it seems to be fixed now. Finally got an order today ;-)

I'll try to have a look at the latest release and see if/how I can port my existing changes to the new version, that is, if my changes are even required now. I haven't kept abreast of the changes but I read that you've modifed the 'packing/volume' calculations, which was the main reason for me to keep with my modded 2.0.6 version).

If there is some way I could continue to display a number of days instead of the other variations I would appreciate it a lot.

Cheers
Greig

Tim Ware:

My "Prepaid express satchel 500g" is only displaying as a "Prepaid satchel 500g"

It should be OK now. (My error with latest server update).

Thanks for the report.

Cheers
Rod

Thanks Rod is working correctly now thanks. :)

1 other quick question..
I have the Postage Delay (days) set to a minus figure to disable the estimate delivery time feature.
But after I set it to this, it starts adding new lines between the quotes. Which get larger and larger as the quotes go down through the list.

It works fine if I enable the Postage Delay (days).

Thanks again
Tim

GAM:

If there is some way I could continue to display a number of days instead of the other variations I would appreciate it a lot.

I'll possibly end up adding a toggle/switch for this.

Question. Since you prefer the Days, do you prefer them as they are currently supplied (IOW, NOT taking weekends into account), or would you prefer to use the actual number of days instead?

Or, to put it another way... if the estimated days is say "1" and the order is placed on a Friday, the real estimate should be 3 days 'cos that's how long it'll take to arrive at destination, so which is your preference, business days or actual days? (ideally, this should be what would your customers prefer). I'll probably only use the business days for the module, but I thought I should ask, because the direction I take with ozpost really is a direct result of user feedback.

Cheers
Rod

Tim Ware:

1 other quick question..
I have the Postage Delay (days) set to a minus figure to disable the estimate delivery time feature.
But after I set it to this, it starts adding new lines between the quotes. Which get larger and larger as the quotes go down through the list.

It works fine if I enable the Postage Delay (days).

Hmmmm, what interesting (and unexpected) behaviour... I need to look into this a lot further than I've time for at the moment (I have to head out shortly for the evening). It is this part of the code that has undergone most of the restructuring lately... and as surprising as it may seem, I've done most of my tests and checks with the older client programs.. It didn't really occur to me that the latest version would also have some hidden issues.
Doh!

I'll report back what I find, along with any suggestions for a fix/cure

Cheers
Rod

RodG:

I'll possibly end up adding a toggle/switch for this.

Question. Since you prefer the Days, do you prefer them as they are currently supplied (IOW, NOT taking weekends into account), or would you prefer to use the actual number of days instead?

Or, to put it another way... if the estimated days is say "1" and the order is placed on a Friday, the real estimate should be 3 days 'cos that's how long it'll take to arrive at destination, so which is your preference, business days or actual days? (ideally, this should be what would your customers prefer). I'll probably only use the business days for the module, but I thought I should ask, because the direction I take with ozpost really is a direct result of user feedback.

Cheers
Rod
Hi Rod

Toggle would be good ;-)

I prefer 'business days'. The reason I prefer an estimated transit days system is that my 'dispatch days' can be irregular hence... 'x days estimated transit from dispatch date'.

FYI
I read about your new system regarding weekly dispatch days, a few posts back, and it sounds good and I imagine very appealing for many/most but it would not really work for me due to my 'irregular' dispatch days... typically Tue to Thur but often enough Mondays and Fridays too. Time of day also makes a big difference. I typically 'cut-off' same-day dispatch around midday i.e., orders received after midday would normally be dispatched the following business day.

If you are going to look at the 'days' vs 'date' toggle/flag then I will hold off upgrading (and hacking) the latest version.

Cheers
Greig

RodG:

It seems to be working at the moment (Road express only).
your debug shows other TNT methods available, so I assume you have disabled those.

BTW, your tpl_modules_shipping_estimator.php file hasn't been updated with the latest copy from the ozpost distribution package... it takes care of some of the messy formatting.

Cheers
Rod

Rod thanks for your quick response. Have updated that file. Had some issues with it early on that is why i reverted back to the older file but it seems to be working now. As for the tnt shipping still doesn't show when not in debug mode. Will leave the shipping module debug mode off so you can see what I mean. Don't understand it as the debugger doesn't give me any errors?? Yes I only have TNT Road Express enabled. I have tried to enable them all to see if any show up when debugging mode is off and none of them show.
superiormarinegroup.com.au/catalog

No I spoke too soon. Updating the tpl_shipping_esitimator makes the search sidebox drop to the side and squeeze the page up. Looked at the coding and change the table dimmensions from 100% to a pixel width but didn't fix the side box issue. when I put the old file back in it is good again. ??

Olsta:

No I spoke too soon. Updating the tpl_shipping_esitimator makes the search sidebox drop to the side and squeeze the page up. Looked at the coding and change the table dimmensions from 100% to a pixel width but didn't fix the side box issue. when I put the old file back in it is good again. ??

PLEASE DISREGARD THE PREVIOUS POST ROD. I added a form tag to the end of your updated tpl-modules-shipping_estimator file and this fixed the layout problem.:D

Olsta:

PLEASE DISREGARD THE PREVIOUS POST ROD. I added a form tag to the end of your updated tpl-modules-shipping_estimator file and this fixed the layout problem.:D

This is a known (and somewhat embarrasing) bug introduced into v2.1.1 <sigh>

Cheers
Rod

Olsta:

Don't understand it as the debugger doesn't give me any errors?? Yes I only have TNT Road Express enabled. I have tried to enable them all to see if any show up when debugging mode is off and none of them show.
superiormarinegroup.com.au/catalog

With the debug enabled, what you see in the 'server returned' section are the methods that are considered suitable for the item being quoted. If a method does show here, but doesn't show in the end listing, then it is because that method has been disabled.

In the test I performed, there were 4 valid TNT methods returned, but only one of them was showing, which was how I deduced that you had disabled some of rhem.

As a general rule, many/most errors will also show in the 'server returned' section, and they will have a quote of $0.00, and usually an estimated delivery time of -1 . In either case, quotes containing these values are also filtered from the final quote list.

There are some errors that can't easily be trapped or catered for in any meanginful or useful manner, and these are usually 'silently' ignored. For the most part though, if an error can be reported, it will be...

Anyway I figured knowing a little about what the debug is showing you will help solve many of the mysteries.

Incidently, you probably don't realise it, but with your debug enabled this afternoon I was able to identify an issue with some of the TNT error reporting, so thanks to you, the module now provides a little more debug information than it did this morning :-)

Cheers
Rod

RodG:

With the debug enabled, what you see in the 'server returned' section are the methods that are considered suitable for the item being quoted. If a method does show here, but doesn't show in the end listing, then it is because that method has been disabled.

In the test I performed, there were 4 valid TNT methods returned, but only one of them was showing, which was how I deduced that you had disabled some of rhem.

As a general rule, many/most errors will also show in the 'server returned' section, and they will have a quote of $0.00, and usually an estimated delivery time of -1 . In either case, quotes containing these values are also filtered from the final quote list.

There are some errors that can't easily be trapped or catered for in any meanginful or useful manner, and these are usually 'silently' ignored. For the most part though, if an error can be reported, it will be...

Anyway I figured knowing a little about what the debug is showing you will help solve many of the mysteries.

Incidently, you probably don't realise it, but with your debug enabled this afternoon I was able to identify an issue with some of the TNT error reporting, so thanks to you, the module now provides a little more debug information than it did this morning :-)

Cheers
Rod

Hi Rod, I have enabled the 4 TNT shipping methods for you and put the shipping module back into debug mode. I personally can't find any errors but I assume you would have a better knowledge and understanding of what the debug returns than I would even though to me it just looks like a straight forward return result on what shipping methods can be placed given the weights and dimensions produced. You may already have this info but I have a 23 page doc file from tnt for RTT (Version 2) which I could send you if you would like me to do so send me your email to [email protected]

Thanks Ollie

Olsta:

Hi Rod, I have enabled the 4 TNT shipping methods for you and put the shipping module back into debug mode. I personally can't find any errors

Well, as I said in my posting to you yesterday"
It seems to be working at the moment (Road express only).
your debug shows other TNT methods available, so I assume you have disabled those."

In other words, there were NO errors that I saw with MY test order.
I Just tried another item... still not a problem.

Conclusion: The problem you are having is Item specific, or perhaps destination specific. (help me out here huh? I can't check every item to every possible destination for you).

Olsta:

but I assume you would have a better knowledge and understanding of what the debug returns than I would

Not really, it is a straigtforward XML file

Olsta:

even though to me it just looks like a straight forward return result on what shipping methods can be placed given the weights and dimensions produced.

Exactly. As well as many of the possible error messages, should they occur. Did I not just explain all this too you?

Olsta:

You may already have this info but I have a 23 page doc file from tnt for RTT (Version 2) which I could send you if you would like me to do so send me your email to [email protected]

I appreciate the offer, but until/unless it is proven that the existing code is broken and/or produces invalid results then I probably won't even look at it, under the assumption it is no different than the informatation that I already have.

ANYWAY, as I've said, I tested your store last night and again just now, using an a couple of random items, to a couple of known valid destinations, and nothing was amiss... We clearly need to start working on the same page, please provide a link to the item along with the destination postcode/suburb that you are using that will show the problem that you are having and then perhaps I can solve the mystery.

Cheers
Rod

GAM:

If you are going to look at the 'days' vs 'date' toggle/flag then I will hold off upgrading (and hacking) the latest version.

The toggle has been added (server side). Needless to say, I still need to update the client software for it (probably within the next week).

I have set up so that by default the DAYS will show (as this has been the 'traditional' format). The exception being V2.1.1 with uses the DATE format by default.

Until this is added to code, it can be manually set by editing the
/includes/modules/shipping/ozpost.php file, and adding the following to the QUERY STRING "ef=0" (days format) or "ef=1" (date format).

Cheers
Rod