ozpost shipping module

RodG:

What version of ozpost are you using?
What version of ZenCart?

Cheers
Rod

it is the lastest version and zen cart verion 1.51

louisapple:

it is the lastest version and zen cart verion 1.51

Please clarify the version of Ozpost that you are using? The 'latest version' available for download is V3.4.0, but those that make use of the auto-update functions of the module will be using the latest latest version, which is V3.4.1.

Also, if you could supply a link to your store I'll be in a better position to do some testing on your behalf.

For what its worth, I've not heard of anyone experiencing this particular problem before.

Cheers
Rod

RodG:

Please clarify the version of Ozpost that you are using? The 'latest version' available for download is V3.4.0, but those that make use of the auto-update functions of the module will be using the latest latest version, which is V3.4.1.

Also, if you could supply a link to your store I'll be in a better position to do some testing on your behalf.

For what its worth, I've not heard of anyone experiencing this particular problem before.

Cheers
Rod

thanks for you reply, here is my site http://igrab.com.au/

Hi,

Please help me i am using abbington_mega in zencart v 1.5.1. I want to use free shipping all India's state and i add two Payment Zone for payment in All India. 1st All India (where i want my payment through Netbanking) 2nd Delhi & NCR (where I want my payment COD ) When I select in Payment Module COD -> Zone All India It show in payment Information. and When I select Delhi & NCR It not show in Payment information.

Please intimate to me how I can solve it for Delhi & NCR payment.

Hope you will help me.

Thanks with Regards,

Rajesh

Hey Rod,

Thank goodness I found the real OzPost after wasting my time with another module.

Installing the OzPost module was easy, however since then it doesn't seem to update any changes I've made to the settings. I've attempted removing it (inc. the Complete removal method) but it isn't rectifying the problem.

This first occurred when I decided to try disabling all but international shipping methods, figuring that for an Australian (domestic) delivery I'd get nothing (except my existing table method...which I'm looking to replace). After updating the settings it still showed me all OzPost domestic delivery options. I removed the module (as mentioned) and reinstalled it but the same issue occurred. I saw a mention of enabling debug resolving some possible caching problems so I tried that too.

I also change the Estimated Delivery Format to days and this change wasn't updated either - it still shows estimate date.

I'm using Zencart 1.50 and OzPost V3.4.0 - the site is: http://www.palmoilfreeproducts.com.au

Any ideas what could be going on?

Troy.

...Not sure what I did, but it seems to have resolved itself (I also upgraded to V3.4.1).

Troy.

louisapple:

thanks for you reply, here is my site http://igrab.com.au/

It looks like you are using the 'Australia Post' module. This forum is the support area for 'ozpost'. Sorry, I can't help.

Cheers
Rod

escapedape:

Any ideas what could be going on?

Yes, there was a bit of a glitch in the installation/update code a while back. Nothing too serious, and easy to fix.

Basically the initial install/update routine would end before the database files were being updated, this left the system in a state where the DB and the zencart files would be out of sync. The solution being to simply perform a remove/install keypress sequence (NOT a complete removal, which essentially sets up the same problem condition). This simple act is/was enough to get things back to normal.

Cheers
Rod

escapedape:

...Not sure what I did, but it seems to have resolved itself (I also upgraded to V3.4.1).

It was the upgrade process that solved the problem. This process has the same effect as the remove/install I mentioned in my previous reply.

Thanks for letting me know that the problem has been solved.

Cheers
Rod

escapedape:

...Not sure what I did, but it seems to have resolved itself (I also upgraded to V3.4.1).

Did you happen to note any errors/warnings during the upgrade?

The reason I ask is that it appears that at least one of the 'support' files is still the original ZenCart code. The file in question being 'tpl_modules_shipping_estimator.php'.

The module will work just fine with this original code, but it works somewhat better with the enhancements, which includes things such as removing the unused (by ozpost) 'State/Province' selector, and replacing it with an AJAX driven Suburb name selector (which is a semi-required input for the courier quotes).

It also makes a few improvements to the actual output display, by using <divs> rather than tables for the formatting, as well as alternating background colours for the rows.

In almost every case so far, the failure for this file to get updated is due to a permissions problem. The file needs to be writable to the webserver process during the ozpost install/upgrade process.

