ozpost shipping module

[GAM]

Hi Rod.

I have 'constrain dimensions' enabled. 105cm may have been exceeded but the main problem for me is still the same... the calculated parcel dimensions.

On another example....

Product dims: 5 x 5 x 2.1 cm.
Quantity: 100 units
Parcel dimensions (OzPost): 5.00x2.10x100 (cm)

These 100 fittings fit into a little box or bag easily and if fractionally lighter would be shipped in a 500g satchel, but otherwise 3kg satchel. The 100cm parcel dim means no satchel option.
[EDIT: actually the product dims are smaller in reality than specified, more like 5x2x2, hence easily fitting into a small bag.]

Cheers
Greig

[RodG]

the main problem for me is still the same... the calculated parcel dimensions.

Please don't make me repeat my spiel about the holy grail of shipping modules, because that is what we all want.

On another example....

Product dims: 5 x 5 x 2.1 cm.
Quantity: 100 units
Parcel dimensions (OzPost): 5.00x2.10x100 (cm)

That looks wrong to me.
5 x 5 x 2.1 x 100 should come out as 5x5x210 (cm)

Hmmm, perhaps that's wrong too... how about...

50x50x2.1 (cm) or perhaps
50x5x210

It all depends on how they are packed/stacked. For multiple quantities of any given size this is quite easy to figure out and demonstrate. It gets *really* complicated when multiple items of different sizes are added.

Of the examples just given, which one is 'correct' and 'why'?

Can you suggest any 'rules' that can be applied by the module that will work in all cases for all users (or even most cases for most users?). If so, I'll be more than happy to lead you on your way down the slippery slope until even you give up after a few weeks/months.

These 100 fittings fit into a little box or bag easily and if fractionally lighter would be shipped in a 500g satchel, but otherwise 3kg satchel. The 100cm parcel dim means no satchel option.
[EDIT: actually the product dims are smaller in reality than specified, more like 5x2x2, hence easily fitting into a small bag.]

The solution is simple. Pre-pack these fittings into bags of 100 and sell them as such. You can still sell them singularly of course, but the customers will soon realize that buying 1pack of 100 is going to save them a fortune in P&H over ordering 100 individual items.

Besides, if someone wants an odd amount, such as say 80 .. They'll be more inclined to buy the 100 pack because the cost difference will probably outweigh the postage difference. Furthermore, as these are now prepackaged you don't need to waste time counting out 80 of them. It's a win-win, the customer will get more product for less $outlay, and you'll sell more product with less work/handling.

I really have given this a LOT of thought and consideration and honestly believe that this is the best way to go.

The difference you observe between the AustPost and the ozpost modules is where AustPost *attempted* to solve the issue by parcel splitting based on dimensions, the ozpost module no longer even tries.

I can appreciate that the old method worked well for you, but several others were reporting problems because it expected one (or more) of the items in the cart to be able to be split. (eg, quoting for a brick and a feather resulting in two parcels, each containing half a brick and half a feather, rather than one parcel for the brick and another for the feather..

Sorry I don't have better news for you on this one, but hopefully I have somehow managed to convince you that the best solution isn't in the code (aka, The holy grail) but in the pre-sales packing.

If you wish to go it alone and revert back to what AustPost used something like the following should work: (Insert in code just before the dimensions get saved as session data)

if ( $parcellengh >= 105 ) {
$parcellengh = $parcellengh / 2 ;
$parcelwidth = $parcelwidth * 2 ;
}

Half the length, double the width.

*Ideally* after this, the parcel should be re-oriented again, because the new width may now be the 'length' and *it* could possibly exceed the 105 limit itself, and if so repeat again. I think AustPost performed 2 such recursions before ending up in a black hole, but a single test *may* suffice for your needs.

Cheers
Rod.

[GAM]

Thanks Rod.

I do appreciate the complexities of this matter (we have also discussed it in the past with AusPost) and I don't want to drag it all out again. ;)

I'm aware of the pre-packaging benefits you mention but it can only be applied to a handful of items in my case. There are hundreds of different fittings that people will order in 1's, 2's, 3's... Some of the main ones maybe in 10 or 20. The 100x was for example purposes... there may be 100 'similarly' sized fittings in an order though, but to make it worse, these will be included with an item 500x200x100!!!

No easy solutions.

My head hurts with this stuff. ;) I realised earlier today that this path was trouble. I will look at the splitting as that might work out okay in many cases, however what I thought I could do for myself, as far as simple 'rules' go, would be to try something like the following.

If max dims < satchel dims
and cube < satchel max cube
and weight < satchel max weight
then offer satchel

