homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / WebmasterWorld / Ecommerce
Forum Library, Charter, Moderators: buckworks

Ecommerce Forum

Package Dimensions

 7:30 pm on Aug 29, 2007 (gmt 0)

Hi im new here, this looks like a good forum so maybe you guys can help me with something thats really causing a headache.

I'm in the process of revamping a shipping estimate system for one of our clients.

We use an online service that ties into the major shippers and gives us estimates for the package dimensions and weights we pass into it.

Currently the package dimensions are calculated simply by adding all the respective values together to get the max. IE 2 items that are 6 x 6 x 6
and weigh 5lbs would calculate to a 12 x 12 x 12 10 lbs package.

This system, while far from ideal, is producing decent results. It's a lot better then no estimate but it's starting to really hurt on some packages since it's not really accurate.

I need to come up with the most accurate way to calculate package dimensions for a shipping estimate based on all items having their heights, widths, lengths, and weights as defined in our product DB.



 9:14 pm on Aug 29, 2007 (gmt 0)

It's not clear in your post whether or not your Product DB has "product" dimensions/weights or "shipping" dimensions/weights. In other words, a 16 oz net-weight widget would certainly weigh more than 16 oz by the time it's packed in a shipping container along with cushioning/void-fill material.

Likewise, multiple 6x6x6 widgets may nest into a 8x8x8 box, unless the 6x6x6 dimensions are solid cubes.

Shipping costs for smaller items can be estimated based on product weight, plus an adder for the container and packing materials. For larger items shipping in the US, the actual weight is irrelevant, as dimensional weights come into play. US Postal begins their dimensional calculations for shipments to distant zones as early as 1 cu ft packages.

The rules change based on carrier, class of service, and product mix. A database of actual product sizes and weights, along with a table of "stocked" shipping container (box) internal and external dimensions is needed to develop accurate shipping cost estimates.


 10:09 pm on Aug 29, 2007 (gmt 0)

The dimensions are for the actual product. I was leaning towards a system like you have suggested with padding for package weights.

The inventory is currently being reprocessed and better info is being added to the DB.

Would be best to just use weight / dimensional weight, depending on which is bigger, and add in some padding for the packaging? Basically only using the dimensions to get an idea of what package to use?


 2:31 am on Aug 30, 2007 (gmt 0)

Work the estimate off box sizes available. If your smallest box is 8x6x6, that's the size box a couple of screws will ship in.

Fairly straightforward:

Pick the cheapest box to ship where:
The cubic area of the box is equal or greater than the sum of the area of all the items in the box * packing material/fudge factor. Maybe 10%.
The largest dimension of the box is greater than the largest dimension of any item going into the box.
The second largest dimension of the box is greater than the second largest dimension of any item going into the box.
The third largest dimension of the box is greater than the third largest dimension of any item going into the box.

We also have items that are we call "squishable" (think a t-shirt). For those items we remove the largest dimension rules.

The algorithm is quick to run and quick to write.

We use it for determining boxes to use (as well as for our shipping cost calculations. If the data is correct, we almost never (but not never) can't fit all the items in the selected box and rarely do we select a box too large.


 11:51 am on Aug 30, 2007 (gmt 0)

Currently the package dimensions are calculated simply by adding all the respective values together to get the max. IE 2 items that are 6 x 6 x 6
and weigh 5lbs would calculate to a 12 x 12 x 12 10 lbs package.

This system, while far from ideal, is producing decent results. It's a lot better then no estimate but it's starting to really hurt on some packages since it's not really accurate.

Wouldn't the package be 6 x 6 x 12 and 10lbs. The volume of the package shud only double and this way the courrier rates will be reasonable.


 2:27 pm on Aug 30, 2007 (gmt 0)

To play it safe, add 2 inches to all three dimensions for box thickness and cushioning, then add 1-2 lbs for box/cushioning weight. Then round everything up to the nearest standard box size that you stock. Keep in mind that advertised box dimensions are for their internal size, but carrers base their charges on the box external size, which is different.


 6:05 pm on Aug 30, 2007 (gmt 0)

This is a *very* good question, one I've grappled with for a year or so.

Tell me, does an order include multiple items? Now it gets very complex.

For the record, we deal with products that range from long and narrow (think "walking stick") to "golden mean-ish dimensions" (8 X 6 X 6) to flat-ish (think "8x10 to 20 x 24 picture frame".) It can be anything, at any time.

For a single item it's a no-brainer. You enter shipping dimensions and weight for the item and store it in the database along with each product. Using this method, I only have to add a 1% padding and a calculation for the weight of the box itself. We make maybe a dollar or two on every shipment (which barely covers box costs) and seldom lose money on shipping.

But for multiple items, you have a bit of an issue with automating the calculation of final box.

True, the box's width and height should be the greatest of any item in the package. but if you start "stacking" height, you end up with a box that's extremely tall (see oversize below.) So you need to do some sort of re-sorting of the boxes.

What I do is get the greatest width and length, and calculate the total volume. I then calculate the height based on the volume divided by the width and depth:

($whole,$fractional_part) = split(/\./,$totalVolume**(1/3));
$height = ($fractional_part >= .5)?ceil($totalVolume**(1/3)):floor($totalVolume**(1/3));

However, there are still two problems. This simplified solution still "stacks" boxes, and there may be more than ample room to "shift" boxes in the stack to make for a shorter box. So I have a complex (to me!) algorithm that

1. Sorts the boxes by volume,
2. Lays in the largest w X h items,
3. based on the "last height" takes the next box in the sorted stack and lays it in the "second row left,"
4. Proceeds to lay items into the box until a height is reached that exceeds "oversize."

Oversize. Yeah. :-) Another complication. Both USPS and UPS have rules governing oversize boxes. Basically they are that if the length X the girth (wx2 + hx2) exceed a certain amount, you pay an extra charge for the box. And it's a significant surcharge over shipping them in multiple boxes.

