ozpost shipping module

dw08gm:

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

I seriously have no explanation, but as stated, this change won't help in any way shape or form. Its only purpose is/was for my use, and it can only work with the appropriate code on the server being defined (in this case, localhost). Without the appropriate code it will either cause a cURL error message (which is a bit misleading, as the same error will be generated even if cURL is fully functional. Strictly speaking the error should read "Unable to retrieve valid data from the server", OR, if used from the front end of the store it'll cause the module to use the 'static rates' for quoting, because it won't be able to retrieve valid quotes from the live servers.

Cheers
Rod

Hi Rod,

got the below email from my mum, are you aware and prepared for the changes?

I had a visit today from a representative from Australia Post who had been looking at our website and was wondering if there was anything they could do to help us. Anyway during the conversation it came up that Registered Post is going to be no longer as of 13th April, and the prices are going up etc. She said we would have got an email from Australia Post regarding our freight calculator on the website. I am guessing that we haven’t because the one we have is not genuine … is that correct, or have you received an email?

Apparently the option will now be to pay $2.95 for a signature (and possibly tracking) and it will be extra for insurance.

found this to back it up: http://auspost.com.au/about-us/april-price-rises.html

gmturner:

Hi Rod,
got the below email from my mum, are you aware and prepared for the changes?

Yes, I'm aware of the changes

The ozpost servers will be providing the new prices sometime during next weekend (6th or 7th Apr). I need to make some significant code changes (server side) to cater for the new International Zones, so the exact timing will depend very much on this.

The most significant/notable change that will affect most merchants is the cessation of the registered parcel service. This has been/will be replaced with the 'new' service called 'SOD' (Signature on delivery).

Due to the time it is going to take to update all of the client software to 'support' the 'new' service, the ozpost servers will be 'replacing' the registered parcel quotes with the regular parcel prices plus the SOD charges, as per the information provided by Australia Post

http://auspost.com.au/parcels-mail/new-prices.html**
"Want the same offering as Registered Post for your parcel delivery?**
Simply choose the regular product, Parcel Post, and then add Signature on Delivery or Extra Cover as optional features"

Unless demand is high I am not considering adding the new same day courier services as being a high priority addition.

It should also be noted that Australia Post are hiring stronger workers these days, and the new team can lift a massive 22kg (up from the previous 20kg limit). :)

There are also changes being made to the 'Click n Send' system, but as yet they haven't released any details, so there is a possibility that this function may get broken as a result of the changes. Time will tell.

Prepaid Express Post 3kg large and Express Post 5kg large satchels will be withdrawn from 8 April 2013. The ozpost servers will cease providing quotes for these items, which will effectively disable them as being a valid method by existing client software.

As a general rule, most ozpost users/merchants won't be affected by these changes (other than the increased costs), the only thing to be mindful of is that as of 8th April Registered parcels will no longer exist and quotes provided for this method really mean 'Regular parcel with signature'.

There will be no need to update the client software as a result of any of these changes. However, I do hope to release updated client software in the next month or so as I've recently been working on support for StarTrack Express, and may even find time to add Couriers Please and Smartsend to the list of supported carriers (plus the usual bugfixes and tweaks).

Cheers
Rod

in the last 48 hours we had 15 orders, 5 of these orders looked like this

the rest of the orders are fine (come up with ozpost postage options)
seems to be an intermittent problem, half the orders are fine at random times
nothing in-particular different about the orders
customers said it removed the postage options at paypal page
problem only in the last 48 hours

about 48 hours ago i updated the "Restrain Dimensions." to yes

after the problem was reported a few hours ago i updated oz-post to new version
and no new errors yet