(Customer chooses at own risk)

FYI, when I went to upgrade to latest AustPost I wasn't even expecting there to be any conditions on 'satchel' options other than weight. I was going to put the onus on the customer to choose wisely. They benefit from the lower satchel rates where reasonable instead of being charged parcel rates in ALL cases. So the addition of dimension checking was a bonus but also now a devil in disguise in my case. :)

Also considered default package sizes for 'small' items, i.e., items like fittings but realise the difficulties which your example illustrates so nicely ;)

"That looks wrong to me.
5 x 5 x 2.1 x 100 should come out as 5x5x210 (cm)

Hmmm, perhaps that's wrong too... how about...

50x50x2.1 (cm) or perhaps
50x5x210"

There is no easy answer.

Thanks again for your help and time Rod.

Cheers
Greig

[GAM]

Oh, btw, satchel issues aside, I think the parcel dimensioning is creating issues.

Although the 105cm apparent length will affect the cube (well, maybe, but that's another matter), the difference in the calculated cubes isn't going to affect the quotes, on account of the fact that the module doesn't actually use the cube data for anything other than the debug display. Only the weight and dimensions are passed to the server.

The Australia Post server must be quoting based on whatever is greater, Cube Weight (assuming calculated by Australia Post server based on submitted dims) or Actual Weight, as the quote for Express Post for the original example was around $115.00 instead of the more accurate $45-50. When I checked with the online postage calculator it seemed the quote was based on the cube weight of 12kg and not the actual 3-4kg.

This is why I am currently running both OzPost and AustPost as the customer can choose the lower of the quotes while I get this sorted out.

Cheers
Greig

[RodG]

There are hundreds of different fittings that people will order in 1's, 2's, 3's...

These aren't likely to cause any excessive dimension problems.

Some of the main ones maybe in 10 or 20.

Even lots of 10-20 shouldn't cause any excessive dimension problems if the items are less than 5cm high.

The 100x was for example purposes... there may be 100 'similarly' sized fittings in an order though,

Yes, there may be, but how often has this *actually* happened?

I do a fair bit of online shopping myself, but rarely to I ever place an order for more than a few items at a time. I *used* to, when I had my repair business, but that was also when I was buying in wholesale from a wholesaler - which is a whole new ballgame, at least as far as postage & delivery was concerned.

but to make it worse, these will be included with an item 500x200x100!!!

No easy solutions.

There's actually lots of 'easy' solutions, but none of them work in all cases, all of the time.

My head hurts with this stuff. ;)

Mine too ..... I even occasionally think I have *the* solution, until I think it through all scenarios.

I realised earlier today that this path was trouble. I will look at the splitting as that might work out okay in many cases, however what I thought I could do for myself, as far as simple 'rules' go, would be to try something like the following.

If max dims < satchel dims
and cube < satchel max cube
and weight < satchel max weight
then offer satchel

(Customer chooses at own risk)

I don't know how well this will gel with the server, which has its own ideas as to what will fit into a satchel. If the server doesn't think it'll fit, based on weight & dimensions then it won't return a quote.
However, since this is essentially a fixed cost item it wouldn't be hard to re-add it locally. Sorry. No help with this one.

FYI, when I went to upgrade to latest AustPost I wasn't even expecting there to be any conditions on 'satchel' options other than weight.

AustPost and ozpost have always used dimensions & weights.

I was going to put the onus on the customer to choose wisely.

Customers won't do that, they'll choose cheaply.

They benefit from the lower satchel rates where reasonable instead of being charged parcel rates in ALL cases. So the addition of dimension checking was a bonus but also now a devil in disguise in my case. :)

Sorry, but I've kinda forgotten what your problem was with satchels (I'm good at forgetting difficult questions and problems) <grin>.

Also considered default package sizes for 'small' items, i.e., items like fittings but realise the difficulties which your example illustrates so nicely ;)

There isn't any way to set a default package size, only a default item size.

"That looks wrong to me.
5 x 5 x 2.1 x 100 should come out as 5x5x210 (cm)

Hmmm, perhaps that's wrong too... how about...

50x50x2.1 (cm) or perhaps
50x5x210"

There is no easy answer.

I agree, and we are both so much smarter than any computer.

Thanks again for your help and time Rod.

Cheers
Greig

My pleasure.

Cheers
Rod

[RodG]

Oh, btw, satchel issues aside, I think the parcel dimensioning is creating issues.

It can't do that. The sole purpose of dimensions is to prevent issues :-)

