Bugs in shipping rate calculation: IMPORTANT

ctrottier wrote:
That would be great if you could share your changes

What about FedEx? Can I test your work with the FedEx plugin?

rdub wrote:

If you're directing this to ctrottier, then I think no - he's only done it for UPS right know.  I've been corresponding with him to see what he's done.  You should understand that his work has made many changes in the core of nopC.  (Also, I think  all the shipping plugins would need to be re-coded.)  That means that you will need to have VS and compile unless he supplies a full executable version of his modified nopC.  Once you use this version, you are at risk of not getting any new regular nopC version changes (bug fixes, new features), unless he merges those changes into his version.   The hope of course is that the core team adopts his work and makes it part of the regular version - but no guarantee, and no time-frame.

With Shipping Director, I've taken a non-invasive approach for now.  It can call the existing plugins.  I'm going to look at ctrottier's work, and see if I can make adjustments to Shipping Director to be able to support his plugins too.

Thank you for clarifying.

Your work should be available end of week?

That was the original plan, but now if I decide to incorporate/support some of ctrottier's work it may be delayed.  I suppose I could finish what I have now and release that beta, then make decision to release prod version shortly thereafter vs. do another round of change/beta.  (You can PM me with your time-frame / concerns ).

New York is right.  I have not touched the fedex plugin.  If the changes I have made are incorporated into the core, I plan to create a fedex plugin that will work with the packed boxes.  The work I have done does not affect current shipping plugins, as they should all still work as they normally have, there is just an extra "packedboxes" property that is passed to them that they can either use or ignore.

Nothing I am doing is even close to being usable in production.  Just laying the groundwork and hoping it gets adopted.  If you need somthing soon, go with the shipping director plugin, as that is the only route without making significant changes to the core.

/Chris

I'm sure you have already reviewed this but the description of how FedEx determines the rate is found in their Service Guide on page 108. LxWxH then divide by 166 (for U.S. shipments)

This is what I need in order to get a rate that will at least be close to accurate. Are you aware of any other ecommerce packages that use this for FedEx?

Since this is how FedEx determines the rate I don't understand why the plugins all seem to send only the weight info.

Unfortunately I'll have to continue looking for an ecommerce package that includes this. Anyone have any ideas?

Yes, based on dimensional weight unless the actual weight is greater.  
Dimensional Weight is used if package exceeds three cubic feet (5,184 cubic inches).  E.g  A 3 cu ft package has billable dimensional weight of 5184 / 166 = 31 lbs  regardless of actual weight
See this for details

http://images.fedex.com/ca_english/customersupport/faq/DimensionalWeight.pdf

You can test package sizes here.  

https://www.fedex.com/ratefinder/home

The calculation will indicate whether it used dimensional weight or not on the last page

       Dimensional Weight of your package(s) was used to calculate your rate.


Yes, it does seem odd that the shipping plugins don't use dimensions, but that's because without true "packing", there is no way to determine the actual box sizes. I.e. totaling the H W L of shopping cart items the way it does now would not yield true packed box sizes.

A "true" Packer plugin would be set up with various box sizes, and would determine an optimal 3D bin pack.  It's a computationally expensive process, and difficult to optimize performance characteristics  (typically, heuristics are used).  I don't think you will find any eCommerce system that supports it, except maybe one that costs $20K+.

Ctrottier is working on some enhancements (a fork version of nopC, until it's adopted), that will call a 3rd party 3D Bin packer API - solvingmaze.com.  It does, though, have some limitations on # of box types, and #of packed boxes.  Also, as indicated above it won't be prod ready for a while.

The Shipping Director "packer" does "fabricate a box" with dimensions - i.e. it creates a single dummy product variant / shopping cart item with the box dimensions, but unfortunately the Fedex plugin does not use them.  I'll look at the fedex plugin, and see what's involved in fixing that (single item uses those dimensions, else use cube root as per above).   The Shipping Director "packer" is however limited to a single box type (HxWxL).  However, it will after packing "shrink" the dimensions on packages that are not "full" (e.g. so that if only n% of box is filled, then it assumes it will actually be packed in a smaller box using cubic root calc).

(P.S. I will post some of above to the forum thread, for benefit of others.)

a.m. wrote:


I've update the shipping fork: https://hg01.codeplex.com/forks/grene/shippingimprovements,
with what I have so far.  It implements the packing list, solving maze packing plugin, shipment manifest for ups, tracking for ups in the user and admin side, and shipment void requests.

Please let me know what you think.  It's just basic functionality at this point, I need to do some more work in the packing plugin, and the packing tab, but it gets the idea accross.  Can you take a look at it and let me know if you think some of necessary core changes can be pulled in?

For the benefit of those following this thread, I've released beta 2 of Shipping Director at www.noptools.com.  Also, there is a FedEx plugin enhanced with some packing methods as described above.

https://www.nopcommerce.com/boards/t/13776/shipping-director-plugin-beta1-released.aspx#58704