GAM:
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.
GAM:
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.
GAM:
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. :yes:
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.