There is also a maximum weight per parcel for both shipping services.

So, you need some method of fitting the first batch of items in a non-oversize/non overweight box, then popping off the remaining items into subsequent boxes. I have something that works, but it doesn't work that well.

USPS only requires box weight for parcels that are not oversize, but UPS requires box dimensions as well as destination city. So this is a Very Big Deal.

That's where I'm at, anyone else got positive solutions? :-)


 7:17 pm on Aug 30, 2007 (gmt 0)

I've got an algorithm that I've been working on, but it's a work-in-progress and not live on my web site. But if your web site is like mine, then:
- weights of items vary from 0.05 pounds to 60 pounds,
- dimensions are all over the map, with some items as thin as a pencil, others are cubic.
- and item densities vary, from lead to feathers.

What to do? Let's take the USPS flat-rate boxes as an example. They are available in two sizes: 11"x8.5"x5.5" (BoxSize1) and 11-7/8" x 3-3/8" x 13-5/8" (BoxSize2). You can use any box size, but I'll stick with these as an example.

I'll assume that 70 pounds is not a limiting factor for these sizes of boxes. I propose a two-pass method to "pack a box":

A BoxSize1 holds 514 cubic inches; a BoxSize2 holds 546 cubic inches. According to my testing "in the basement laboratory", 65% of that space is what you want to try to use up. So, we can pack 334 cubic inches in a BoxSize1, and 355 cubic inches in a BoxSize2; this is their UseableSpace.

1st pass: Divide the items in the shopping cart into three groups:
- those that fit into BoxSize1,
- those that fit into BoxSize2, and
- those that fit in either.

If an item doesn't have dimensions, or has dimensions that don't fit into either box, don't calculate a flat rate shipping cost for the order (use a non-flat-rate BoxSize3).

2nd pass: Based on the information gained in the 1st pass:
- sum the volumes of items that can only fit into a BoxSize1,
- sum the volumes of items that can only fit into a BoxSize2,

- if the sum for either box size is zero, don't use that type of box for the order. Simply add the volume of the remaining items to get the total volume, then divide by that box's UseableSpace to get the total boxes required.

- if both box sizes are needed, take the remaining items, sort them in descending order by volume, and one-by-one, add them to "the box size that's most-empty". This is determined by finding the smallest modulo of Sum divided by UseableSpace.

You'll then know the number of boxes of each size that the order requires. Round up any fractions of boxes, and multiply by $8.95 to get your cost.


 7:23 pm on Aug 30, 2007 (gmt 0)

Ahh so you're using the "fit in our boxes" approach! :-) Sweet, I've considered that but haven't tried it because of the added complication of keeping box sizes in the database. What do you do about those "other items" beyond the flat rate box or registered box sizes? Also what if when adding volumes, the actual dimensions of the added items don't fit? I mean, there's sufficient volume but you can't "fold up" a picture frame. :-)

Just a side note,

I'll assume that 70 pounds is not a limiting factor for these sizes of boxes.

For flat rate boxes, no, I can verify this because a friend shipped some items, I can't reveal what they are but they were a piece of exercise equipment involving SAND. Each one weighs in at over 75 lbs. :-) It cost her very little using flat rate.

Which is another complication, with both USPS and UPS there are many levels of service, each limited by box weight and dimensions, but let's stick to the whole dimensions problem for now. :-)


 7:03 pm on Aug 31, 2007 (gmt 0)

Some really good replys guys, this is a pretty complicated issue it seems. When our system was first set up i knew nothing about how to pull it off and thus have a pretty flawed approach.

These suggestions here have been very helpful so far. The hardest part seems to be choosing the right box and figuring out how to fit multiple items into it programmaticly.

Thanks everyone for your posts.


 5:38 pm on Sep 1, 2007 (gmt 0)

I certainly hope this topic continues, I know there's a numbers guy/gal out there that can tell use we're over-complicating it and "here's a simple solution." :-)

zeejay, in the "short run" here's a pretty simple solution for you.

IMO we have determined that USPS shipping is less expensive for anything a pound or less. You only begin to see reasonable savings with UPS when your packages begin to exceed 8 or 10 pounds. So if you predict that your packages will mostly be 10 lbs or less, USPS only requires a weight, origin, and destination zip code to estimate a shipping charge in real-time.

The other thing to consider is the possibility of oversize packages. If you see the potential for someone ordering enough items in one order to bump you into oversize, you need to pursue a more complex option - but if not, you should be able to get by for a while simply adding up the total shipping weight and querying the USPS API.

Global Options:
 top home search open messages active posts  

Home / Forums Index / WebmasterWorld / Ecommerce
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved