ozpost shipping module

[Mike_Dean]

Cheers Rod, I'll see how that goes..

Thanks,
Mike

[RodG]

Hi Rod,

Just wondering if this module is compatible with fast and easy checkout (FEC)?

I don't know if FEC is compatible with this module or not.

Also if i was using the Aus Post improve module is it just a matter of overwriting the existing files with the new ones?

Aus Post improved hasn't worked properly for almost a year.

ozpost is a completely different module so no overwriting the existing files will take place. If you just upload/install the ozpost module you'll end up with two modules, austPost and ozpost. There is no *need* to remove/disable the unused module, but it is strongly recommended so as to avoid any possible confusion.

Cheers
Rod

[Mike_Dean]

Cheers Rod, I'll see how that goes..

Thanks,
Mike

Worked a treat, inserted straight after // store it //.

Now, how do I remove the words "Australia Post," as well.

I tried using the same formula, but using "Australia Post'" instead, but it did not work.

The reason I want to remove it, is that we don't always use Aust Post, but we do use the prices it quotes. So I don't want people automatically assuming it is Aust Post that will deliver.

[RodG]

Now, how do I remove the words "Australia Post," as well.

I tried using the same formula, but using "Australia Post'" instead, but it did not work.

The reason I want to remove it, is that we don't always use Aust Post, but we do use the prices it quotes. So I don't want people automatically assuming it is Aust Post that will deliver.

The 'dirty' way to to this would be to add a line reading:
$carrier = "" ;
This will need to be added just before/after the other line of code you added.

A simpler/better way would be to modify the /languages/modules/shipping/ozpost.php file and redefine he carrier name to your choosing (including '' )

The $carrier variable and the various 'defines' were introduced along with the TNT and Fastway functionality.

Cheers
Rod

[giftpackaging]

Hi Rod,

I'm still getting errors with shipping calculation. Not sure if there has been an update to fix yet.

If a customer orders too many of a particular item/s then it will get to a point where ozpost can't calculate the shipping cost and give the Error and AP flat rate.

"ERROR: (18+53.00) x 2cm exceeds the Maximum 140cm girth allowed. Using AP Flat Rate." etc..

I've noticed on ebay, I believe its using the Auspost rates to calculate shipping automatically if wieght, size/dimensions have been entered for each product. The shipping calculates the same costs as ozpost, but doesn't give an error when more products (qty) are added.

Any update on this?

Michael

[RodG]

Hi Rod,

I'm still getting errors with shipping calculation. Not sure if there has been an update to fix yet.

As far as I'm aware, your problem was solved months ago. The last posting from you stated "If I choose items/qtys so that it does not exceed the restrictions, everything works perfectly".

If a customer orders too many of a particular item/s then it will get to a point where ozpost can't calculate the shipping cost and give the Error and AP flat rate.

Yes, that is what it is *supposed* to do. The only other options are to return no quote at all, or a quote on a parcel that is too large for Australia post to accept anyway.

What do you think the module *should* do? Compress the parcel so that it will fit the allowed dimensions? Split the parcel into multiple parcels even though this may be physically impossible to do without damaging the goods?

A better method of 'packing and stacking' would alleviate the problem somewhat, but having already attempted several different methods, each which introduced their own problems I agree with many others in that this is the 'holy grail' of shipping modules no matter what ecommerce software is being used.. Besides, even with a *perfect* packing and stacking code, sooner or later the parcel is going to reach limits that will require you to use a different shipping method.

"ERROR: (18+53.00) x 2cm exceeds the Maximum 140cm girth allowed. Using AP Flat Rate." etc..

This is more a statement of fact rather than an error. It really doesn't matter what I do with the code, (18+53.00) x 2cm is always going to exceed the Maximum 140cm girth allowed by AustPost.

I've noticed on ebay, I believe its using the Auspost rates to calculate shipping automatically if wieght, size/dimensions have been entered for each product. The shipping calculates the same costs as ozpost, but doesn't give an error when more products (qty) are added.

If you can provide a URL I'd be happy to take a look at what is being used, and how they perform this feat, but my gut feeling tells me that it will only be quoting on weight alone.