Also I checked the cache, it was too big so blocked me from access (i don't have cpanel file management or anything, just ftp), so i rebuilt the cache (renamed and recreated) and waited for errors, just got allot of errors saying the database cache location was incorrect, so i fixed that and only errors since:

[03-Apr-2013 15:37:48] PHP Fatal error:  1062:Duplicate entry 'cede06403704e30b3a3afd6c61ca37f1' for key 'PRIMARY' :: 


insert into sessions
              values ('cedex6400xxxxxxc61ca37f1', '1364xxxxx8', 
'T0FZxxxxxxxxxxxxxxxxxxxJNjA3MWR4Sm5ldmx6VGNMMFdIQUhjYUx1Z3R0eVBsbERJamE3TTF5aHpuZ2FMYmhwT2g2V0tZbk85cnhWUWUzRDgwaUNOckVfaTRuR3NLXzl4YVNxcDI4X1pacnozTnhxxxxxxxxxxxxxxxxxxxxxaOUhWY0U1bW8xOFRSQXZ5T0xORjBNxxxxxxxxxxxxxxxxxxxncmhTaG90Q0lDazlhMjY5NzZPTE8xRXZTRmcxWmlFenAzeFU4S202QnlRTlE3MkY0Q0YwczJCcW9HYnUxemdlZ2ZoTmtqaDBpZlhGNmlTaFBrVGRwclUxY0lVOG5vcWwxY0FwYS1aRGRjTHpaVk1TdndSZ05BdHptZmVtUUZkQ0pUSmtHQ2xaU0wxxxxxxxxxxxxxxxMVhmeG1jZEZPTlJ0MkNzYzQxWno1Z1lEY09wc0xESThQajBaUlQtZnZaQk1GdEg0YmdEMEJnbEtQbjVTMC15NDUtOTIwdDlxxxxxmhaN2Z0UVNtRXozRGRHZzhwcTNnWGppdkd4aFRuTWhNM3BONzVXdFZwM0syME9tUjBPVHpaOG11YWJLVzNhN3RLMnI0RFNRQ1VONEk1ZXBzRExNTGNNcDZFVFpBblhSOG9DTUdsakxqLVNIQTAxxxxxxxxxxNIY25zTURkQTVvcVZQRzVzSl9kT0tYRDJQLVlzMmI5bElKVk9EWjMwd3RiUExaTUlkN3FSNS1mYkdCUmhTTHByTnBKX0NCNzFnYW14ZHZidmRWUDR0SWhjc0twNUlucDhPN2RZMVgtYy1sWHptbDhMakJSeHRfekg0eTF5MkxUZ0Z4aVAxxxxxxxxxxxxxxxR0w3NzdxaE5LaGZPX3BFWGxVWjVDMm82dUFzaFNfR2h2aUFVU3BHa1pZb0lYa3VjY2tjX1JiMkpHZEFNTU8tQmxHdHZ4YmNvbDdJS0RNRzhKRHM5Ti1lWkQ2Y1pxNnp5TV80R0MtdjMxZ01pbEZMTmgzQ0p6Sjg2QkFURHZrSGc1S2I1cE1hWGw1WVFpSVgxOXR2dXI4MzBfTk4xb2tDa3hYQXhFeHhBemt2dkdqT2FfbW5RUDhOUTNWRUZyd2VfeGxHc195aFVCSTJCazNWMFIwelRtZEVIWkVreWlVOTNCMHJDS3RSNnZiWlZTdVItUXJ3dnppNWZvb1pFa0Y0U0xvYl9vNzNRY21MeGFCRk96bDNlxxxxxxxxxVERpYzk0aGlPTkRhNGM5NXNOdy4u') in 
/home/xxxxxx/xxxxx/includes/classes/db/mysql/query_factory.php on line 101

[03-Apr-2013 16:35:28] PHP Warning:  file(/home/xxxxx/xxxxx/cache/clickNsendInt.csv) [<a href='function.file'>function.file</a>]: failed to open stream: No such file or directory in /home/xxxxx/xxxxx/includes/modules/shipping/ozpost.php on line 1495

i am going to ignore these errors.
Site seems to be working fine, and i can not reproduce the problem, but it's intermittent so don't know if its going to happen again.

vandiermen:

in the last 48 hours we had 15 orders, 5 of these orders looked like this .............

Site seems to be working fine, and i can not reproduce the problem, but it's intermittent so don't know if its going to happen again.

I also fixed some other code to do with the checkout, but I don't think it was related to the postage problem.
You may ignore my last post if it seems like not your problem, I will post a message here again if the problem continues.

vandiermen:

I also fixed some other code to do with the checkout, but I don't think it was related to the postage problem.
You may ignore my last post if it seems like not your problem, I will post a message here again if the problem continues.

Although I don't think its an ozpost problem, I'd be foolish to simply ignore the report.

Having said that, I haven't made any changes to any of the server code in recent times (at least a month or more?) so if this is new/strange behaviour it probably has more to do with your changes rather than anything else.

BTW: "i updated the "Restrain Dimensions." to yes" - Generally speaking this a bad idea (and unneccesary). I've often found that those that find a need to set this to 'yes' do so because their individual product dimensions are incorrect/invalid. Setting this to 'yes' in these circumstances will suppress the oversize parcel alerts, but this is simply hiding the real problem which will cause issues when expecting satchel and/or letter rates to work correctly.

Just something to be aware of.

Cheers
Rod

RodG:

Although I don't think its an ozpost problem, I'd be foolish to simply ignore the report.

Having said that, I haven't made any changes to any of the server code in recent times (at least a month or more?) so if this is new/strange behaviour it probably has more to do with your changes rather than anything else.

Yes we have two sites one database, one of the sites was only created a couple of months ago, it had FEC mod with missing body code to direct it through checkout. client said today the orders with missing postage came from that site.
No bad orders since fixed yesterday.

RodG:

BTW: "i updated the "Restrain Dimensions." to yes" - Generally speaking this a bad idea (and unneccesary). I've often found that those that find a need to set this to 'yes' do so because their individual product dimensions are incorrect/invalid. Setting this to 'yes' in these circumstances will suppress the oversize parcel alerts, but this is simply hiding the real problem which will cause issues when expecting satchel and/or letter rates to work correctly.

Just something to be aware of.

I set it to yes because i was told some orders were coming in a 'pickup'/postage error; but problem was with second site code. I can now turn off Restrain Dimensions, but there are a few items that need to be disassembled in to two boxes.

Question, if multiple items (all below allowed dimensions) are added to cart, but in total dimensions exceed allowed, will it crash.
I am 100% sure a few of my clients gets many multi-orders that would not fit into allowed box size.

vandiermen:

Question, if multiple items (all below allowed dimensions) are added to cart, but in total dimensions exceed allowed, will it crash.
I am 100% sure a few of my clients gets many multi-orders that would not fit into allowed box size.

Hopefully your definition of the word 'crash' is different than mine.

What should occur under these circumstances is the same as if a single item was given the same oversized dimensions, namely, the module will provide a quote based on the static rate settings, which can be set for flat rate, cost per item or cost per Kg.
If these are set to zero the module will disable itself (assumedly to allow another module to take over).

It shouldn't "crash" (meaning that it causes some kind of system or other unexpected failure).

Keep in mind that the idea of adhering to the size limitations is to protect the merchant. 'Tis better to not provide any quote at all than to provide one for a package that is impossible to create in the real world. The 'Restrain dimensions' setting (set to 'yes') will have no effect until the limits are reached, at which time further products will be added to the 'parcel' increasing it by weight alone. Sometimes this will 'work' in a real world situation (The ozpost module does a pretty poor job, compared to humans, when it comes to packing parcels of differing sizes), but sooner or later the physical world limits will apply, so user beware.

If it is common for people to order multiple items and causing this 'problem' it could be prudent to ensure the shipping estimator is displayed as a listing in the shopping cart page, as this will allow a bit of feedback to the customer that there could be a problem, by virtue of the fact that the quotes are available until they add that one product too many. :)
Depending on how common the problem occurs it could also be prudent to add a bit of shipping text to explain the situation and advice the customer to perform a checkout with the items that 'fit', then continue their shopping until they (over)fill the cart again.

