Incorrect Rates

[cannonmoyer]

I've been hesitant to submit an issue, but I've been unsuccessful in solving my problem. I've successfully integrated ActiveShipping with a rails application I have been developing. Functionally, everything appears to work as expected and I can pull rates for a package of weight X with blank dimensions. I went further into the docs and it appears that the package

ActiveShipping::Package.new(8.0 * 16, [],units: :imperial)

is a valid Package representation and can be submitted for a rate with only the weight defined. Again, functionally this appears to work fine, but when I compare the rates from ActiveShipping to the rates I am getting from two of our other systems that are in production, the rates are off drastically. I've also compared the rates with the dimensions defined in the current productions system alongside ActiveShipping. Again, the rates are drastically off. I've seen up to $70 rate differences for packages of the same weight and same service option. I've tested ActiveShipping on the same production UPS and FedEx accounts. I've also ensured that the origin and destination addresses are the same and I am not using sandbox. After going through the documentation I have not found any other setting that I believe would cause such drastic rate differences. I've tested residential rates vs commercial rates also, but the problem persists across the FedEx and UPS integrations.

[jonathankwok]

Hello @cannonmoyer, that sounds frustrating. It may be because there's no dimensions being passed into the ActiveShipping::Package - while we presently support three zero-length dimensions, there are plans to deprecate this functionality in ActiveShipping 2.0.

Can you let me know what happens if you pass in dimensions? Do you still have massive mismatches?

[cannonmoyer]

I pulled a few more rates again today for an 8lb package with dimensions 4 x 4 x 4 with the same origin and destination address. Here is what I got from ActiveShipping:
UPS Ground - $16.88
UPS Three-Day Select - $23.8
UPS Second Day Air - $29.63
UPS Next Day Air Saver - $45.69
UPS Next Day Air - $49.29
UPS Next Day Air Early A.M. - $80.56

The software we use in our warehouse pulled these rates:
UPS Ground 11.45
UPS Three-Day Select - $20.81
UPS Second Day Air - $23.26
UPS Next Day Air Saver - $45.38
UPS Next Day Air - $49.39
UPS Next Day Air Early A.M. - $140.58

I do understand why you'd want to require dimensions for all packages, but for companies that have a large selection of items (the company I work for has 50k different items we sell online) it would be impossible to go through all of the combinations of items and put together a package size of 1...n packages per order. That seems like it would make the rate differences even worse. Currently we add up the weight of all the items in the cart and get combined product shipping rates with only the weight. That method seems to carry over very well when compared to the actual shipping rates we pay.
@jonathankwok

[developingchris]

@cannonmoyer does your company pay based on weight, or dimensional weight divisor?
Are you on a commercial rate scale?

I have a similar issue of having lots of sku combinations to choose from.
I'm very interested in helping figure this out, as I'm embarking on a rewrite of a system that sounds similar to yours, I was planning on reverse engineering dimensions using dimensional divisor, if necessary to make the api work for me.

[cannonmoyer]

@developingchris We pay based on weight. And yes we are on a discounted commercial rate scale. I would be interested in figuring something else out because it appears that the Shopify devs are going a different route than what I need anyway.

[developingchris]

@cannonmoyer
Dimensions can be easily derived from weight with a dimensional divisor. Which should be a fixed point in your rate schedule or the base one.

I'm running the other route, measure all the things, build a box configuration program, estimate the box to be used, and determine it's dimensional weight.