Any update on this?
Michael

It is a trivial task to have the module ignore any size errors, simply by ignoring the calculated parcel size and substituting fixed dimensions instead. It may come as a bit of a shock when you actually go to post the parcel though.

Although I've no 'real world' data to back myself up, my hunch is that this problem will occur far more due to mulitple quantities of a single item being added to the cart than it would with single quantities of multiple items being added, and this being the case, and it is a serious issue, then the solution is to use 'bulk packing' for the items in question. By this I mean create a cart item for a box of (say) 10 somethings, and then enter the actual dimensions of these 10 items packed together so that when people buy the 10 pack the module will only see this as a single item and it won't need to use the very simple stacking code. In other words, you literally need to pre-pack the items where you are likely to get sales of multiple quantities.

As before, this will only really help minimise the error, because sooner or later we just have to obey the laws of physics.

Cheers
Rod

[dw08gm]

Hi Rod

I tried to load 2.0.5 onto 139c localhost but it would not install.

All I got was this error message

Network Connectivity test FAILED
Is cURL installed on your server? (it needs to be). If so, this may be a temporary glitch, try again in a few minutes.
Installation will NOT continue.

I have curl enabled in php5.2.9, but also tried it unenabled.

I tried switching lines 70-71 of \includes\modules\shipping\ozpost.php ie

$this->SERVER = 'ozpost.vcsweb.com';
// $this->SERVER = 'http://localhost/zencart/' ;

but to no avail. Are there other switches?

In doing the upgrade, however, I did note that one of your files was based on a 139b version.

[RodG]

Network Connectivity test FAILED
Is cURL installed on your server? (it needs to be). If so, this may be a temporary glitch, try again in a few minutes.
Installation will NOT continue.

I have curl enabled in php5.2.9, but also tried it unenabled.

There is no way that it will work without cURL.

I tried switching lines 70-71 of \includes\modules\shipping\ozpost.php ie
$this->SERVER = 'ozpost.vcsweb.com';
// $this->SERVER = 'http://localhost/zencart/' ;
but to no avail.

No reason to expect that to work either, unless you happen to be running a quotation server on your own machine :-)

Are there other switches?

No.

In doing the upgrade, however, I did note that one of your files was based on a 139b version.

Firstly, I have no idea if you are referring to an upgrade of the ozpost module, or if you are referring to an upgrade of zencart to 1.3.9b. Perhaps both.
Either way, I must ask the question, was your previous install of ozpost working correctly, and if so, what version was it.

As for "I did note that one of your files was based on a 139b version" this isn't quite true, it (actually, "they" as there are three of them) are based on a much older 1.3.7 or 1.3.8 version of zencart.
The purpose of them is clearly detailed within the .txt files that are supplied with all ozpost distribution packages.

Anyway, as for solving your problem, the error message is clearly indicating that there is (or was) a problem connecting to the server. A problem with cURL is just one of the *possible* causes of this problem. Other possible problems include temporary failure of the server, a firewall issue (client or server end), a routing/networking issue. a problem with the nameservers, and so forth.

The *first* thing you need to do though is ensure that cURL really is availalble and working. zencart has a program for this in the 'extras' folder.

After confirming that cURL is ok you/we will need to start to investigate why it can't (apparently) connect to the ozpost server. Depending on your skills/knowledge you may need to involve your webhost with this, however it is possible that there is a bug/flaw in the code that does the checking, so I propose this may be the easiest next step..

To do this, load /modules/shipping/ozpost.php into a text editor, then comment out (or delete) lines 525 - 532 and resave the file. Please report your results.

Cheers
Rod

[giftpackaging]

Hi Rod,

I'm not suggesting parcels are to be compressed to fit the dimensions of auspost requirements. But I know if you walk into a auspost outlet, with 10 items, they aren't going to give you an error and say they can't post them because the sum of the parcels is too large.

I really think your module works perfectly except for when customers either purchase an item which is too large or add too many items to the cart that then eventually exceeds the 'requirement'.

