Calculating box sizes/weight for shipping (was: Shipping - canada post, drupal shipping modules)

10 replies [Last post]

Submitted on Mon, 09/24/2007 - 23:19

Joined: 09/24/2007

Juice: 76

I was about to set out writing a canada post shipping module (which would be similar to the UPS module), but before I do I wanted to check here, and share some of my thoughts..

First off, is anyone developing a canadapost module already? I can't find anything posted about it, but that doesn't mean it isn't out there.

The module itself would be similar to the UPS module, I think. One issue is that the UPS module has fields for width, length, height. I will probably also need these in my module, however, it seems dumb to duplicate them, and equally dumb to require the UPS module so those fields are available. Shouldn't they just be part of the product itself, instead of being tied to the shipping method?

One approach I'm considering is writing a bridge to allow drupal ecommerce shipping modules to be used within ubercart (of course, I've only taken a quick glance at ubercart's shipping API, and an even quicker glance at drupal's). Any thoughts on the feasibility of this? It may also be a good way to go for payment methods..

#1 Submitted on Tue, 09/25/2007 - 01:27 Top View page

zmove

Joined: 08/13/2007

Juice: 1108

Hi there,

I don't think ecommerce shipping and payment module will be compatible with ubercart one day, because these 2 ecommerce modules are not based on the same way. Maybe I'm wrong, but don't hope.

For canadian shipping module, I don't think a thing like that exist today. There is the geoshipping module which is probably the more versatile shipping module you will find in ubercart today. But it still in alpha version and probably non usable on a production site (impossible to create groups, the shipping is not calculated on checkout page... maybe incompatible with the taxe module (I didn't test))...

So the best way is to develop your own canadian post module, and, maybe, if you are altruist, provide powerfull enough functionnality to be appliable all over the world.

zmove

#2 Submitted on Tue, 09/25/2007 - 15:01 Top View page

Lyle

Joined: 08/07/2007

Juice: 6674

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.

#3 Submitted on Tue, 09/25/2007 - 22:17 Top View page

gregmac

Joined: 09/24/2007

Juice: 76

For the bridge, my thoughts were that it would be possible to trick the drupal module into thinking it's being called by drupal ecommerce - it would only use the documented ecommerce hooks. In other words, a 'bridge' module would effectively just be an API proxy - ubercart calls its hook method, which in turn calls ecommerce's hook method. Unless the APIs are so radically different..?

I can see the reasoning behind dimensions, but at the same time, it's something that PROBABLY isn't going to change for a given product based on the shipping carrier (aside from "standard" box sizes).

In theory you could actually figure out what standard box sizes to use based on product dimensions - but in reality it is much more complex and possibly not worth the effort (think: irregular-shaped objects: eg, a wedge of cheese requires a 4x4x6 box, but you can actually fit two in one box).

This is probably worthwhile sorting out, and I'm willing to put some effort in - since I'm going to need to deal with dimensions one way or another (writing a canadapost module, or a bridge).

My suggestion is moving the dimensions to the product module, then we can figure out more complex calculations from there.

For example, "maximum total space per box is X CuFt/cm3" to calculate how many separate boxes a shipment has. Maybe a size reduction multiplier in the product, eg "For every X of this item/item in this category/product class/.. reduce space usage by Y%". I'm not suggesting implementing this stuff now, it's just nice to have an end goal in sight when planning design changes.

#4 Submitted on Wed, 09/26/2007 - 07:41 Top View page

Lyle

Joined: 08/07/2007

Juice: 6674

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.

#5 Submitted on Thu, 10/18/2007 - 23:44 Top View page

gregmac

Joined: 09/24/2007

Juice: 76

Uploaded @ http://www.ubercart.org/contrib/1422

#6 Submitted on Wed, 10/24/2007 - 10:25 Top View page

Blackguard

Joined: 10/24/2007

Juice: 36

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.

#7 Submitted on Wed, 10/24/2007 - 12:22 Top View page

Lyle

Joined: 08/07/2007

Juice: 6674

Products now have dimension fields that any module can use. I think it depends on the use of different shipping modules how you want to interpret them. I can see them used as the actual size of one product, the dimensions of the box several of them ship in. The values of those fields are only important to the CanadaPost module, so far. The only other place they are used is to provide default values for packages in the shipping module. It might be good if the CA Post module could provide some instructions by the product dimensions explaining what it wants.

#8 Submitted on Wed, 10/24/2007 - 20:56 Top View page

gregmac

Joined: 09/24/2007

Juice: 76

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.

#9 Submitted on Thu, 10/25/2007 - 08:09 Top View page

Lyle

Joined: 08/07/2007

Juice: 6674

I didn't realize until after that post that the CanadaPost module didn't actually use the dimension fields. Got a little confused.

I think you're right about the different uses for the dimensions causing problems down the line. That's really why I had them separated out into the different shipping methods in the first place. But like I said, most of the shipping modules don't actually need to use those fields. The ones that do can define their own and give exact instructions on what they're for. The main product dimensions should be the dimensions of the product itself.

How does that sound?

#10 Submitted on Thu, 10/25/2007 - 11:51 Top View page

gregmac

Joined: 09/24/2007

Juice: 76

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.

Ubercart

Calculating box sizes/weight for shipping (was: Shipping - canada post, drupal shipping modules)

Navigation

User login