Advanced shipping calculations

[David Legg]

I'd be interested to know how people have implemented shipping
calculations on their sites.

Our site sells a variety of items weighing from 1g to several Kg and a
variety of sizes from things that fit into an envelope to things that
are over a metre long.  This means that a large number of shipping rates
could apply and calculating the best one is non-trivial as the choice of
packaging can affect the rate.

I've written some code which seems to be fairly accurate at predicting
the correct postage under most circumstances; but even I stopped short
of implementing a packing algorithm which could predict how much of an
order can fit into a Jiffy bag!  I take into account the maximum volume
of envelopes and boxes, their weight, individual item weights and
volumes etc.  I also take into account the maximum weights and
dimensions allowed for each postage rate.

How do most people cope with this situation?

Regards,
David Legg

[BJ Freeman]

I have implemented a layer of ecas, since this is the easiest way to
patch quickly these calculations, as I developed these. it also allows
me to intercept the services used in shippment calcuations.

this starts with shipping estimates and refined on shipping.
1)determine type of packing (single, multiple)
2)which shipper will handle this packages.
3)which shipper has the best delivery based on a query to their system.
  a)deliver time
  b)delivery cost
  c)insurance cost
  d)Signature required
for shipping
send data to shipper to get shipping cost
compared against sales estimate.
if under use shipper data, and complete shipping.
if over put on hold for manual determination.
#1 has the ecas to do the measurement and/or weight conversion.
start with cubic measurements for a rough estimate to find the right
CarrierShipmentBoxType for the weights, based on ShipmentMethodType.
then check for oversize rules.
Starts as a shipment total then breaks it down to items if can't find
any shippers.




David Legg sent the following on 10/18/2008 3:18 PM:

> I'd be interested to know how people have implemented shipping
> calculations on their sites.
>
> Our site sells a variety of items weighing from 1g to several Kg and a
> variety of sizes from things that fit into an envelope to things that
> are over a metre long.  This means that a large number of shipping rates
> could apply and calculating the best one is non-trivial as the choice of
> packaging can affect the rate.
>
> I've written some code which seems to be fairly accurate at predicting
> the correct postage under most circumstances; but even I stopped short
> of implementing a packing algorithm which could predict how much of an
> order can fit into a Jiffy bag!  I take into account the maximum volume
> of envelopes and boxes, their weight, individual item weights and
> volumes etc.  I also take into account the maximum weights and
> dimensions allowed for each postage rate.
>
> How do most people cope with this situation?
>
> Regards,
> David Legg
>
>
>

[David Legg]

Hi BJ,

> I have implemented a layer of ecas, since this is the easiest way to
> patch quickly these calculations, as I developed these. it also allows
> me to intercept the services used in shippment calcuations.
>  

Thanks for running through your process.  It confirms what I feared...
there is no easy shortcut to working out shipping fees ;-)

I would love to have some form of packing algorithm that could be used
instead of crudely using product volumes to determine if they would fit
a particular form of packaging.  Take an envelope for example, as you
fit more items into it the envelope's height increases and its width and
length decrease.  Even if the order will physically fit the envelope,
volumetrically speaking, the new height of the envelope may preclude
sending it as letter rate and it will have to go as large letter rate
instead.

Currently I use volume to crudely determine if an order will fit
packaging, but I've had to apply rough rules of thumb to make it work.  
For example, I downgrade padded bag volumes to 40% of the theoretical
maximum to make the calculation work.

Of course this is all fine until you come across products which aren't
particularly cube shaped.  This is where volume calculations tend to
break down when multiple products are packaged together.

Anyone come across something like this?

Regards,
David Legg

[BJ Freeman]

