ozpost shipping module

harroman:

Hi
I have a similar problem and have run your script and get the following
< snip >
Everything seems ok, so any suggestions to what my problem might be.

I'd love to help, but I don't have a clue what you are referring to in regards to having "a similar problem"? Similar to 'what'?

Cheers
Rod

Hi Rod,

Found what appears to be an issue with the rates Couriers Please are returning in certain circumstances.

Not sure if this issue stems with my config or not..

If I enter my cost of Ezy Link Metro and Link labels.

Then add a 12kg box to the cart, select postcode 5290 as the destination, (which is SA7 on the CP rates card and would need 1 Metro and 12 Ezy Links sending from 2263), CP rates delivered are around the $22.00 mark ?

If I remove my costs and use the standard pricing option, the rate delivered jumps to the $60.00 mark, which is pretty much spot on with what the actual cost is.

I tried it on several postcodes, and from what I can see, its returning the correct rates for Metro and (semi-regional) areas if use my costs in the config, but anything that goes further out, its throwing up strange rates.

But if use the standard option, then its correct at all times..

Another regional postcode (as an example) 4377

Using the standard rates option, returns a price of $79.35
(1 Metro coupon / 17 EZYLink coupons according to CP's website)

But if I plug in my costs, it drops to $18.35.!!

Mike_Dean:

Found what appears to be an issue with the rates Couriers Please are returning in certain circumstances.
Not sure if this issue stems with my config or not..

Thanks. This is a bug. I'll have it fixed with the next update, but meanwhile, if you don't wish to wait, you can load the ozpost.php file into a text editor, navigate your way to line#1652 (or thereabouts). It currently reads:
$l = substr($fn[1],1,1) ;

Change this to
$l = substr($fn[1],1,2) ;

Resave.

Cheers
Rod

Thanks Rod,

Love ya work.!

New ozpost update now available for all. V3.5.1

After several weeks of testing, and a lot of feedback, I feel the latest version of ozpost is now ready for the masses.

A full distribution package is currently available for http://ozpost.net.au, with a copy also uploaded to the plug-ins section of this site.

For those currently running an existing V3.x.x version you should be able to use the one click update tool from your admin control panel.

This update contains full support for the recent Australia Post changes, and introduces several new couriers, specifically, StarTrack Express, SmartSend & Couriers Please.

There are also many other updates and changes, such as enhanced behaviour if items don't have any weights associated with them as well as improvements to the 'error processing' code, which can now use table rates rather than the simple static rates of the previous versions.

Although the beta testers have done a very good job (thanks guys) I think I'd be foolish to expect this update to be entirely bug free (it is actually quite a significant update. I was almost tempted to call it V4), so please keep an eye on things and don't hesitate to report any problems or issues. Preferable with a link to your store & product that will demonstrate the problem.

Thanks
Rod

Just downloaded the new version 3.5.1 using the update button in the admin panel (Zencart version 1.39h) and can not see the couriers please section that is supposed to be in this update. Have I missed something?

Hi,

Did you "Uninstall" and then "Reinstall"the module in Admin ?

No just did the auto update which is supposed to do it automatically. No mention of having to uninstall when pressing button.

Bruce1952:

Just downloaded the new version 3.5.1 using the update button in the admin panel (Zencart version 1.39h) and can not see the couriers please section that is supposed to be in this update. Have I missed something?

You haven't 'missed' anything. The problem has something to do with the updater code, which doesn't seem to want to 'take' with some installations. This is turning out to be a tricky bug to fix, because any 'fix' I come up with doesn't become effective until the next update. In other words, the current release may have this fixed for the next release, or, the latest changes could just as easily break the next automatic update. <eeek>.

Simply put the auto-update code in any given ozpost release is essentially a version behind the code being updated.

The 'cure' is simple. Perform a manual "Uninstall" and then "Reinstall". (Just the admin keypresses. No need to touch any files). Most, if not all of your current settings will be maintained, and this simple act of uninstall/install will resynchronize the database and files and all will be well.

It is always handy to keep in mind that the ozpost uninstall/install can/will often fix all manner of ozpost related problems, for example, if you ever need to restore files/data from backups, or if you install a seemingly unrelated module, and doing so causes an ozpost malfunction, the ozpost uninstall/install process will attempt to re-patch any of the changed/modified files. It won't re-replace the files, it will actually copy and modify them which helps avoid compatibility issues with said add-ons or updates.

Bottom line. Although the ozpost auto-update code is still a little flakey, the uninstall/install keypress is your friend.

Cheers
Rod

Hi Rod. I have 1.3.9h, trying to update ozpost but when I click it in shipping modules, it renames the file and then throws the following error:

1146 Table 'information_schema.tables' doesn't exist
in:
[SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'becker' AND table_name = 'main_ozpost_cache';]
If you were entering information, press the BACK button in your browser and re-check the information you had entered to be sure you left no blank fields.

When this happens I can't get to the uninstall button as the page crashes. I rename the file via FTP and the same thing happens. Any ideas?
Thanks!

I tried adding the table using the code from ozpost.php

CREATE TABLE " . TABLE_OZPOST_CACHE . "(
cache_entry_name varchar(64) NOT NULL DEFAULT '',
cache_data mediumblob,
cache_entry_created timestamp NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (cache_entry_name))") ;

Added the table OK but still getting the problem. Help?

slobadog:

I tried adding the table using the code from ozpost.php

---

CREATE TABLE " . TABLE_OZPOST_CACHE . "(
cache_entry_name varchar(64) NOT NULL DEFAULT '',
cache_data mediumblob,
cache_entry_created timestamp NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (cache_entry_name))") ;

---

Added the table OK but still getting the problem. Help?

Open /includes/modules/shipping/ozpost.php into a text editor.

Search for 'schema'. This is only found on one line. Delete (or comment out) this line of code, as well as the line that follows. ( starts with 'if ($res->fields ....)

Resave the file.

Cheers
Rod.

PS. This a a rare issue. I've only heard of one other case. The cause is the missing 'information_schema.tables' table. It shouldn't be missing. My 'fix' will take care of your immediate problem, but not the underlying cause that will probably have other side effects that you aren't aware of yet.

Thanks Rod. Had a little trouble installing the update. For a reason I couldn't determine, ozpost.php couldn't resolve the define DIR_WS_TEMPLATES. It was inserting it literally instead of resolving to DIR_WS_INCLUDES . 'templates/.

EG. USR/HOME/DIR/DIR_WS_TEMPLATEStemplate_default/templates

I got it working by redefining 'DIR_WS_TEMPLATES' with ```
define('DIR_WS_TEMPLATES', DIR_WS_INCLUDES . 'templates/');

Thanks for your help, the great support and a great mod.

slobadog:

For a reason I couldn't determine, ozpost.php couldn't resolve the define DIR_WS_TEMPLATES. It was inserting it literally instead of resolving to DIR_WS_INCLUDES . 'templates/. .

This is another known problem. I did have this taken care of at one stage but I appear to have unfixed it again with the latest update. :(

slobadog:

I got it working by redefining 'DIR_WS_TEMPLATES' with ```
define('DIR_WS_TEMPLATES', DIR_WS_INCLUDES . 'templates/');

A better place for this will be in the configure.php file(s), because that is where they are missing from. This suggests that you are either using an old version of ZenCart, or, your configure.php files haven't been updated along with the rest of the store.  

> **slobadog:**
>
> I now have it working except for the shipping estimator. If a weight is set to zero, it defaults to 1000kg! I guess I'll have to tidy up all the customers products...

Before doing anything with the products, the zero = 1000kg are ozpost settings.  
The 'kg/gms' switch determines if this value is 1000kg, or 1kg (1000gms).  
The value itself is a merchant defined ozpost setting, and is the default weight used if a product doesn't have its own weight assigned. (This is new to V3.5.1) 

 There is also another ozpost setting that causes products with zero weights to behave in different ways. The default behaviour is to use the weight determined by the weight/kgs/gm settings, but, it can also be set to ignore products with a zero weight (effectively giving the product(s) free shipping), OR, it can be set to produce a 'Contact store owner for shipping costs' type message if a zero weight product is added to the cart.  (Also new to V3.5.1) 

As for the customers products, there is one simple rule. Accurate weights *and* dimensions = accurate quotes.  
Although the weights are generally the most significant factor as far as costs are concerned, the ozpost module attempts to quote using the smallest sized 'standard' package possible for any given quote (envelopes, satchels & boxes). It can only calculate the correct sized package if the items also have correct dimensions.   
A common 'trap' is in thinking a 300gm item will fit into a 500gm satchel. Quite often, although the weight is suitable, the physical size of the item(s) may preclude the use of a 500gm satchel, in which case the ozpost module will quote on the next sized satchel that does fit (if at all).  Again, correct dimensions are essential for this to function correctly.  

Cheers
Rod

A better place for this will be in the configure.php file(s)
It actually is there. I tried simply redefining it at the top of ozpost.php but it still broke, I had to put it in the two lines mentioned to get it to work. Thanks for the extra info RE weights and dimensions, I'll get those too. I realise it needs updating but I had to modify so many core files, it's a bit of a pain.

Happy days, I can now have a glass of red...

slobadog:

It actually is there.

Strange. I wonder why it isn't getting used?

slobadog:

I tried simply redefining it at the top of ozpost.php but it still broke,.

I realise you've already overcome the problem, but for reference, the 'fix' that I use in the ozpost module (because permissions prevent modification of the configure.php file(s) is similar to line#226 of the ozpost.php file. Essentially the same 'define' that you are currently using, but with an 'if not defined' test, so that it only gets set by the ozpost module if it hasn't already been pre-defined elsewhere.

Cheers
Rod

Hi Rod
I am using V3.5.1 of Ozpost.
Since the Australia Post changes I have noticed that Express Post envelopes are not giving the correct price in the Ozpost module.
It charges the customer $5.25 but the actual cost is $5.80 (Small Express Post Envelope up to 125g and 20cm wide). On the Australia Post website I can not find any reference to a $5.25 option.

Robyn

robbie269:

Express Post envelopes are not giving the correct price in the Ozpost module.

All should be OK now. There was an error in the data tables.

I've extended your subscription by another month in way of compensation and to say thanks for reporting the problem.

Cheers
Rod

RodG:

All should be OK now. There was an error in the data tables.

I've extended your subscription by another month in way of compensation and to say thanks for reporting the problem.

Cheers
Rod

Thanks Rod :smile:

I am trying to enable this module even if "always free shipping" is selected. V3.5.1