ozpost shipping module

zekin:

Hi, just to report you, yes it fails now.

Just as you say it should. Ergo, the current methods are still valid. Nothing more needs to change until/unless someone gives me another practical example of false positives. :D

Cheers
Rod

zekin:

Oh yes I think I can explain with girth

No one asked you to.

zekin:

Let's assume L is the longest, L > W > H

Yes, the length is always considered to be the largest of the 3 dimensions.

zekin:

Girth = (W+H)*2
see max girth is 60cm because it's satchel's width 30cm x 2.

Correct. and this is where you should stop!

zekin:

If you take object's Length in consideration, it can work the same way,

We have already taken the length into consideration when we determined which of the 3 dimensions was the longest .. The reason for doing this is so that we then know the two shortest dimensions so that we can calculate the girth

zekin:

the max "(L + H) x 2" should be 80.

But this calculation isn't the girth. It is meaningless.

zekin:

I believe this is the validation check that you can make sure the box can fit in a satchel or not.

Not so. The length is always going to be the longest side, and the girth is always double the sum of the other two sides. There is nothing more to consider.

Cheers
Rod

RodG:

But this calculation isn't the girth. It is meaningless.

Not so. The length is always going to be the longest side, and the girth is always double the sum of the other two sides. There is nothing more to consider.

Cheers
Rod

Hi the purpose of "max (L + H)x2 = 80" is to check if the box can be completely fit inside the satchel and seal properly.

It's how i determine whether an item can fit satchel in real life. It's not meaningless IMHO.

RodG:

Sure... :no:

Girth = L x (2W + 2H)
The largest item that will fit (theoretically) is Length 40cm x Girth 60cm

