It seems like a major limitation that only a single static "default package size" can be used. This would only apply to your business if you always used the same box size for all shipments -- probably not true for most people.

I looked into altering the box size but the only hook exposed "commerce_fedex_submit_soap_request" is invoked just before the request is made and has no order context (which of course is a requirement for any custom heuristic).

I have a patch to follow that explicitly alters the package dimensions and sends along the order context with it.

CommentFileSizeAuthor
#17 commerce_fedex-allow-package-dimensions-alteration-2267831-17.patch1.85 KBjsacksick
#1 commerce_fedex_alterdefaultpackagedimensions-2267831-1.patch2.09 KBkeyframer
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

keyframer’s picture

keyframer CreditAttribution: keyframer commented
FileSize
commerce_fedex_alterdefaultpackagedimensions-2267831-1.patch2.09 KB
keyframer’s picture

keyframer CreditAttribution: keyframer commented

And in case anyone is going down the same route I went, here's the heuristic I landed on. I tried a several, including branching to preset box sizes as a function of the number of items in the order, special casing certain item types and quantities. But I got the best results by just assuming that for most orders the shipper will likely get it all into a single box and that the box will be just big enough to fit all items. That is up until a maximum box size, in which case multiple boxes will be used. Crude, but works well for this particular store.

function HOOK_commerce_fedex_package_dimensions_alter(&$packageDimensions, $order)
{
    // Assume that the shipper can fit all items into a single box, up until
    // a maximum box size.
    $maxDimension = 15;
    $volume = commerce_physical_order_volume($order, 'in');
    $scale = pow($volume['volume'], 1/3) + 1;
    $scale = min($scale, $maxDimension);
    
    $packageDimensions['length'] = $scale;
    $packageDimensions['width'] = $scale;
    $packageDimensions['height'] = $scale;
}
nvahalik’s picture

