ozpost shipping module

[zekin]

Because a satchel when it is flat it's 40cm long right? , but it actually have two sides, front and back, so, imagine this 40cm of front and back form a 3d shape, then this 3d shape must have 80cm , theoretically 2 x one side and 2 x adjacent side (a rectangle has 4 sides) formed by the back of satchel (40cm) and the front of satchel (another 40cm).

hmm headache.

Am I on right track?

Oh yes I think I can explain with girth

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

Girth = (W+H)*2
see max girth is 60cm because it's satchel's width 30cm x 2. If you take object's Length in consideration, it can work the same way, the max "(L + H) x 2" should be 80.

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

[RodG]

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.

Cheers
Rod

[RodG]

Oh yes I think I can explain with girth

No one asked you to.

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

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

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!

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*

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

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

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

[zekin]

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.

[zekin]

Sure...

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.

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!

[RodG]

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.

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

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.

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.

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

[zekin]

Exactly.

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

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

[lucidlee]

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.

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

[RodG]

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