TIP: As long as the ozpost module has the setting for 'upgrade' rather than 'remove', you can perform the remove/install keypress sequence as often as you like and it will have no effect on your settings, they will remain intact. This makes it easy to take care of one permission problem at a time (if need be), without fear of losing your current settings.
By repeating the process until all warnings go away will ensure you have a 100% successful install of all of the support files.

This same remove/install process can be used if you ever do a zencart upgrade/reinstall too (which would overwrite the ozpost modified files).
The ozpost remove/install process will then update the updated files. In short, unlike the earlier ozpost modules (and all the current Austpost modules), the current ozpost module means that no one need ever edit any of the core files just to get things going. Hopefully this all makes sense. :)

Cheers
Rod

Hey Rod,

Thanks for all your feedback everything seems to be working fine now - although we're often getting a "WARNING: An Error occurred, please refresh the page and try again." when we select "Continue checkout" after selecting the shipping method although a refresh resolves the problem.

I didn't see any errors during the upgrade. I'll update the tpl_modules_shipping_estimator.php file to the new version too - it's like that because I tidied up the layout a little.

By the way - the "Australia Post" module is just the standard Table Rate renamed (table rate is a bit meaningless to shoppers).

Regards,
Troy.

lj20272:

I'm looking at moving over to e-parcel or click and send. Is there a specific add on to enable the export/import of data. Ideally a system that would update orders with tracking numbers etc etc.

If not, what procedures are you using to make using these systems a breeze?

Is there anyway ozpost exports or imports data for the e-parcel or click and send system. I did not think there was and its not needed, but can't hurt to ask as there is a reference to it doing so.

Solar Camping Australia asks the following question

The fastway calculator does not work in the same way Fastway calculator calculates its freight.

Let me try and explain.

Fastway has different coloured labels for different areas.

In the local area the one coloured label covers 25kg's this is working.

In other areas the coloured labels cover 5kgs and for extra 5kg weights up to 25kg's a saver label is added.

We have the situation where some combined parcels exceed the 25kg max weight. The system just adds another saver label but fastway will not carry items over 25kg's.

The maximum number of saver labels can only be 4. Which will consist of one coloured label and 4 saver labels to equal 25kg's.

So to send 30KG's the parcels need to be split into two coulured labels one on each parcel and two saver labels on each parcel. This will equal 15kg's per parcel.

http://www.fastway.com.au/pricing/quick-quote/quick-quote-result?PickupRF=BDB&DeliverySuburb=CORRIGIN&Weight=30&Postcode=6375&Length=&Width=&Height=

Corrigin, 6375

If you check the fastway link to enter wide bay as the dispatch point you will get an idea of what I mean.

Then put 2x150w panels in the basket and use this town and postcode you will see the calculation difference.

See how you go.

If you need more info please let me know.

We have lost a fair bit of money over the years because of this error.

We have just had another order one to this area and will loose another $55.00 plus because of this error.

I would be interested in your findings.

vandiermen:

Is there anyway ozpost exports or imports data for the e-parcel or click and send system. I did not think there was and its not needed, but can't hurt to ask as there is a reference to it doing so.

The ozpost module has had this support since V3.2.0 (Feb 2012)

It is enabled/disabled via the ozpost setting menu, and it will create a CSV file suitable for importing into the Click n send system as and when orders are placed. This CSV file (actually there are two of them, one for national one for international) can be downloaded to your computer by the link(s) that will appear under the 'customers' menu if/when the files exist.

They can be directly imported into the C 'n' S website.

Cheers
Rod.

ps. This part of code has undergone several changes in the last 12 months as a result of Click n Send making changes to the file format. Initially they used a single file for both National and International, then they changed it so it needed a different files for each, and earlier this year I noted they changed it again to allow both the single file for both, or one file for each (user choice). THe current ozpost module (V3.4.x) only supports the two file formats.

vandiermen:

Solar Camping Australia asks the following question

"We have the situation where some combined parcels exceed the 25kg max weight. The system just adds another saver label but fastway will not carry items over 25kg's."

The ozpost server will not provide FastWay quotes for parcels over 25Kg (deadweight) or 40kgs (cubic weight).

   if (($deadweight <= 25000) && ($cubeweight <= 40000 )) {
   _getFastWayQuotes() ; 
}

The weights above are in gms.

The maximum number of saver labels can only be 4. Which will consist of one coloured label and 4 saver labels to equal 25kg's.
So to send 30KG's the parcels need to be split into two coulured labels one on each parcel and two saver labels on each parcel. This will equal 15kg's per parcel.