nvahalik CreditAttribution: nvahalik commented
Status: Active » Closed (won't fix)

This has been implemented a bit differently, but the idea is still the same. There is now a HOOK_commerce_fedex_rate_request_alter(&$request, $order); so you can modify the entire shipment request within your module and have the context of the order.

nvahalik’s picture

nvahalik CreditAttribution: nvahalik commented
Status: Closed (won't fix) » Closed (fixed)
keyframer’s picture

keyframer CreditAttribution: keyframer commented

FWIW I've attempted to use this new hook and it's not worth it, I'm sticking with my patch. If you try to change the packing heuristic after the SOAP request has been built you have to do a lot of dirty structure manipulations like removing or adding the correct # of packages. This is just emulating the logic in _commerce_fedex_get_package_items() but way too late. By calling out to a user packing strategy directly within _commerce_fedex_get_package_items() this ends up being much cleaner.

murias’s picture

murias CreditAttribution: murias commented

I'm needing to go down a very similar road here. My client has the issue that most things can fit into the default box sizings, but there are items which are larger than that size and module is wanting to break them up into smaller boxes. This is a physical impossibility, simply cannot make large pieces of aluminum smaller.

I must agree with keyframer on this, it is simply to late in the process to use this new hook. Why need rebuild a wheel, when one can simply give explicit instructions on how to build the wheel from the start. Thus requiring much less code or confusion. The logical way of this process is hooks in the initial build of the request array.

In my particular use case, it makes sense to have the algorithm perform a dimension check of the item itself prior to adding it to the total volumes etc,. then add that specific item to the request array. Waiting until this array is built then attempting to go back and destruct, reconstruct requires too much coding and dare I even say guessing.

I have read many threads on this type of subject. Seems that maybe this requires more discussion, to have an actual viable solution to be useful to a wider range of people.

nvahalik’s picture

nvahalik CreditAttribution: nvahalik commented

murias, keyframer,

Thanks for your comments.

I agree that this topic deserves much more discussion. While this hook is useful and provides a clean way to access FedEx's requests before processing, the whole shipping subsystem as a whole lacks key functionality that makes this problem (box packing) not only tough to solve, but practically impossible to solve across the board. (e.g. You're stuck with FedEx if you modify it to use your needs. You can't swap carriers on the fly.) The real crux of the issue is that orders are flat and unless you're using Commerce Shipment, there is no "native" way of even splitting an order into individual boxes, shipments, etc. no less plugging in some logic to figure out how you want to build a shipment. The problem is exacerbated in that shippers all have different various options of box sizes, weight limits per box sizes, content restrictions, etc, etc.

That said, the fight to be fought is not here in Commerce FedEx, but within the larger Commerce Shipping subsystem as a whole. At BadCamp 2014, we're going to have a BOF about Commerce & shipping to discuss this and other areas of improvement for shipping. It could definitely use this, and you're welcome to come visit us while we're there as well as participate in the BOF.

andyg5000’s picture

andyg5000
he/him
Primary language English
Location North Carolina, USA
CreditAttribution: andyg5000 commented

Hey Everyone,

This has been going an ongoing issue with commerce shipping since day one. Everything is simplified and abstracted as to not make too many assumptions about how people will handle shipping. The solution has been to provide the ability to alter the rate requests on your own. While I think this is important, I also feel that if you're rewriting your own rate requests, you might as well write your own module.

I'd like to propose an idea that I've been working on over the last few weeks. I have developed commerce box which exposes a fieldable/bundleable entity that is used to store box information. This entity represents the box that will be shipped out the door full of commerce products. The default fields of a box entity are dimensions and max weight. All that the module currently does is expose this entity. However, I've created a client-specific shipping solution by adding extra fields to the box entity and attaching the box entity to commerce shipment entities. In this example, I'm able to build "pack outs" because I've added a field collection to the commerce box containing product and min/max quantity. Basically it says if there's x quantity of product y, put it in product z. Once all pack outs are filled, the remaining products on the order are packed into the best box(es) based on volume calculations. I then create shipment entities from this information that includes a box reference and product references (1 entry per 1 quantity of product). From here you have all the info you need to make a reliable rate request.

I propose that we make commerce box and commerce shipment the default way to handle shipping rate requests for all of the shipping modules. This will allow us to store rate request details and any other information we need to be saved on the the shipment (including tracking!). Currently commerce shipment is using a line item reference to track what's in the shipment. From there we can also create libraries for different types of packing logic and include them with either module as a sub module of box or shipment.

Looking forward to the BADCamp BOF and coming up with a solution to this long standing problem.

murias’s picture

murias CreditAttribution: murias commented

Any idea when the BOF is at BADCamp? There is no information of any BOFs at the event.

andyg5000’s picture

andyg5000
he/him
Primary language English
Location North Carolina, USA
CreditAttribution: andyg5000 commented

I asked Nick, but haven't heard back. I'm happy to do it any day. I'll make sure we ping you when we figure it out.

murias’s picture

murias CreditAttribution: murias commented

Hopefully its all on saturday, something came up and not making it sunday, bummer.

nvahalik’s picture

nvahalik CreditAttribution: nvahalik commented

2:30 PM Saturday! Be there or be ■!

murias’s picture

murias CreditAttribution: murias commented

drat drat drat. Major amounts of crudness. The one session I want to make sure I attend, backdrop, is in conflict with this discussion of commerce and shipping. Where is this BOF being held, and for how long?

nvahalik’s picture

nvahalik CreditAttribution: nvahalik commented

Come on by the commerceguys booth any time today. Happy to discuss at any time.

murias’s picture

murias CreditAttribution: murias commented

Nick and Andy,

Was great to meet with you two yesterday, and have some time discussing this issue on its different levels. I am looking forward to seeing what comes from it, and of being what assistance I can be.

Keep me informed.

Cheers
Murias

andyg5000’s picture

andyg5000
he/him
Primary language English
Location North Carolina, USA
CreditAttribution: andyg5000 commented

Hey Murias,

Great meeting you as well. Looking forward to moving this thing forward!

Thanks,
Andy

jsacksick’s picture

jsacksick CreditAttribution: jsacksick commented
FileSize
commerce_fedex-allow-package-dimensions-alteration-2267831-17.patch1.85 KB

According to the discussions it doesn't seem that this patch will come in, the module doesn't seem to be maintained anyway.
However, I need the patch, I'm attaching the same patch (properly formatted).

carlier.yannick’s picture

carlier.yannick CreditAttribution: carlier.yannick commented

Hello!

I encountered as well this situation where the module always send default values instead of Physical values. So I applied the patch #17 but it appears according to the logs that the module is still sending default values:

Here is what I see in the report/log section of Drupal:

array (
0 =>
array (
'SequenceNumber' => 1,
'GroupPackageCount' => 1,
'Weight' =>
array (
'Value' => 1.3,
'Units' => 'LB',
),
'Dimensions' =>
array (
'Length' => '10',
'Width' => '10',
'Height' => '10',
'Units' => 'IN',
),
),
),

As you can see I do have the right specific weight: 1.3lb, but the dimensions here are from the default values, not from the product.

Am I missing something?

Thank you for your help.

mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
CreditAttribution: mikelutz commented

carlier.yannick:
I don't believe the patch in #17 does anything on its own. All it does is expose a hook which allows other modules to alter the package dimensions.

The plugin system in the 8.x module allows custom modules more control over individual packages, and the packing strategy, and I think it solves this particular use case. That system will probably not be ported back into 7.x. Now that I'm able to do maintenance I have no objection to applying some of these patches and doing maintainence and cleanup on the 7.x branch, although my current priority is the 8.x branch. I don't have an objection to a hook for package dimensions if it would be useful. Is this still an issue for everybody?

BD3’s picture

BD3 CreditAttribution: BD3 commented

What about the patch in #1, does that not do anything on it's own as well? I attempted this patch, but the same default values are being sent to FedEx. With that patch, does somehow the comment in #2 need integrated as well?

mikelutz’s picture

mikelutz
He/Him
Primary language English
Location Michigan, USA
CreditAttribution: mikelutz commented

The patches in #1 and #17 do the same thing, #17 is just formatted properly. All they do is expose a hook that other modules can use in order to modify the package dimensions. The comment in #2 is an example of a hook function that could be included in a module to modify the package dimensions. That particular one assumes the box is a square box, slightly larger than the total volume of products needing to be shipped.