Cheers
Rod

G'day Folks,

Just thought I'd mention that I have a new update to the ozpost module sitting in the wings awaiting a few people to check/test some of the new features before I archive it up into another release for the zencart downloads section.

This is a development/experimental release of the latest ozpost for ZENCART ONLY.

This update contains MANY changes since the last release (V3.4.1), most notably it has experimental support for Couriers Please, StarTrack Express and Smartsend (who supply quotes for perform bookings for Australian Air Express, TNT and Couriers Please).

Although the SmartSend options are somewhat similar to the quotes supplied directly by TNT, Couriers Please, etc, unlike these couriers, a minimum spend isn’t needed to set up an account. This may be a lot more useful to many people. The costs are comparative.

PLEASE NOTE: This is NOT a complete distribution package. It is an UPGRADE file only. In order for this update to function you MUST already have a working ozpost installation.

For those wishing to trial this update, simply download the zip file, and replace your current /includes/modules/shipping/ozpost.php file with the one contained in the .zip.

After replacing this file you MUST log into the admin of your store, then click the button to REMOVE the ozpost module (Don’t worry, almost all of your current settings will be maintained). Follow this removal by clicking on the INSTALL button, and this will update your database files with the new shipping methods.

Any and all feedback will be greatly appreciated.

Enjoy
Rod

ps. This update also better reflects the changes made by Australia Post on April 8th 2013 (new methods added, obsolete methods dropped)

Pss. Please MAKE A BACKUP of your original ozpost.php file JUST IN CASE you need to go back.

Hi Rod,

Long time between correspondence.