The ozpost system does not and will not attempt to perform any 'parcel splitting'. This has been tried using many different methods in the past. I've lost count of the number of hours I've spent on this before coming to the conclusion that any solution seems to cause more trouble than the problem trying to be solved.

Using this customers example, yes sure it'll be possible to quote a 30kg parcel as two separate 15kg parcels, but what if the parcel only contains one item weighting 30kg? Are they going to physically cut this item in half for shipping purposes? What about a parcel with two items. One weighting 20kg, the other weighing 5kgs?. Separately, one item could cost (say) $20, and the other costing $50, but the combined cost (if sent in a single parcel) the total cost may only be $55. Which quote should be provided? The single parcel quote (which is with acceptable limits), or the two separate parcels that will probably/possibly be more convenient for the merchant?
This is just a simple example.. What if there are 3 items in the parcel, say 10kg each item? Should we quote for 3x10kgs parcels, or 1x 10kg parcel and one 20kg parcel? No matter which way it gets quoted, it will be wrong 50% of the time. The ozpost system takes the 'safe' way in order to protect the merchant, since the total weight is more than will be accepted by the courier, the module will not provide ANY quote (for this courier).

Even this 3 Item spit wouldn't be too difficult to handle programmatically, but as more and more items of various weights (and dimensions) get added to the cart (some of the items being rather heavy and 'unsplittable') the problem becomes far too complex for my brain to handle, which is why after several years of trying, I simply gave up on it and reverted to the 'single parcel only' method, and if the 'single parcel' exceeds the courier limits, it simply won't provide a quote for that particular parcel/courier.
In short, it places the actual shipping costs back on the merchant, rather than provide an incorrect quote, or a quote for an parcel that can't be delivered anyway.

We have lost a fair bit of money over the years because of this error.
We have just had another order one to this area and will loose another $55.00 plus because of this error.

This should never happen. The ozpost system is based on two principles.

1. PROTECT THE MERCHANT FROM UNDERQUOTING.
2. Provide accurate quotes for the customers.

If the customer/merchant finds that the ozpost system fails with either of these principles, it means either there is a bug in the system, in which case I'll take care of the problem as soon as I can prove/replicate it, or, the most likely and most common cause is due to INVALID PRODUCT DATA.

In this case, everything is pointing to invalid product data, simply because the client is making a claim that the module is quoting for a parcel weight that is explicitly disallowed by the server code. In other words, their products weigh one thing, but they are being quoted for something different.

What they need to do is enable the ozpost 'DEBUG', and take a close look at what is actually being sent to the servers. This will/should provide a clue as to which product(s) contain the invalid/incorrect data.

Alternatively, if you/they can provide me with a link to the product(s) that are being underquoted, along with the destination postcode and suburb that will show the problem, I'll be more than happy to take a look at things for myself which will either show that there is a server/quote error, or more than likely, I'll be able to see (and report) exactly why they are getting the apparent incorrect quotes.

Cheers
Rod

Hi Rod,

Sorry to nag you, we're often getting a "WARNING: An Error occurred, please refresh the page and try again." when we select "Continue checkout" after selecting the shipping method although a refresh resolves the problem.

Is there some sort of time-out issue talking to the server? Is there someway to increase this?

Regards,
Troy.

escapedape:

Sorry to nag you, we're often getting a "WARNING: An Error occurred, please refresh the page and try again." when we select "Continue checkout" after selecting the shipping method although a refresh resolves the problem.

This is not typical of any known ozpost errors. It is more often associated with a server error of wherever your site is hosted.

escapedape:

Is there some sort of time-out issue talking to the server? Is there someway to increase this?.

The ozpost system consists of three different servers on three different networks.

From the ozpost FAQ file

Q. Is the ozpost server down?
A. No.

Q. What makes you so sure the server isn’t down. Isn’t that being a bit presumptuous?
A. Although it is quite possible this website may be inaccessible at times (no server is infallible, and there may be network or other issues outside of our control), we can be pretty confident that the quotation server is fully functional. This is because we do not rely on a single server. At the time of writing this we currently maintain three different servers on three different networks (one of them hosted on an Australian based ‘cloud’ server). The likelihood of all these servers on all networks being inaccessible at the exact same time is so remote that it is hard to imagine. If your store is unable to connect to any of them, the problem is far more likely to be at your end of things rather than ours and the inability to connect to our servers is the least of your problems. A DNS issue is the most likely cause. Such issues, if they occur, generally resolve themselves within minutes.

