ozpost shipping module

Thanks Rod, that worked nicely :)

John

curl

Is what is installed

RodG:

The cURL libraries/modules would have been installed in order for it to have worked before, and now the ozpost module is telling you that they are apparently missing (or some other networking error).
I don't know what changed but we did not renew for a long time and the expiry date kept on resetting to 55 days while I was working on the draft. Could this happen if your server rejects request from our site?

vandiermen:

I don't know what changed but we did not renew for a long time and the expiry date kept on resetting to 55 days while I was working on the draft. Could this happen if your server rejects request from our site?

Our servers - Three of them, on different networks, all running independently, will never block or reject a connection from any store. It/They need to be accessible in order to check the subscription status.

The '55 days' is a bit of a mystery too. Positive numbers are the number of days left remaining on a subscription, negative number are the days since the subscription has expired. New stores (those that have never connected to the server before are given a 60 day subscription.

I suspect that the '55 days' is perhaps a stored/cached value - but then is the question, you say it is resetting to this value, what is the value(s) that it is resetting it from?

Your screenshot show that cURL is apparently installed, so therefore it must be 'some other network error'.

Here's the thing - This problem, whatever the cause, if far more likely to be related to your single server rather than the 3 independent servers that we have spread across the globe, so looking to ozpost as being the source of the problem is pretty much going to be futile.

As for the error message Network Connectivity test FAILED
Is cURL installed?

This comes about as the result of a rather simple test. A request is sent to our server(s)
http://svr1.ozpost.net/quotefor.php?flags=get_latest_client_version
http://svr2.ozpost.net/quotefor.php?flags=get_latest_client_version
http://svr0.ozpost.net/quotefor.php?flags=get_latest_client_version

The result is expected to be
"V1.2.3". The numbers will change over time (currently V4.2.6), but the "V" is considered a constant, so as long as the 'V' exists, the test will pass. If we don't get the expected 'V' response then a network error is assumed, with 'cURL' being the prime (but not the only) suspect.

I really can't help you any more than this - For some reason, your store simply isn't getting the expected response from our servers, and it isn't our servers doing the blocking or returning an invalid result for this very simple query.

Basically. I'm at a loss.

Cheers
Rod

If I PM you the FTP/cPanel details, or send them by your contact page, would that help?

vandiermen:

If I PM you the FTP/cPanel details, or send them by your contact page, would that help?

I'd rather you didn't.

Instead, please d/load the attached .zip file, extract the contents (ozpost_test.php), upload the php into the top level folder of your store, then execute it by pointing your browser to http:/yourstore.com/ozpost_test.php?detail

This should provide some clue as to what is going on (rather than a simple 'test failed').

Cheers
Rod

Rod
I'm extending my ozpost.inc to handle another category of products. As usual I'm stuffing multiple charts into a tube but the tubes vary in size and capacity, plus I have the added joy of shipping flat packs. I'm now getting shipping quotes roughly double expected for even single tubes and I think that somehow the code is doubling the number of tubes and this the weight. Here is a typical debug output:

[parcel_build] => Parcel Created by svr1+ On Sat Feb 03, 2018 13:44 (Server Time)
Fits into Medium Tube (weight permitting)<-----------------------------------------Don't know how this is determined
Number Parcels : 2<------------------------------------------------------------------NOT Correct Should be 1
Dimensions: 75 x 8 x 8 cm<---------------------------------------------------------Correct
Weight :1.288kg = 2 * 0.644kg<----------------------------------------------------NOT Correct Should be 1 * 0.644kg
Parcel Value : $30<-------------------------------------------------------------------NOT Correct. Should be $15

====== Parcel Build (NoPack) ======
Item 1, Qty 1<-------------------------------------------Correct
Item Value $15<-----------------------------------------Correct
Item Weight 0.644kg<-----------------------------------Correct
Item Dimensions 75 x 8 x 8 (cm)<---------------------Correct
----------------------------------
Items in Parcel :2 <--------------------------------NOT Correct. Should be 1
Parcel Weight 0.644kg <---------------------------Correct
Parcel Dimensions:75 x 8 x 8 (cm)<--------------Correct
Parcel Contents Value $30<------------------------NOT Correct Should be $15

The Parcel Build (No Pack) is correct but the Items in Parcel is 2 when it should be 1.

If I add another item, also with a quantity of 1, I get this:

[parcel_build] => Parcel Created by svr1+ On Sat Feb 03, 2018 15:49 (Server Time) Fits into Large Tube (weight permitting)
Number of Items in list : 2
Number of Items in Parcel : 4
Dimensions: 75 x 16 x 16 cm
Weight :2.576kg
Parcel Value : $60

====== Parcel Build ======
Item 1, Qty 2
Item Value $15
Item Weight 0.644kg
Item Dimensions 75 x 8 x 8 (cm)
Bulk Pack Dimensions 75 x 16 x 8 (cm) ( Packed as 1x2x1 )
----------------------------------
Items in Parcel :2
Parcel Weight 1.288kg
Parcel Dimensions:75 x 16 x 8 (cm)
Parcel Contents Value $30

Item 2, Qty 2
Item Value $15
Item Weight 0.644kg
Item Dimensions 75 x 8 x 8 (cm)
Bulk Pack Dimensions 75 x 16 x 8 (cm) ( Packed as 1x2x1 )
----------------------------------
Items in Parcel :4
Parcel Weight 2.576kg
Parcel Dimensions:75 x 16 x 16 (cm)
Parcel Contents Value $60

     // Set basic parameters that don't change within the line item processing loop            $control_tare = "" ; // It is generally good to add tare to a parcel. I've disabled it here on the *assumption* that there will be no other items in the cart
            // If there are other items the ozpost servers will assume you will be packing these tubed items into the same box as other items so
            // disabling tare here isn't what it really wanted


            $tws = 204; // weight (gm) of a single small tube 73 x 8 x 8 cms
            $twm = 256; // weight (gm) of a single medium tube 75 x 10 x 10 cms < this is the original tube
            $twl = 672; // weight (gm) of a single large tube 75 x 20 x 20 cms - used instead of 5 large tubes
            $twx = 1070; // weight (gm) of a single maxi tube 97 x 20 x 20 cms - only used for shipping a combination of banners and charts
            $twf = 500; // weight (gm) of a single flatpack 70 x 100 x 2 cms - this is the original packaging from the printer - 2 sheets of kraft paper
            $twsmax = 2; // max qty charts in a single small tube 73 x 8 x 8 cms
            $twmmax = 5; // max qty charts in a single medium tube 75 x 10 x 10 cms < this is the original tube
            $twlmax = 25; // max qty charts in a single large tube 75 x 20 x 20 cms - used instead of 5 large tubes
            $twxmax = 25; // max qty charts in a single maxi tube 97 x 20 x 20 cms - only used for shipping a combination of banners and charts
            $twfmax = 25; // max qty charts in a single flatpack - only used for shipping to colleges


    // loop through $shipme items
    for ($index = 0 ; $index < count($shipme) ; $index++ ) {


        /// set parameters that are used in each loop
            $tq = 0; // the qty of tubes that will be needed
            $pcat = $shipme[$index]['category'] ; // the category of products in this line item
            $pnum = $shipme[$index]['id'] ; // the product id of this line item
            $pq = $shipme[$index]['quantity'] ; // the quantity of products in this line item
            $pw = $shipme[$index]['weight'] ; //the weight of the product (usually chartsets but may be banners or books)
            $pp = $shipme[$index]['price'] ; //the weight of the product (usually chartsets but may be banners or books)


///        if (($shipme[$index]['category'] == "1" ) && (stristr($shipme[$index]['name'], "Chart")) ) {  //  Only if category '1' and name contains 'chart'


        switch ($pcat):  
            case 1: //  Only if category '1' ie Wallcharts
                if ($pq < 3):
                    { $tw = $tws; $tq = floor($pq / $twsmax); $length = 75 ; $height = 8 ; $width = 8 ; } // special calc to handle stuffing up to 2 charts per small tube
                elseif ($pq < 16):
                    { $tw = $twm; $tq = ceil($pq / $twmmax); $length = 75 ; $height = 10 ; $width = 10 ; } // special calc to handle stuffing up to 5 charts per medium (large) tube
                elseif ($pq < 26):
                    { $tw = $twl; $tq = ceil($pq / $twlmax); $length = 75 ; $height = 20 ; $width = 20 ; } // special calc to handle stuffing up to 25 charts per large (mega) tube
                else:
                    { $tw = $twl; $tq = ceil($pq / $twlmax); $length = 75 ; $height = 20 ; $width = 20 ;} // let's give up here and go for the basic solution since actual packing will involve a variety of tubes.
                endif;
                
            break;
    
            case 7://  Only if category '7' ie Wholesale which consists of larger tubes and flatpacks
                    if ($pnum = 21): // medium tube
                        { $tw = $twm; $tq = ceil($pq / $twmmax); $length = 75 ; $height = 10 ; $width = 10 ; } // special calc to handle stuffing up to 5 charts per medium tube
                    elseif ($pnum = 20): // large tube
                        { $tw = $twl; $tq = ceil($pq / $twlmax); $length = 75 ; $height = 20 ; $width = 20 ; } // special calc to handle stuffing up to 25 charts per large tube
                    elseif ($pnum = 19): //flat pack
                        { $tw = $twf; $tq = ceil($pq / $twfmax); $length = 100 ; $height = 2 ; $width = 70 ; } // special calc to handle 25 chartsets in a flatpack
                    endif;
            break;
        endswitch;  // not this category


        if ($tq = 2): {$kraft = 250;} // half a sheet for two small tubes
        elseif ($tq > 2 && $tq < 6): {$kraft = 500;} // a full sheet for two or more medium tubes
        endif;
        
        $products_weight = (($pw * $pq) + ($tw * $tq)) / $tq + $kraft ; //(weight of one chart * qty ordered) + (weight of the tube * qty of tubes needed) + weight of kraft paper to overwrap tubes
        $parcelWeight +=  $products_weight ;
        $packageItems +=  $tq ;
        $productValue =  $pp * $pq ;
        echo "\nTube Qty = ".$tq."\n"."Tube Weight = ".$tw."\n";
        echo "\nTQ = ".ceil($pq/$twmmax);
            
        /// Finished processing this line item. let's output what we've found            
//         $width = 0    used for debugging missing data //
        $items[] = array(
            'Length' => $length * 10,
            'Width' => $width * 10,
            'Height' => $height * 10,
            'Weight' =>  $products_weight,
            'Qty' => $tq,
            'Insurance' =>  $productValue );
        $shipme[$index]  = null ; //  Mark item as done
        $NoPack = 1 ; // Treat the tubes as separate parcels - Note: Only works if only one 'item' is in the cart.  Comment out for normal packing
    } // next item

So this fail seems to be a constant factor regardless of the actual quantity of an item or the number of items in the cart. At this stage I'm suspecting a problem with ozpost.php but can't quite finger it. Certainly, the ozpost server is having trouble working out the dimensions of the bundle, ignoring the results from ozpost.inc and doubling the small dimensions of the tube willy nilly before interrogating the shipping servers. In this context the meaning of $NoPack is ambiguous to me. Whether I set it to 0, 1 or comment it out entirely the shipping calculations shown in the parcel build are all over the place but nowhere accurate.

Any suggestions?

lucidlee:

Rod
I'm extending my ozpost.inc to handle another category of products. As usual I'm stuffing multiple charts into a tube but the tubes vary in size and capacity, plus I have the added joy of shipping flat packs. I'm now getting shipping quotes roughly double expected for even single tubes and I think that somehow the code is doubling the number of tubes and this the weight. Here is a typical debug output:

The Parcel Build (No Pack) is correct but the Items in Parcel is 2 when it should be 1.

This is probably a clue. The ozpost server will only do the 'right thing' with a 'NoPack' option is there is only one item in the items[] array. If the server is reporting 2 items it can only be because there are two "items" being sent to the server.

Before calling the ozpost.inc the code creates an array of 'shipme' items, it is this array that gets passed/manipulated by the .inc file, which should then return back to ozpost.php with one item, and an empty/nullified shipme array.
If it returns with two items[] array it means that the .inc file has for some reason created two of them (the items[] array doesn't exist prior to entering the .inc code. Alternatively, if the .inc code return just one item[] , but there is still an unnullified shipme[] array then whatever is left in the shipme[] gets copied/added to the items[] array. The server then tries to perform its calcs based on the two items, one of which may or may not contain more than one item, which then get treated as products rather than parcels. Basically, all very confusing, which is why I've not tried to replicate this feature into the modules for other eCommerce systems.

lucidlee:

    /// Finished processing this line item. let's output what we've found            

// $width = 0 used for debugging missing data //
$items[] = array(
'Length' => $length * 10,
'Width' => $width * 10,
'Height' => $height * 10,
'Weight' => $products_weight,
'Qty' => $tq,
'Insurance' => $productValue );
$shipme[$index] = null ; // Mark item as done
$NoPack = 1 ; // Treat the tubes as separate parcels - Note: Only works if only one 'item' is in the cart. Comment out for normal packing
} // next item

This could be where things are falling over and the two item[]'s are being created.  I'm guessing that there should be a check added here to negate the NoPack = 1 if items[] > 1.  but doing this would cause the server to try to 'pack' the item[qty]  rather than treat it as a parcel[qty].  

Basically, the server code isn't 'smart' enough to handle multiple *parcels* and multiple *quantities* at the same time, so (as far as I can determine from the very messy hacked together code),  the 'qty x parcels' you have created are being treated as 'qty x item' by virtue of their being two items[] rather than just one item[]         

> **lucidlee:**
>
> So this fail seems to be a constant factor regardless of the actual quantity of an item or the number of items in the cart. At this stage I'm suspecting a problem with ozpost.php but can't quite finger it.

I've not made any changes to this aspect of the ozpost.php code since the day it was created, which then brings us back to the .inc code, or possibly your changes to the .inc code has exposed a bug that has always been there, but only now just revealed? 

> **lucidlee:**
>
> Certainly, the ozpost server is having trouble working out the dimensions of the bundle, ignoring the results from ozpost.inc and doubling the small dimensions of the tube willy nilly

It wouldn't be willy nilly. Computers are far more predictable than that. 

What is happening, as far as I can see, is that you have two items[].   The 1st one  having a qty of 2 x tubes, and the second having 'x' x products, and because the servers can only handle *one* item[] with 'x' tubes, and you are supplying two items, the server is treating your tubes as products, and adding them to the other product(s) so you are no longer being calculated for two tubes, but two tube sized products, that are being stacked against whatever the other item is.  


> **lucidlee:**
>
> In this context the meaning of  $NoPack is ambiguous to me. Whether I set it to 0, 1 or comment it out entirely the shipping calculations shown in the parcel build are all over the place but nowhere accurate.
> 
> Any suggestions?

In the context of more than one item[], the NoPack has no meaning or function.  In the context of only one item[] it changes the calculation from being based on (size * qty) to   (size * 1) * qty  (does that make sense?)   

My only suggestion is to ensure that there is only one item[] to be quoted for as this will allow the 'NoPack' do its job and treat the 'qty' as #of parcels rather than #of items.  

Hmm, another possibility is if you do have 'mixed' items/parcels to quote for is to manipulate the item[] as parcel data so that it has the correct weights and dimensions for the number of parcels needed, and set the qty to '1'  -  This will stop the weights/dimensions from being multiplied by the qty (well, not stop, but 1x1 = 1) - but this means you won't be quoted based on #number of tubes and that should give correct results (assuming all tubes and other items are packed into a single box for shipping). I would suggest adding a conditional when doing this, so if only a qty of tubes are needed (single item[]) then that function will continue to work as it always has been.  

So to summarize as best I can. 

One item (several charts) with 'NoPack' set the quote will be based on the cost of one tube, multiplied by the number of tubes. 
One item (several charts) with 'NoPack' NOT set the quote will be based on the size of the tube, multiplied by the quantity of items (if three charts are in a tube, then the qty of items will need to be '1'. The servers don't 'care' how many items are in the tube,     
With more than one item the NoPack is ignored, and the quote is based on the calculated size of all items and quantities of each item (this is the default behaviour).            

At the end of the day, if you use the ozpost.inc it becomes your responsibility to provide the servers the correct data needed to provide the the desired results, regardless of whether you with to use one item[] with NoPack (indicating #of parcels), or more than one item, leaving the ozpost servers to stack them into a single package.  The key point to remember is that 'NoPack' only works when there is a single item[] array.  

Hope this helps.  Its all bloody confusing to me though. :) 

Cheers
Rod

RodG:

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.

Hi RodG, Is this still a feature that works with the new my post business?

gee38l:

Hi RodG, Is this still a feature that works with the new my post business?

Sorry, but no, the Click n Send CSV support was dropped about 2 years ago (perhaps longer).
No one mourned its demise.

Cheers
Rod

Hi, I updated a site from 1.3.9h to 1.5.5f, and updated ozpost and dimensions are not showing on add a product or edit a product page anymore. Maybe you have a copy of the files I need to update or you can update it?
https://www.sydneyropesupplies.com.au

also with same site on shipping quote and checkout

PHP Fatal error:  Uncaught Error: [] operator not supported for strings in /home/srs/public_html/includes/modules/shipping/ozpost.php:594Stack trace:
#0 /home/srs/public_html/includes/classes/shipping.php(171): ozpost->quote('')
#1 /home/srs/public_html/includes/modules/pages/checkout_shipping/header_php.php(187): shipping->quote()
#2 /home/srs/public_html/index.php(36): require('/home/srs/publi...')
#3 {main}
  thrown in /home/srs/public_html/includes/modules/shipping/ozpost.php on line 594

require('/home/srs/publi...') I cant see

checkout was blank so I put back old version of oz-post and so checkout works until fixed but in the mean time, this makes admin shipping modules error, and e-go quotes dont look like they are working

p.s.
I installed 'ozpost - Version: V3.5.5' and its working fine in checkout.
Also collect_info.php was updated and dimensions are working
Also e-go is working
Also there are no error logs
I think I will leave it until later updated is required.. You may ignore the last 2 messages (unless you want to, I would be happy to continue helping diagnose fix the new version)

vandiermen:

p.s.
I installed 'ozpost - Version: V3.5.5' and its working fine in checkout.
Also collect_info.php was updated and dimensions are working
Also e-go is working
Also there are no error logs
I think I will leave it until later updated is required.. You may ignore the last 2 messages (unless you want to, I would be happy to continue helping diagnose fix the new version)

Oh boy, I fear that your v1.5.5 site may now consist of a small umber of files from v1.3.9. specifically,

/admin/includes/languages/english/product.php/

admin/includes/modules/update_product.php/

admin/includes/modules/product/collect_info.php

/includes/templates/CUSTOM/templates/tpl_modules_shipping_estimator.php

To ensure you have all the correct files please follow these steps.

1. Log into the store, navigate to modules->shipping, then click the button to uninstall the ozpost module. This is important. Dont skip it.
2. Restore the 3 admin/ files listed from the zencart v1.5.5 distro zip.
3. Delete the /includes/templates/CUSTOM/templates/tpl_modules_shipping_estimator.php file (if it still exists)
4. log back into the store and click the button to install the ozpost module (doesnt matter which version) it will/should probably be the old version that you reinstalled earlier.
   Take note of, and fix,any errors reported during the install. Almost all errors seen at this stage are folder/file permissions.
   The store and ozpost should now be fully functional and without errors.
5. When you see the notice that a new ozpost update is available click the button to perform the update.

That's it.

Cheers
Rod

@RodG - just thought you may want to have a read of this that I just posted about additional shipping options - you may have a solution.
cheers,
Mike
https://www.zen-cart.com/showthread.php?224202-Additional-Shiiping-Options-Required-in-Zone-Rates&p=1347562#post1347562

Just a heads up.
Rod Gasson, the developer and promoter of OzPost has passed away. The Ozpost service will cease as of March 2019. Please refer to https://ozpost.net.au/.

OldNGrey
an OzPost customer for many years.

To all and sundry who may read this, let me pass on a message of thanks from Gaelyne, Rod's widow. In her own words:

…please let the forum folk know I appreciated reading their comments? And I agree - he was a grumpy old bugger, opinionated, and yet very helpful. I'll miss him forever.

and that's that. For those of you who have subscribed to Rod's service and not yet acted you will not have much time beyond early February to find alternative arrangements before the servers supporting Rod's code are shut down on March 10 2019.

lucidlee:

For those of you who have subscribed to Rod's service and not yet acted you will not have much time beyond early February to find alternative arrangements before the servers supporting Rod's code are shut down on March 10 2019.

"GREAT NEWS EVERYONE!! We're still working out the details but Ozpost should be under new management and will continue to function for a long time to come. While we will continue to have the one month subscriptions for awhile until the dust is settled, the Ozpost servers will NOT be shut down and will continue to function.

VCSWEB

January 15 at 12:52 PM "
Reference: https://www.facebook.com/vcsweb

Really good news.

environment Dev: Zen Cart 156a; Apache 2.4.33; PHP 7.3.1; MySQL 5.7.21; Windows 10
environment Test: Zen Cart 156a; Apache 2.4.29; PHP 7.2.4; MySQL 5.7.24; Linux 4.15.0

packages / add-ons:
ckeditor ; clone template 1.2.0; payment module fee;
Direct bank Deposit V1.5.revised; zencart155 securepayxml (modified); ozpost v4.2.7 (partial);
ceon_back_in_stock_notifications.9 (modified); export_shipping_information_V1.3.5;
edit_orders-4.3.5 (modified); master password 4; admin log in as customer;
image checker 2.0;

vandiermen:

"GREAT NEWS EVERYONE!! We're still working out the details but Ozpost should be under new management and will continue to function for a long time to come. While we will continue to have the one month subscriptions for awhile until the dust is settled, the Ozpost servers will NOT be shut down and will continue to function.

VCSWEB

January 15 at 12:52 PM "

Reference: https://www.facebook.com/vcsweb

Good to hear, we tried installing this and it continually came up with errors. Tried getting help from Rod G, and after being belittled just gave up on the whole thing. Great if his work carries on, especially if the developer/customer communications normalise! I look forward to hearing more.

Today I was asked where to find/post sentiments and honour the broad number of contributions RodG made to Zen Cart over the years.

I've moved several collected sentiments over to a separate thread: In memory of Rod Gasson - RodG

Please feel free to share your positive memories of Rod's contributions there. He is missed!