Looking a module that supports a product's dimensions: height / width / depth

My client wants to have, as part of the product info, the product dimensions, Height/Width/Depth.
so i'm looking for a module that would support that.

can anyone recommend such a module?

We haven't discussed completely but i think the dimensions would be used in calculating shipping costs.
aye,,,,!

There's a lot more to it than just collecting dimensions.

It gets more complicated when you start discussing why you're collecting that info ... such as what do you intend to do with it.

ie:

• if it's only for display purposes so the customer has that information, then the dimensions are probably already part of your description. And "product" dimensions might be very different from "shipping dimensions".
• if it's for shipping, then does your shipping quote module support dimensions as well? (who is your carrier of choice?)
• what if your products can be packaged into one larger box? Do you have a magical calculator that will determine what size box that'll all fit into, and then submit THAT larger box size to your shipping quote module? Or does your shipping carrier's online quoting system already handle those calculations for you based on custom box sizes you've programmed on their end?

I have the same problem with USPS. Two of my categories of products (CatA & CatB) fit into an International Large Envelope. A third category of products (CatC) is too thick to fit in that class. It has to go in a box as a First Class Package. The problem is that customers will choose the Large Envelope option leaving me to pay the difference in postage from Envelope to Parcel, which is sometimes double what they pay.

Adding weight or "dimensional weight" to the item description is a hack, and backfires with other calculations and draws complaints of high shipping costs, and abandoned carts.

My box is 3oz and is entered in the tare weight, but that skews the estimator for the Large Envelope rate. Adding attribute flat fees also drives up the shipping costs for customers that buy several items.

It seems like a really simple solution to feed dimensions of products or category preferences to the USPS so it can negate the Large Envelope option if the dimensions are over a half inch thick.

everythingtiny.com
ZC 151
Numinix Google Merchant
Numinix FEC
Cross Sell Plus

Herbert Hoover:

It seems like a really simple solution to feed dimensions of products or category preferences to the USPS so it can negate the Large Envelope option if the dimensions are over a half inch thick.

Yes, that IS really simple.

The hard part is having the store calculate the dimensions, box sizes and number of boxes needed for carts that have multiple items of varying dimensions in them, and I've a lot of experience with this. It is NOT an easy task. In fact it is without a doubt the most difficult programming challenge I've ever had to deal with.

The more items added to a cart, the more difficult it gets.

Cheers
Rod (Developer of the 'ozpost' shipping module)

Dimensional Shipping Option 1
Perhaps an index is all you need to add to the various products. Call it the** dimension_index** field.

Then your products pile up in the cart and it provides shipping options based on a calculated** dimension_value**.

So, customer comes to the cart adds one DVD, dimension_index is 1. They go to the cart, it sees there's only 1 DVD with dimension_index 1 and assigns a dimension_value of 1. The shipping modules look for dimension_value before they become available**.** The customer gets one choice... an envelope.

But wait, they want to add a skateboard to their 'How to Ride' DVD. The dimension_index of the board is 3. Now the cart could add 3+1 = 4 and assign a dimension_value of 3. The customer would only see box shipping options.

**Dimensional Shipping Option 2
**Imagine an editable *admin shipping table *that displays a merchant shipping table provided by the shipping company. The ones I have list L-W-H in a zone table with the price beside each size.

Products could carry with them a **dimension_index **field that reads as if it was L-W-H.

The* new admin shipping table* has an extra field with a dimension_reference.

The cart would mash the _index with the _reference and 'pick' the closest match = dimension_value.

Shipping modules would look for the *dimension_value *before they become available.

Both options would allow you to use number grouping, ranges, even zone values to accurately filter the shipping options. Now imagine an alphanumeric code that assigns existing zones to number ranges.

Wait, you've got two shipping companies... use a second editable *admin shipping table... *

twitchtoo:

But wait, they want to add a skateboard to their 'How to Ride' DVD. The dimension_index of the board is 3. Now the cart could add 3+1 = 4 and assign a dimension_value of 3. The customer would only see box shipping options.

What about the situation where the customer purchases two DVD's and a skateboard? The cart would add 3+1+1 = 5, with a dimension value of 4? even though the two DVD's will be packed side by side on top of the skateboard, therefore the parcel/box dimensions would actually be the same as one DVD plus one skateboard.

In fact you could probably fit 3, perhaps even 4 DVD's alongside each other atop the skateboard and the package/box dimensions will remain unchanged.

Remove the skateboard from the equation and the DVD's parcel/box size will increase with each one added. Furthermore, assume 4 DVD's are purchased, how will the merchant pack them? Will they stack them on top of each other (4x1x1) , pack them in a long thin box side by side (1x4x1) , a flat square box (2x2x1), a flat rectangular box (4x1x1) or perhaps..... Now add another DVD or 3, how many possibilities does that give? And these are the easy examples... toss a skateboard and a helmet into the mix and a simple 'indexing' method just won't cut it.

It becomes a bit like coding for a 3 dimensional game of tetris, and even if this was done, will the merchant actually pack the items with the same efficiency as the program that performed the calculations? Have you ever tried to 're-pack' one of IKEA's 'flatpack' pieces of furniture? (It not an easy task).

Cheers
RodG

RodG, I believe the solution to your packing scenario is to create a box dimension table in admin. There you could enter in the available box sizes your company uses and their weight capacities then index the list. I agree the human packing products won't make the same choices the computer has programmed, but I'm willing to bet if the computer knows all of the variables the human does... it will be right far more often.

To summarize the Dimensional Shipping Module wishlist:

New product field - holds L-W-H + weight

New admin shipping table - holds merchant shipping rates

New admin packing table - holds available box sizes and capacities

New function - master equation to match the appropriate box to the product size and weight based on the information of the tables

Once the above is complete we will need:

• Integration into each step of the shopping cart
• Shipping output that meets shipping company API requirements

Anything else?

Also, I agree that indexing is only useful when it's applied or has an application. If the function can be built without it... one less step :)

My problem is simpler than an overall change that calculates dimensions for the entire order.
Category A products: fits in an envelope
Category B products: do not fit in an envelope
I want to disable the USPS Large Envelope shipping option if an item from Category B is put into the cart, forcing the USPS module to only show First Class Package rates as a shipping option.

See your other post for a solution, Herbert Hoover ...

Ajeh has the answer here:

http://www.zen-cart.com/showthread.php?211290-Hide-USPS-International-Large-Envelope-option-if-products-don-t-fit&p=1229536#post1229536