Bugs in shipping rate calculation: IMPORTANT

Guys,

could you please have a look at changesets e197d081c68b and 6a758803dfb6 and let me know your thoughts. It uses the algorithm suggested by Dennis. It's quite simple (dimensions are calculated on based cube root of volume). Of course, it's not a planned 3D Bin Packing implementation which is quite complex but it works more accurate now.

I'm not yet running a 2.70 version on my desktop to test it, but the code looks right.

Can you share you plans for whether/how you will be adding Packing plugins?
Please keep in mind that even if Packing is performed and you pass a "Packages" collection to Shipping plugins, that I hope you will continue to pass the Items collection too, so that the Shipping plugin can still use them if desired :)

Have these changes been rolled into 2.8 and above?   I'm still seeing high shipping rates compared to the UPS site, using the same UPS account credentials.

Many items, in our case, are $3-$4 more expensive than they should be.

Thanks.

It could be related to "negotiated rates":

https://www.nopcommerce.com/boards/t/22779/ups-shipping-not-accurate-compared-to-ups-site.aspx


Do you also get excessive rate for a "simple" cart? ( ie. a single item with dimensions that don't cause "dimensional weight", less than 70 lbs, etc.)

Andrei

\Libraries\Nop.Services\Shipping\ShippingExtentions.cs

The " ensure that a maximum dimension is always preserved " is not good for very large product.
E.g. 76 x 10 x 5 = 3800  cube root = 16   (maxProductLength = 76 :   76 * 16 * 16  = 19456  (5x as big)

E.g. UPS Ground for actual dimensions is $19.  For adjusted package, it's $149 !

        public static void GetDimensions(this GetShippingOptionRequest request, 
            out decimal width, out decimal length, out decimal height, bool useCubeRootMethod = true)
        {
            if (useCubeRootMethod)
            {

                ...

                decimal dimension = Convert.ToDecimal(Math.Pow(Convert.ToDouble(totalVolume), (double)(1.0 / 3.0)));
                length = width = height = dimension;

                //sometimes we have products with sizes like 1x1x20
                //that's why let's ensure that a maximum dimension is always preserved
                //otherwise, shipping rate computation methods can return low rates
                if (width < maxProductWidth)
                    width = maxProductWidth;
                if (length < maxProductLength)
                    length = maxProductLength;
                if (height < maxProductHeight)
                    height = maxProductHeight;
            }
            else
            ...

I think the rate calcs need to be adjusted like Fedex was:

            switch (_fedexSettings.PackingType)
            {
                case PackingType.PackByOneItemPerPackage:
                    SetIndividualPackageLineItemsOneItemPerPackage(request, getShippingOptionRequest, subTotalShipmentCurrency, requestedShipmentCurrency.CurrencyCode);
                    break;
                case PackingType.PackByVolume:
                    SetIndividualPackageLineItemsCubicRootDimensions(request, getShippingOptionRequest, subTotalShipmentCurrency, requestedShipmentCurrency.CurrencyCode);
                    break;
                case PackingType.PackByDimensions:
                default:
                    SetIndividualPackageLineItems(request, getShippingOptionRequest, subTotalShipmentCurrency, requestedShipmentCurrency.CurrencyCode);
                    break;
            }

P.S.  The optional param (bool useCubeRootMethod = true) is never set by any callers
And, it's not configurable by Settings.

P.P.S.  ShippingExtentions.cs is spelled wrong :)

New York wrote:
Thanks. I've just created a work item. But sometimes it's requires (max dimension). This 3D bin packaging task is very (!!!) complex. Not sure that I can properly implement it

New York wrote:
This work item already exists

New York wrote:
Fixed

Hello Everyone,

Yes, I too am noticing very high rates as compared to the UPS and FedEx website calculated rates. I can only speak for our case when it comes to shipping. Most of the boxes we ship are roughly square. So the cube root method makes sense to us. Very rarely do we ever ship anything that has a 1 inch facing on the box... So for us the following code doesn't apply:

                //sometimes we have products with sizes like 1x1x20
                //that's why let's ensure that a maximum dimension is always preserved
                //otherwise, shipping rate computation methods can return low rates
                if (width < maxProductWidth)
                    width = maxProductWidth;
                if (length < maxProductLength)
                    length = maxProductLength;
                if (height < maxProductHeight)
                    height = maxProductHeight;

I see why it was done. But to tell you the truth it doesn't really apply much in when you are shipping with either UPS or FedEx as long as it doesn't end up being an oversize package by looking at billable and dimensional weight: UPS Calculations
FedEx Calculations

I ran through the code on scratch paper with two identical items that measure 22 x 17 x 10. So it looks like this:

h = 22
w = 17
l = 10

3740 cubic inches...

The code then finds the cube root and assigns the value equally to all three sides:

h = 15.5
w = 15.5
l = 15.5

Then it goes back and assigns max height, width and length...

h = 22
w = 17
l = 15.5

That leaves you with 5797 cubic inches. That is 35.48% higher than it should be. If you get into larger packages that kind of difference can easily turn a package that is not oversized into an oversized package further compounding the issue. My solution was to dim out the code that uses maximum sizes. At the end of the day, the rates seem to be much closer for us.

With UPS then look at your dimensional and actual weight and charge you for the greater of the two:

Dimensional Weight for Domestic Air Shipments: (H x W x L)/166
Dimensional Weight for Domestic Ground Shipments < 5184 Cubic Inches = Actual Weight (UPS ONLY)
Dimensional Weight for Domestic Ground Shipments >= 5184 =  (H x W x L)/166
Dimensional Weight for International Shipments (H x W x L)/139

All figures are rounded up to the next pound. So the above example ends up like this at 5797 cubic inches:

Dimensional Weight for Domestic Air Shipment: 35lbs
Dimensional Weight for Domestic Ground Shipment: 35lbs
Dimensional Weight for International Shipment: 42lbs

Without the MaxHeight/MaxLenght/MaxWidth permutation it looks like this:

Dimensional Weight for Domestic Air Shipment: 35lbs
Dimensional Weight for Domestic Ground Shipment: 14lbs <-- less than 5184 cubic inches use actual weight (UPS)
Dimensional Weight for Domestic Ground Shipment: 22lbs <-- (FedEx Will Use This)
Dimensional Weight for International Shipment: 42lbs

There isn't much of a difference when you are dealing with heavy items or items that you are shipping internationally.

Now on the flip side of the coin we have to consider oversize packages. These are packages where the girth (2 x H) + (2 x W) > 130 inches. In those cases then you have to worry about the MaxHeight/MaxLenght/MaxWidth because they are billed at a higher rate.

Maybe what should be done is to apply that code only if the two largest values of the MaxHeight/MaxLenght/MaxWidth multiplied by two exceed 130 inches.

And yes, I agree...it is a complicated scenario and there is no easy way to calculate this accurately.

PCTech wrote:

What version of nopC are you using?  Where do you see that?  The versions upgraded with cube root don't do it

Hi New York,

This is version 3.1.

Nop.Services.Shipping.ShippingExtentions.cs
        

Around line 45 in GetDimensions()

3.10's FedEx has packing type (and similar was added to UPS in 3.20, see below)
If you set PackByVolume, it won't use the GetTotalWidth / GetDimension

            switch (_upsSettings.PackingType)
            {
                case PackingType.PackByOneItemPerPackage:
                    SetIndividualPackageLineItemsOneItemPerPackage(sb, getShippingOptionRequest, packagingType, currencyCode);
                    break;
                case PackingType.PackByVolume:
                    SetIndividualPackageLineItemsCubicRootDimensions(sb, getShippingOptionRequest, packagingType, subTotalWithoutDiscountBase, currencyCode);
                    break;
                case PackingType.PackByDimensions:
                default:
                    SetIndividualPackageLineItems(sb, getShippingOptionRequest, packagingType, subTotalWithoutDiscountBase, currencyCode);
                    break;
            }