The Australia Post server must be quoting based on whatever is greater, Cube Weight (assuming calculated by Australia Post server based on submitted dims) or Actual Weight,

This is correct - for parcels over 1kg.

as the quote for Express Post for the original example was around $115.00 instead of the more accurate $45-50.

I'll not comment on which is the "more accurate" figure until I know what the input data is/was in both cases.

When I checked with the online postage calculator it seemed the quote was based on the cube weight of 12kg and not the actual 3-4kg.

Are we still referring to the parcel that exceeded the maximum dimensions and was constrained to 105cm? If so, then the higher cubed rate will probably be correct if verified with the online postage calculator using the same dimensions.

This is why I am currently running both OzPost and AustPost as the customer can choose the lower of the quotes while I get this sorted out.

Sorry if I appear to be a little confused, but I'm a little confused as to what you need to sort out, other than doing everyone a favour and creating bulk packs of items (where suitable) and then relying on 'normal human behavior' which 'limits' the number of items purchased in any given store at any one time to no more than a handful of products anyway, which aren't likely to exceed the practical limits. Also bearing in mind that no matter how good the code is to divide/split/limit there is still nothing to prevent someone from adding more and more different things that sooner or later you'd need several trucks to ship. (ok, an exagerration).

Seriously though, If you think that you have identified a problem that is *likely* to occur during the normal course of business I'm more than willing to see what, if anything, I can do about it - But if the problem is due to somewhat unrealistic scenarious (such as bulk sales where bulk packs are not offerered) or expecting someone to purchase 100 different items in one sitting then there really isn't anything more that I can do or say, other than agree that it could be a problem, but one we need to learn to live with.

Cheers
Rod

[ozetrade]

Hi, I'm having a problem installing the ozpost module on a fresh install of ZC 139c.

My install is running on a Win32 Pro XP machine and I'm using MOWES HTTP server v2.2.3.

HTTP Server: Apache/2.2.11 (Win32) PHP/5.2.10
PHP Version: 5.2.10 (Zend: 2.2.0)
Database: MySQL 5.1.35-community
PHP Safe Mode: Off
CURL is not installed
ozpost_v2.0.6

I first did a WinMerge - I did find some minor changes to the in the ZC 139c files which I kept. Accessing the MODULE/SHIPPING through the admin panel, the Ozpost Module shows however, when I click on the INSTALL button, I get a dead page with error "The website cannot display the page". the URL displayed is
localhost/139c/admin/modules.php?set=shipping&module=ozpost&action=install

I then tried just a straight copy & paste of the ozpost package - still the same problem.

Any help appreciated
Thanks
OZ

[RodG]

I first did a WinMerge - I did find some minor changes to the in the ZC 139c files which I kept.

There are only 3 files that would possibly need merging (all located under /admin/), but unless you have other modules that also use these files you won't need to merge, simply replace the originals with the replacements.

Accessing the MODULE/SHIPPING through the admin panel, the Ozpost Module shows however, when I click on the INSTALL button, I get a dead page with error "The website cannot display the page". the URL displayed is
localhost/139c/admin/modules.php?set=shipping&module=ozpost&action=install

Not much of a clue really.

Do the other shipping modules install/uninstall OK?

Can you increase the debugging level somehow so we can get some idea *why* the page couldn't be displayed? (file not found, bad permissions, bug in code, etc, etc.

I then tried just a straight copy & paste of the ozpost package - still the same problem.

Oh shoot.... I just went to preview this post and have spotted your problem..

"CURL is not installed"

So, how did you manage to install zencart? (which complains loudly if cURL isn't available).

Cheers
Rod

[ALiepinieks]

...(which complains loudly if cURL isn't available)...

so if a "curl not installed error" appears and nobody is there to read it did it really happen?

i think the term loudly is directly proportional to the emphasis a user places on reading rather than winging it

[ozetrade]

Oh shoot.... I just went to preview this post and have spotted your problem..

"CURL is not installed"

So, how did you manage to install zencart? (which complains loudly if cURL isn't available).

Cheers
Rod

Hi Rod.

I had a feeling it might be CURL that was the issue. Yes, during the installation of ZCv139c there are loud warnings regarding the abscence of CURL. These warings do go on to say that some payment and shipping modules may not function without CURL.

I have not had an isssue with earlier versions of ZC as I've always built them on this type of platform i.e. minus CURL and I've always been able to install and configure modules - payment and shipping. I don't test full function until I upload to a host provider. I've just never aexperienced this type of install failure. I would guess it has to do with your full rewrite of the module.

Never mind. I'll upload to the host provider and check it.

Thanks
OZ