I have just put tissue reams on ebay and used the estimate postage costs. I put in dimensions and weight of 1 ream, allowed regular and registered postage options.

http://cgi.ebay.com.au/ws/eBayISAPI....m=130390584392

Click on the postage tab, and you can enter a postcode and change qty amount. On our website, it will give an error once you go over 4 reams.

[RodG]

Hi Rod,

I'm not suggesting parcels are to be compressed to fit the dimensions of auspost requirements. But I know if you walk into a auspost outlet, with 10 items, they aren't going to give you an error and say they can't post them because the sum of the parcels is too large.

This is true only if you make the each of the parcels small enough for them to accept. In *some* cases this may not be possible, ie, where a single item will exceed the allowed dimensions.

I really think your module works perfectly except for when customers either purchase an item which is too large or add too many items to the cart that then eventually exceeds the 'requirement'.

This, in itself isn't a shortcoming of the module. It is still a matter of physics.
X number of Y products is eventually going to exceed any allowable size (or weight) limitation.

I have just put tissue reams on ebay and used the estimate postage costs. I put in dimensions and weight of 1 ream, allowed regular and registered postage options.

http://cgi.ebay.com.au/ws/eBayISAPI....m=130390584392

Alas, I am unable to tell from this link exactly what it is that is being sent to the quotation servers. I am still of the strong opinion that the dimensions are being ignored.

Click on the postage tab, and you can enter a postcode and change qty amount. On our website, it will give an error once you go over 4 reams.

I understand what you are saying, but it really doesn't change anything. All this means is that unless they are using code that is too complex for me to understand (possible) the quotes that they are providing under such conditions are probably inaccurate in that it obtains a quote for a single item and multiplies it by the number of items purchased (thus over quoting when multiple items can be placed into a single package, OR it may possibly work similar to the default zencart code whereby the dimensions are non-existent/unused and the weights are simply added together and if the resulting parcel weight over the 20kg limit the purchase gets split into multiple parcels and quoted accordingly ... eg, 60kg of 'product' will be quoted at 3x 20kg parcels.

On the surface this appears to be a good working solution, until you get into the following situations (examples only).

3 items weighing 13kg each will create a 39kg parcel, which will be 'split' at the maximum weight setting (20kg) producing a quote for TWO parcels weighing 19.5kg each.
Unless one of the items itself can be cut in half (without damage) you will not be able to create the two parcels being quoted - you'd need to pack them into 3 parcels @ 13kg each - and I can assure you that the cost of 3 parcels @ 13kg each isn't going to cost the same as two parcels @19.5kg each. The postal charges simply aren't that linear.

Another example:
Suppose you have two items in your store, one weighing 19.7kg, the other weighing 400gm, and a person orders both. The total weight of both items exceeds the 20kg limit - If we split by weight we'll be quoted for 2x 10.05kg parcels. Clearly the 'best' way to ship these items would be 1x 19.7kg parcel and perhaps a 500gm prepaid satchel for the other. The shipping costs between the two methods is going to be significantly different (and it may not be possible to cut the 19.7kg item in half).

The same problem occurs when attempting to divide/split the parcels by size. There is no way of knowing if any given item can be physically 'split' or not, and this one is even harder to overcome than splitting by weight.

These are just very simple examples - The more items that get added to the cart (especially if the items are all different weights and sizes) the more complex this all becomes).

Bottom line is that although it is easily possible to prevent both weight and dimension errors by attempting to split parcels into allowable sizes, the quotes returned cannot be accurate unless the items themselves can actually be split in the same manner as the underlying code suggests they could.

I have spent literally *months* trying to find a practical solution to this dilemma, and there really doesn't seem to be one (which is why it is still known as a holy grail), so the options are 1) to report an error when limits are exceeded, or 2). Circumvent the limits (by dividing parcels in somewhat arbitary ways that may not even be possible) and then returning quotes that cannot be possibly be accurate.

I'd rather have ozpost produce error messages and accurate quotes rather than have it quote for parcels that may not be be possible in a real world situation or quotes that may be a long way from being even close to the real costs.

Hopefully this clarifies the situation a little better for you.

Cheers
Rod