ozpost shipping module

[RodG]

...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

[escapedape]

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.

[vandiermen]

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.

[vandiermen]

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/qu...&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.

[RodG]

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.

[RodG]

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

[escapedape]

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.

[RodG]

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.

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

[dw08gm]

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

[RodG]

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.

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).

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.

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