I've just updated my test site (ZC 1.3.9D) with OzPost 3.4.1 and confirmed it was working as it should be. I tried the BETA 3.5 and I lose the shipping estimator, such as I see no rates or shipping options after adding items.

Have you seen this error in your initial tests ?

Turing on debugging and error messages didn't offer up any clues.

I'm about to do a full clean install to ZC 1.5.1 and see what happens.

Thanks,
Mike

Mike_Dean:

Long time between correspondence.

Yeah. Ages.

Mike_Dean:

I've just updated my test site (ZC 1.3.9D) with OzPost 3.4.1 and confirmed it was working as it should be. I tried the BETA 3.5 and I lose the shipping estimator, such as I see no rates or shipping options after adding items.

Have you seen this error in your initial tests ?

I've not seen or experienced it for myself, but the problem appears because the /cache/ folder is unwritable.

I think the deeper issue is that the 'define' path isn't set when I'm trying to use it. The end result is the same. The installer isn't able to write its files to the cache folder, leaving an incomplete install.

The ozpost module gets the folder name from the 'DIR_FS_SQL_CACHE' constant (in the configure.php files)

That should fix the problem.

Cheers
Rod

ps. latest beta is v3.5.0**f **

Hi Rod,

Thanks for replying and apologies for my delay in showing appreciation.
Not long after starting my upgrade process my pc fritzed itself and I'm just back to where I started with test sites etc.

I've now got my 1.3.9d site and also a clean 1.5.1 site locally.

My plan is to get your latest version of ozpost (hopefully 3.5.0f) working on my 1.3.9d and publish that update to my live site and then start on a brand new site, new look etc....

Soooooo back to the original issue with losing the shipping estimator on 1.3.9d when trialling 3.5.0f.

Am I reading correct that if I change the permission of the cache file, that should resolve the issue ? or did I miss something in the translation ? :-)

Thanks,
Mike

Update...

Installed 3.4.1 on ZC 1.3.9d and it worked fine.
Uploaded the ozpost.php file for 3.5.0f and I lose the shipping estimator :lookaroun:lookaroun

On a clean 1.5.1, initially installed OZ 3.4.1, checked, all good. Uploaded the 3.5.0f ozpost.php file, removed and re-installed via Admin and Viola, all good..
Its returning rates via the shipping estimator and I can complete the order process.:smile:

Mike

And some more info to dwell on.

I should have made mention of this error when I do the remove/install via Admin on 1.3.9d with 3.5.0f installed

Warning The file (C:/wamp/www/zencart139/admin/includes/languages/english/product.php) has already been modified. This alert can be ignored
Warning The file (C:/wamp/www/zencart139/admin/includes/modules/update_product.php) has already been modified. This alert can be ignored
Warning The file (C:/wamp/www/zencart139/admin/includes/modules/product/collect_info.php) has already been modified. This alert can be ignored

Success Ozpost v3.5.0f Installation successful.
You will need to modify the settings and press UPDATE to complete.

I neglected to mention it, as the last part This alert can be ignored had me doing just that.. But perhaps its pertinent as the same error warning is not thrown up on ZC 1.5.1 using OZ 3.5.0f

Mike_Dean:

And some more info to dwell on.
Warning The file (C:/wamp/www/zencart139/admin/includes/languages/english/product.php) has already been modified. This alert can be ignored
< snip>
I neglected to mention it, as the last part This alert can be ignored had me doing just that.. But perhaps its pertinent as the same error warning is not thrown up on ZC 1.5.1 using OZ 3.5.0f

Do you remember way back in the distant past when you 1st installed the ozpost module? You were required to ether edit or replace some files in the /admin/ folder? Well. the newer code doesn't require the user to do this because the installation code does this automatically.

So, what this warning/alert is telling us is that those files have already been modified from one of the earlier installations and don't need to be modified again.

Mike_Dean:

Success Ozpost v3.5.0f Installation successful.

If you get to see this message you can be pretty confident that you have a good/working installation.

Cheers
Rod

Hi Rod,

I think I have sorted it..

I went through and manually removed all files that were affected by the ozpost module, replaced them with the original core files, then installed 3.4.0 and let it upgrade the db to 3.4.1.

Confirmed all was ok, then planted the ozpost.php file from 3.5.0f and its seems to be working (kinda)

A couple of points, not sure if this one is a feature or a bug ?

1. If I enter a postcode, wait a few seconds and then from the presented list, click on one, a rate is returned, all good. But if I hover my mouse back over the country code, or postcode selector area, it clears the rates that were returned and re-presents the available suburbs for the entered postcode, and I can lather rinse and repeat the process over and over...