David, as you mentioned not hard packing container, pose a different
problem. I added a few fields as extended entities, to deal with this.
these are used in the oversize rules.
basically I set the volume to exceptable level, but usually override
based on weight, for USPS since that is the first consideration.
in the US we have hard container, that have fixed cost with no wieght limit.
and yes it takes some sophisticated algorithm to calculate a many
faceted product. have to use images and graphic tools and/or hardware.
Kind of hard to do if your not stocking the products.
the quickest way is to put the product in a sealed plastic bag then
submerge it in water, then measure the displaced water. good old Archimedes.


David Legg sent the following on 10/19/2008 5:05 AM:

> Hi BJ,
>
>> I have implemented a layer of ecas, since this is the easiest way to
>> patch quickly these calculations, as I developed these. it also allows
>> me to intercept the services used in shippment calcuations.
>>  
>
> Thanks for running through your process.  It confirms what I feared...
> there is no easy shortcut to working out shipping fees ;-)
>
> I would love to have some form of packing algorithm that could be used
> instead of crudely using product volumes to determine if they would fit
> a particular form of packaging.  Take an envelope for example, as you
> fit more items into it the envelope's height increases and its width and
> length decrease.  Even if the order will physically fit the envelope,
> volumetrically speaking, the new height of the envelope may preclude
> sending it as letter rate and it will have to go as large letter rate
> instead.
>
> Currently I use volume to crudely determine if an order will fit
> packaging, but I've had to apply rough rules of thumb to make it work.
> For example, I downgrade padded bag volumes to 40% of the theoretical
> maximum to make the calculation work.
>
> Of course this is all fine until you come across products which aren't
> particularly cube shaped.  This is where volume calculations tend to
> break down when multiple products are packaged together.
>
> Anyone come across something like this?
>
> Regards,
> David Legg
>
>
>

[Nathan C Hampton]

This is the kind of thing that makes me glad I'm a bookseller.  For  
the vast majority of my orders, a simple weight-based calculation is  
perfectly adequate!

--NCH

On Oct 19, 2008, at 11:24 AM, BJ Freeman wrote:

> David, as you mentioned not hard packing container, pose a different
> problem. I added a few fields as extended entities, to deal with this.
> these are used in the oversize rules.
> basically I set the volume to exceptable level, but usually override
> based on weight, for USPS since that is the first consideration.
> in the US we have hard container, that have fixed cost with no  
> wieght limit.
> and yes it takes some sophisticated algorithm to calculate a many
> faceted product. have to use images and graphic tools and/or hardware.
> Kind of hard to do if your not stocking the products.
> the quickest way is to put the product in a sealed plastic bag then
> submerge it in water, then measure the displaced water. good old  
> Archimedes.
>
>
> David Legg sent the following on 10/19/2008 5:05 AM:
>> Hi BJ,
>>
>>> I have implemented a layer of ecas, since this is the easiest way to
>>> patch quickly these calculations, as I developed these. it also  
>>> allows
>>> me to intercept the services used in shippment calcuations.
>>>
>>
>> Thanks for running through your process.  It confirms what I  
>> feared...
>> there is no easy shortcut to working out shipping fees ;-)
>>
>> I would love to have some form of packing algorithm that could be  
>> used
>> instead of crudely using product volumes to determine if they would  
>> fit
>> a particular form of packaging.  Take an envelope for example, as you
>> fit more items into it the envelope's height increases and its  
>> width and
>> length decrease.  Even if the order will physically fit the envelope,
>> volumetrically speaking, the new height of the envelope may preclude
>> sending it as letter rate and it will have to go as large letter rate
>> instead.
>>
>> Currently I use volume to crudely determine if an order will fit
>> packaging, but I've had to apply rough rules of thumb to make it  
>> work.
>> For example, I downgrade padded bag volumes to 40% of the theoretical
>> maximum to make the calculation work.
>>
>> Of course this is all fine until you come across products which  
>> aren't
>> particularly cube shaped.  This is where volume calculations tend to
>> break down when multiple products are packaged together.
>>
>> Anyone come across something like this?
>>
>> Regards,
>> David Legg
>>
>>
>>
>