Even though item's W & H might passed the girth test, but if L is too long, then when you try to fit your item into satchel, you can't seal the satchel (the sealable tape can't reach the other side), ie box exposed.

your rule: The largest item that will fit (theoretically) is Length 40cm x Girth 60cm
In reality , the max Length can't be 40cm unless girth is very very small 0 , eg a few sheets of 40x30cm paper. When you have stack of paper, say 500, you will build up "height", so at that time the stack of paper's girth maybe still less than 60, but i gurantee this time the satchel won't be able to sealed.

That's why I suggest the rule that if (L+H)*2 is less than 80, so you are guaranteed that the satchel can be sealed.

And the reason I suggest L+H , not L+W is because I find that you need to count on the shortest side to give best possibility for "sealable tape" to seal properly. The stack of 40x30cm paper is an excellent example.

This rule can also apply to any satchel , including fastway.

Hope this helps.

RodG:

ps. One of the aims of the ozpost module is to 'protect the merchant', so on this basis I'd rather have the module NOT show an option where it could rather than show it when it shouldn't. (is that double speak or what?)

You are hero for doing this module. Keep it up!

zekin:

Even though item's W & H might passed the girth test, but if L is too long, then when you try to fit your item into satchel, you can't seal the satchel (the sealable tape can't reach the other side), ie box exposed.

Exactly.

zekin:

your rule: The largest item that will fit (theoretically) is Length 40cm x Girth 60cm

.... and the rest of it.... (see my first reply to thisa conversation).

zekin:

In reality , the max Length can't be 40cm unless girth is very very small 0 , eg a few sheets of 40x30cm paper.

This has been accounted for.

zekin:

When you have stack of paper, say 500, you will build up "height", so at that time the stack of paper's girth maybe still less than 60, but i gurantee this time the satchel won't be able to sealed.

That's why I suggest the rule that if (L+H)*2 is less than 80, so you are guaranteed that the satchel can be sealed.

Yes, but it is no good sealing the parcel if the 'real' girth is too great.

zekin:

And the reason I suggest L+H , not L+W is because I find that you need to count on the shortest side to give best possibility for "sealable tape" to seal properly. The stack of 40x30cm paper is an excellent example.

This rule can also apply to any satchel , including fastway.

Hope this helps.

I see where you are coming from, and I think I'm going to need to sit down and think upon it a little more, because the possibilty of exceeding the real girth is one immediate drawback .. I think testing for two different 'girths' would be the most accurate solution, but that may needlessly overcomplicate the code (IMO).

Cheers
Rod

RodG:

Exactly.

Yes, but it is no good sealing the parcel if the 'real' girth is too great.

Yup, totally agree. :yes:
Thanks so much for looking into this btw.

RodG:

Good question. I don't think anyone has asked before.

It was a tough call on how to make this determination, and I ended up using the length and girth measurements. I then used a number of objects to pack the bags out to various shapes (eg, teatowels, books), taking note of how much of the length was being lost due to distortion and then adjusted numbers down to suit.

Rod, this is a topic we have actually discussed before (say 2-3 yrs ago) ending abruptly when I linked you to a site that showed that the general case for a packaging algorithm is impossibly complex to solve. But it may be possible to improve on what you currently do without entirely solving the issue. For me the main problem with your module is that it doesn't know when to stop trying to calculate the costs and we, as shopowners, have no way of setting boundaries for it to test and drop to a generic "Call for price" when exceeded.

In my case I have three differently 'shaped' products in my store: charts, which ship in tubes, B4 books, and flatpacks of charts (700 x 1000 mm). Each of these alone can cause problems, but when mixed in a single order the shipping costs are invariably absurd. Here are two common scenarios for my situation and some gratuitous suggestions which would help me, and perhaps significant numbers of others with similar problems:

1. I can and do pack up to six charts in a tube 100mm dia x 1000mm. Your software doesn't handle this properly because it doesn't understand that multiple charts can be rolled into a tube without changing the dimensions of the package and therefore adding the largest dimensions is meaningless. I think it would be really useful in this instance to have an option in the product page where I can specify how many products will fit into the tube (or indeed any defined package). This case is directly analogous to the teatowel problem you handled above. The shopowner should be able to specify the dimensions of the package and the number of a given product that will pack into it.

The shipping code will also need to test for item count and weight in order to determine the number of packages to create and then cost. I guess if (to use my case as an example) one gets an order of say 11 charts that the code will have to cost shipping of two tubes - or is it one if they are over-wrapped with paper into a single package? Fortunately I'm rarely presented with this problem so I say don't bother trying to handle such complex cases, eg a box with varying numbers of different items, or boxes of items consolidated within a bigger box etc.

2. I often get orders for a book and a chart, usually for export. You can't fit the book into the tube or vice versa but Ozpost will calculate the shipping cost at about $35 whereas in fact it will cost $60 ($35 + $25) to send it to the UK, blowing away any profit. I haven't got a simple answer for this but note that there is code out there for setting up discounts for a product when another is also purchased at the same time. Such links could be exploited to set up the "call for price" message described earlier.

I'm already happily subscribing to your postal service but if you were to find a widespread support for any of the features I've described I'm prepared to contribute towards any work you do on it.

During checkout - the message appears (no hovering takes place) and shows how may days left for the shipping module. No icon, just the text in a box, above the quote selector box. It's there each time I checkout with a test shopper.

ozmosaics:

During checkout - the message appears (no hovering takes place) and shows how may days left for the shipping module. No icon, just the text in a box, above the quote selector box. It's there each time I checkout with a test shopper.

For some reason you are missing a logo... it's called "ozpost_logo_gif" and should be found in the icons folder that holds all of the other ozpost icons.

You can restore it with an original copy from the distribution package, or, if you wish it to be a little less obvious just create an image 1px x 1px and store that in the folder (using the name "ozpost_logo_gif"

Cheers
Rod

lucidlee:

Rod, this is a topic we have actually discussed before (say 2-3 yrs ago)

I'll concede that it's a similar topic, but as I recall, the topic then was the best way to 'pack' any given assortment of items. This current thread is a lot simpler in that it is just a matter of determining 'will it fit'.

lucidlee:

But it may be possible to improve on what you currently do without entirely solving the issue. For me the main problem with your module is that it doesn't know when to stop trying to calculate the costs and we, as shopowners, have no way of setting boundaries for it to test and drop to a generic "Call for price" when exceeded.

I guess there is no reason I couldn't add a 'call for price' option should any given quote exceed a preset value.

lucidlee:

In my case I have three differently 'shaped' products in my store: charts, which ship in tubes, B4 books, and flatpacks of charts (700 x 1000 mm). Each of these alone can cause problems, but when mixed in a single order the shipping costs are invariably absurd.

It is the 'things that fit into things' that would be your biggest issue... namely the charts ...

lucidlee:

1. I can and do pack up to six charts in a tube 100mm dia x 1000mm. Your software doesn't handle this properly because it doesn't understand that multiple charts can be rolled into a tube without changing the dimensions of the package

The computer suffers a meltdown when it tries to combine multple 3d objects without altering the dimensions in any way <g>

lucidlee:

and therefore adding the largest dimensions is meaningless. I think it would be really useful in this instance to have an option in the product page where I can specify how many products will fit into the tube (or indeed any defined package).

I'm reluctant to travel this path at the moment because it can only be done by modifying the core code, which is something I'd like to keep to an absolute minimum (for ease of installation/updates)

lucidlee:

This case is directly analogous to the teatowel problem you handled above. The shopowner should be able to specify the dimensions of the package and the number of a given product that will pack into it.

Perhaps one day I'll even supply a dropdown menu for a selection of different package type/sizes ... (It HAS been considered, and several courier companies have similar inputs), but I honestly can't see this happening in the forseeable future.

lucidlee:

The shipping code will also need to test for item count and weight in order to determine the number of packages to create and then cost.

This is a good place to remind you that there are two different topics/issues at hand here... The PACKING of items and the cost to SHIP the items.

The ozpost server is predominantly concerned with producing accurate shipping costs based on any given input data. This it does.

It is for the client software that deals with the 'packing', and yes, I am also the author of the client code, but I see this more as a base code for others to build upon, whilst I concentrate more on the server code/maintenance.

lucidlee:

2. I often get orders for a book and a chart, usually for export. You can't fit the book into the tube or vice versa but Ozpost will calculate the shipping cost at about $35 whereas in fact it will cost $60 ($35 + $25) to send it to the UK, blowing away any profit.

Unless I'm mistaken, the reason why it costs $60 is because you send them as two separate items? If so, don't do that. Just find a box that'll fit both items (or tape 'em together) and send them as a single parcel, then it'll only cost what you were quoted for. :-)

lucidlee:

I haven't got a simple answer for this but note that there is code out there for setting up discounts for a product when another is also purchased at the same time. Such links could be exploited to set up the "call for price" message described earlier.

This function/feature would be best performed by another module entirely, one that detects the condition and negates all other shipping options (including ozpost)

lucidlee:

I'm already happily subscribing to your postal service but if you were to find a widespread support for any of the features I've described I'm prepared to contribute towards any work you do on it.

If things go well I'll have a lot more time to devote on the project, so who knows where it will lead.

Cheers
Rod

Dear Rod

The codes to determine whether items can fit in satchel or not, eg calculation of girth and length, and validating actual weight against satchel's allowable weight, and the information of all kinds of satchel's dimension, is it all in your ozpost server?

zekin:

The codes to determine whether items can fit in satchel or not, eg calculation of girth and length, and validating actual weight against satchel's allowable weight, and the information of all kinds of satchel's dimension, is it all in your ozpost server?

The code that calculates the parcel weights and dimensions is performed by the client code. (the store module)

The determination as to whether it'll fit a letter, satchel, or whatever is made by the server code.

Cheers
Rod

Love the module, easy to install and configure.

Few issues:

The fastway module i have for cubecart has the option to turn certain colours of label on or off and add specific handling fees for certain labels.

For our company we post large items(25kg) and sending to Grey ticket areas is often hugely expensive and sometimes not even possible as fastway uses different couriers for these areas, so we just turn them off.

Also sometimes it wont retrieve costs at estimate shipping, but if you log in with full town and postcode etc it will estimate the shipping.

So it would seem it needs town name for some costs? this is mainly for Australia post it would seem.

I would really like a option that if this cant calculate postage it offered a option to submit the cart contents to us for freight calculation and we could then submit a postage price and they could log back in and finish the transaction. Sort of like ebays "request postage cost" feature. I dont expect that from this module but if someone knows of one please let me know.

gmturner:

The fastway module i have for cubecart has the option to turn certain colours of label on or off and add specific handling fees for certain labels.

But I haven't ported ozpost to cubecart (yet) ;-)

gmturner:

For our company we post large items(25kg) and sending to Grey ticket areas is often hugely expensive

I always let the client decide whether shipping is too expensive or not.

gmturner:

and sometimes not even possible as fastway uses different couriers for these areas, so we just turn them off.

I would assume that the FastWay servers wouldn't return a quote for areas where they don't deliver.

gmturner:

Also sometimes it wont retrieve costs at estimate shipping, but if you log in with full town and postcode etc it will estimate the shipping.

So it would seem it needs town name for some costs?

All FastWay quotes require the town/suburb names. These are currently derived at the server, based on the postcodes supplied by the client. This is not the BEST option (which would be for the client to supply the suburb names) but it is close enough for most practical instances (so far).

gmturner:

I would really like a option that if this cant calculate postage it offered a option to submit the cart contents to us for freight calculation and we could then submit a postage price and they could log back in and finish the transaction. Sort of like ebays "request postage cost" feature. I dont expect that from this module but if someone knows of one please let me know.

The ozpost module aleady has the ability to disable itself if it can't obtain suitable quotes from the server, so the job is 'half done'. I don't know if there is another module available (call for shipping quote) to use under a no_quote_available condition or not.

To cause ozpost to disable itself, all you need to is enter negative values for the 'fixed cost' data.

Cheers
Rod

RodG:

I would assume that the FastWay servers wouldn't return a quote for areas where they don't deliver.

Fastway are franchises, and the ability to post a item to a certain place for a certain price falls upon the franchise owner. As our items are so large and often beyond size limits we have a special deal that allows them to go, BUT when these items are travelling to grey zones and carried by other companies etc it can lead to the local franchise losing money and it can and has led to difficulties with items getting lost, although covered by fastway insurance it is troublesome.

Because grey tickets cover like 2% of customers if that, we would prefer not to send to them or at least have them contact us so that we may work out a solution which sometimes involves greyhound bus freight and picking up from a depot which no module could ever work out. So disabling grey tickets isnt possible and not going to be possible in the near future?

gmturner:

Because grey tickets cover like 2% of customers if that, we would prefer not to send to them
<snip>
So disabling grey tickets isnt possible and not going to be possible in the near future?

Handy with a text editor? If so, make the following changes to
/includes/modules/shipping/ozpost.php

First, locate the following code segment:

case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
break;

Replace this block of code with:

case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) {

    if(!strstr($quote->description, "GREY" )) {            
    $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
    }
        break;

This will (should) prevent the Grey label quotes from showing.

Oh, I will also state that I'm really not that familiar with the FastWay pricing structure, nor the meanings of the colours of their labels, so would it be right/wrong for me to add a toggle to enable/disable all of the different colours. You also mentioned different handling fees .. again, would it be right/wrong to support a different handling fee for each colour?

Cheers
Rod

thanks seems to work, although you put a extra { in that i had to remove to make it work.

Also prices for Australia post satchels are incorrect. It gives $10 for a normal 3kg satchel and $11 for a express one. They are $10.30 and $11.70 respectively.

gmturner:

thanks seems to work, although you put a extra { in that i had to remove to make it work.

Actually, it appears I left one of them out.

The corrected code should read:

case "FWL";
if(in_array("FastWay Labels", $this->allowed_methods)) {

    if(!strstr($quote->description, "GREY" )) {            
    $handlingFee = MODULE_SHIPPING_OZPOST_FWL_HANDLING ;
       }

}
break;

gmturner:

Also prices for Australia post satchels are incorrect. It gives $10 for a normal 3kg satchel and $11 for a express one. They are $10.30 and $11.70 respectively.

The server is providing the correct quotes. I'm not sure why your store is chomping off the cents... this'll need further investigation.

Cheers
Rod

ahh right well it worked by taking it out, not sure if its causing any other side effects. Will add in the extra ones later.

Yeh im not sure why mine is quoting whole dollars and constantly rounding down. Pretty sure it didnt used to, will have to have a look later.

Hey Rod,

I notice if the function of splitting package is turned on, the quote will become whole dollar, ie cents being chopped off.