Tried it on both Firefox and IE and the same result.

2. There is no boarder around the rates, is that intentional or has my css screwed up ?

Loving it so far (apart from above 2 points.!)

Thanks,
Mike

Mike_Dean:

I went through and manually removed all files that were affected by the ozpost module, replaced them with the original core files, then installed 3.4.0 and let it upgrade the db to 3.4.1.

That'll get rid of the "alerts" for good (mostly). There wasn't a need to do what you did, but it is/was a good thing to do.

Mike_Dean:

Confirmed all was ok, then planted the ozpost.php file from 3.5.0f and its seems to be working (kinda).

Oooeerrrr... 'kinda' implies a problem has been found <g> :(

Mike_Dean:

A couple of points, not sure if this one is a feature or a bug ?.

A feature, definitely a feature.:smartalec:

Mike_Dean:

1. If I enter a postcode, wait a few seconds and then from the presented list, click on one, a rate is returned, all good. But if I hover my mouse back over the country code, or postcode selector area, it clears the rates that were returned and re-presents the available suburbs for the entered postcode, and I can lather rinse and repeat the process over and over...

Tried it on both Firefox and IE and the same result.

That is to provide a means for the customer to select a different suburb in case they make an accidental choice, for example, North Adelaide vs West Adelaide.
If the same suburb is selected the screen should instantly redraw using the previously retrieved data.
If the same suburb is selected 3 times it 'locks' that suburb in, until the postcode is changed.

Mike_Dean:

2. There is no boarder around the rates, is that intentional or has my css screwed up ?

That'll be a CSS issue (probably related to the 'table' displays).

Mike_Dean:

Loving it so far (apart from above 2 points.!)

Thanks. I'm looking forward to making this one available for the masses. I've gone back over my notes, and unless I'm mistaken, this current update supports just about every feature ever asked for (where possible). :)

Cheers
Rod

Hi Rod,

Help if I may ask for it !

I want to remove the following from the shipping estimator

(1.21 Kgs) CANTON BEACH 2263

and replace it with

Delivery to:

Reason, I often drop ship so its probably better off not having this showing;

I edited the tpl_modules_shipping_estimator.php file at line to the following: Its probably a crude way to do it, but it works. is there a better way ?

Perhaps its a feature/option that can be added to the admin side of it ?

//if(isset($_SESSION['parcelweight'])) echo "(".$_SESSION['parcelweight']. " Kgs) " ;

// echo MODULE_SHIPPING_OZPOST_ORIGIN_SUBURB . " " . MODULE_SHIPPING_OZPOST_ORIGIN_ZIP . " to " ;

echo " Delivery To " ;

I commented out the second line above, in case I decide to put it back, at least then its just a matter of un-commenting the line..

Thanks,
Mike

Mike_Dean:

I edited the tpl_modules_shipping_estimator.php file at line to the following: Its probably a crude way to do it, but it works. is there a better way ?

The way you did it was the correct approach. There isn't a better way, at least not at the moment.

Cheers
Rod

Hi
I have a similar problem and have run your script and get the following

http://ozpost.net.au OKAY > V3.4.1

Query : http://ozpost.net.au/postage.php?flags=get_latest_client_version
Connect Time : 0.716171
Name lookup Time : 0.508103
Total Time : 1.038441
########################################____
http://ozpost.net OKAY > V2.9.9 PLEASE UPGRADE

Query : http://ozpost.net/postage.php?flags=get_latest_client_version
Connect Time : 2.16667
Name lookup Time : 2.14974
Total Time : 2.263095
########################################____
http://svr0.ozpost.net OKAY > V3.4.0

Query : http://svr0.ozpost.net/postage.php?flags=get_latest_client_version
Connect Time : 0.314644
Name lookup Time : 0.103429
Total Time : 0.581539
########################################____
http://svr1.ozpost.net OKAY > V3.4.1

Query : http://svr1.ozpost.net/postage.php?flags=get_latest_client_version
Connect Time : 0.131729
Name lookup Time : 0.115364
Total Time : 0.226604
########################################____
http://svr2.ozpost.net OKAY > V3.4.1

Query : http://svr2.ozpost.net/postage.php?flags=get_latest_client_version
Connect Time : 0.315294
Name lookup Time : 0.105151
Total Time : 0.626305
########################################___

Everything seems ok, so any suggestions to what my problem might be.

Thanks a lot
John