Increasing any timeouts won't solve your problem. It'll simply cause your customers to wait a little longer until they get the timeout error.

Cheers
Rod

Hi Rod

The last time I installed this mod was OzPost 2.3.3 for 139h. Although this store never went live since it was never completed, the following edits were made in \includes\modules\shipping\ozpost.php

1. To enable working on localhost, Line 81 was changed from

    $this->SERVER = 'ozpost.net';

to

//  $this->SERVER = 'ozpost.net';
    $this->SERVER = 'localhost/myshop/' ;    // local testing

2. To disable mod when certain categories (art products requiring specialist shipping, not subject to default Flat Rate) are in cart, after Lines 91-92

// disable only when entire cart is free shipping
   if (zen_get_shipping_enabled($this->code))  $this->enabled = ((MODULE_SHIPPING_OZPOST_STATUS == 'True') ? true : false);

was inserted

// bof disable for certain categories in cart
    if (IS_ADMIN_FLAG == false) {
      if (($_SESSION['cart']->in_cart_check('master_categories_id','4') > 0) ||
          ($_SESSION['cart']->in_cart_check('master_categories_id','5') > 0) ||
          ($_SESSION['cart']->in_cart_check('master_categories_id','6') > 0))
		  {
          $this->enabled = false;
		  }
		}
// eof disable for certain categories in cart 

Now I wish to apply similar functionality to \includes\modules\shipping\ozpost.php of OzPost 3.4.0 for 151 version of same store, and am seeking confirmation whether same code as above can be applied to around line 240. If so, but code needs to be changed, can you please provide appropriate code?

Thanks

dw08gm:

1. To enable working on localhost, Line 81 was changed from

$this->SERVER = 'ozpost.net';

> to
> ```
//  $this->SERVER = 'ozpost.net';
    $this->SERVER = 'localhost/myshop/' ;    // local testing

This won't work for you (or anyone other than myself), simply because I'm the only one with the server code on my localhost.

dw08gm:

2. To disable mod when certain categories (art products requiring specialist shipping, not subject to default Flat Rate) are in cart, after Lines 91-92

// disable only when entire cart is free shipping
if (zen_get_shipping_enabled($this->code)) $this->enabled = ((MODULE_SHIPPING_OZPOST_STATUS == 'True') ? true : false);

This is 'standard' code that can/should be found in all shipping modules (only the 'define' will vary).   

> **dw08gm:**
>
> was inserted
> ```
// bof disable for certain categories in cart
    if (IS_ADMIN_FLAG == false) {
      if (($_SESSION['cart']->in_cart_check('master_categories_id','4') > 0) ||
          ($_SESSION['cart']->in_cart_check('master_categories_id','5') > 0) ||
          ($_SESSION['cart']->in_cart_check('master_categories_id','6') > 0))
          {
          $this->enabled = false;
          }
        }
// eof disable for certain categories in cart 

This code example is also applicable to any other shipping module that utilises the $this->enabled variable. The category numbers will vary from store to store though.

dw08gm:

Now I wish to apply similar functionality to \includes\modules\shipping\ozpost.php of OzPost 3.4.0 for 151 version of same store, and am seeking confirmation whether same code as above can be applied to around line 240. If so, but code needs to be changed, can you please provide appropriate code?

The actual line number will vary greatly from module to module and version to version. The code isn't ozpost specific (I probably used an example provided by Ajeh for another module when I provided this info to you).

Simply put, the $this->enabled variable is just a switch to enable/disable the module(s). The "if (zen_get_shipping_enabled($this->code))........ " turns this switch off/on dependent on the admin configuration settings, and you place whatever code you like in the lines that follow to turn it off/on according to store specific needs. In the example given, it will be disabled for category numbers 4,5 and 6.

Does that help?
Cheers
Rod

RodG:

This won't work for you (or anyone other than myself), simply because I'm the only one with the server code on my localhost.

Yes I realise this. IIRC, back then, this code ($this->SERVER = 'localhost/myshop/' ;) was inserted to enable working on my localhost setup while NOT connected to the internet. Otherwise I would continually get cURL error and server not found messages unless connected to the internet. Unless there is another way around...