While it's true that you won't be able to take an e-commerce module and just put it in an Ãœbercart site and expect it to work, you can still use a lot of the code that doesn't have anything to do with Drupal. In fact, that's where the USPS module came from. Most of the original code that built the XML requests is still pretty much the same.

I don't think I'd worry about a bridge module. It wouldn't really be generic enough, and you'd need to spend as much research and mental effort doing that as you would rewriting the modules.

Product dimensions.
Originally, I had put the length, width, and height in the UPS module because I figured that not all shipping methods required them, and even the UPS module doesn't need them if you choose a standard package type. I also thought that maybe people would want to specify different dimensions for the different shipping methods. UPS boxes are different from FedEx boxes, after all.

I suspect that my reasons are silly, and I'll probably put the dimensions right into the product module. Product weight has been there forever, despite thinking that we'd eventually use it for file downloads.

For UPS and FedEx, I have the products specify how many you could send in a single box. This number is used in the quote to figure out how many packages an order might need. This isn't entirely accurate since most people will put everything into one box if they can, not just one kind of product. That's why the "All in one" quoting option is there.

When the shipment is actually made in Ãœbercart, you tell it exactly how many of each product go into each box, so you will get the right number of labels for the right price.

I've been using Zencart with a Canadapost module for over a year.

I want to migrate the store to Drupal. Dimensions are essential to accurate price generation with a Canadapost shipping module for a retail store such as the one I'm working on.

Can't wait to see that happen! If I can help, I'll gladly join in the effort.

From my impression (I have not used another shipping service than Canadapost) the important difference is that you can specify boxes of any sizes to the canada post server - they don't provide standard box sizes.

The Canada post server receives product dimensions and fit them into whatever user defined boxes are recorded in the retailer's canada post profile - unless the item is marked as "ready to ship", in which case the canada post servers provides a quote using the product's dimensions as the shipping box.

Lyle, I saw that they were moved - though I think you mean currently only UPS uses them..

Anyways, as I've said before, the whole dimensions/boxes thing is a very difficult subject. I don't think it's a good idea though to leave it up to each module to decide how to use the dimensions (eg, packed or not).. that will cause major headaches when you want to use eg, both UPS and CanadaPost, and one expects the dimensions to be the boxed dimensions, and the other expects the unboxed product..

(btw, at the moment, the Canada Post module totally ignores dimensions, and just bases the quote entirely on weight)

So the big issue is figuring out what is going to be shipped (how many boxes, and how big is each box), based on any arbitrary mix of products in the cart.

It would be nice if we can come up with one method, and use that for all shipping methods (so it is consistent and usable if you happen to have multiple or all shipping modules installed). If necessary, there could be a couple methods, and the user can choose globally which one to use..

I outlined some random thoughts about using cubic size here: http://ubercart.org/forum/development/815/shipping_canada_post_drupal_sh.... I'm not sure it's the way to go but... there is a surprising lack of insight on the internet about dealing with this.

In fact, the closest thing that I've seen is CanadaPost's service, where you send them dimensions for each product and they pack it all into predefined box sizes in your account and come up with the answer.

The only thing it doesn't account for is small businesses that may not have access to the same boxes all the time, just shipping with whatever is available.

Yeah, I understood why you did that as soon as I started writing the Canada Post module. My conern is, as a user, having multiple dimensions fields for every single product is very overkill (as in, a pain in the ass having to enter dimensions 2 or 3 times for every product depending on how many carriers/shipping methods you're using).

Box packing is a non-trivial problem (see http://en.wikipedia.org/wiki/Bin_packing_problem), and so I'm not really sure what you wish to accomplish by leaving it up to each module. Canada Post actually has a box packing algorithm as part of its API, so if you set up boxes in your account, it will tell you how many boxes and what goes in each box. Quickly looking around, the only thing I could find about UPS was that it has volume-based packing - so it will let you fit a golf club into a box half it's length, so long as there is enough volume.

Here's another scenario: PROD1 has a shipping box that is setup to fit 12 items, and PROD2 uses the same box but fits 6 items. If the customer adds 6 PROD1's, and 3 PROD2's, those should fit into one box.. but the system needs to be smart enough to figure that out, instead of sending two half-empty boxes.

What I'm getting at here, is I think that the only real solution is going to be very complex. But let's not lose sight of the goal here: in the end, we're just trying to get an accurate shipping rate to charge the customer. I see all these extra dimensions fields and leaving it up to the individual quote modules to deal with them as a whole lot of effort that doesn't result in accurate rates.

Generally carriers calculate their rates based on two things: number of packages, and billable weight. For most carriers, billable weight is the larger of actual weight and dimensional weight (see: http://www.ups.com/content/us/en/resources/prepare/dim_weight.html).

So I think I do agree with you that it should be up to the quote modules, but it should be implemented slightly differently than it is now. The modules should really try not to add more UI fields to the products themselves, as that increases complexity for the store administrator or whatever poor sap has to type all that info in.

Each quote module should have a "calculation mode" setting, which for UPS would be eg, "Based on weight only", "Based on dimensional weight". Canada Post would add "Based on Canada Post box packing" (the only reason I'm saying leave it up to the modules, instead of doing it in uc_quote).

They'd also have a setting for "dimensional weight markup", a fudge factor that would let you add x lbs/kgs or a percentage of the calculated weight, since in most cases the box is not going to be filled 100%.

There would be another setting for "maximum weight per box", so the number of boxes is calculated based on that.

Getting slightly more complicated, uc_quote could have a place to define standard box sizes for the store, and so once dimensional weight is calculated, the product could call some uc_quote API function that rounds the dimensional weight up into the next nearest box size (based on the box's dim weight of course), and then return an array with the box (or boxes') dimensions. This is just for a shipping estimate though - it's not figuring out what is actually going in each box.

Sorry for being so long winded about this. I'm very much willing to help implement all this, but I would definitely like to come up with a good solution before I (or anyone else) spends a bunch of time coding something.