Here is a screen shot with both configured to provide list rates with no adjustment:
Has anyone found a reason/fix?
I installed Qphoria's latest FedEx Wsdl (Q), and it is returning significantly higher rates to the Opencart invoice than does the stock FedEx module. The stock module is returning rates consistent with my FedEx Ship Manager software.
Here is a screen shot with both configured to provide list rates with no adjustment:
Has anyone found a reason/fix?
Here is a screen shot with both configured to provide list rates with no adjustment:
Has anyone found a reason/fix?
Actually, you are correct, and I made a poor assumption.
Qphoria has done a very nice job of integrating package dimensions to be fed to FedEx for rating, accounting for dimensional weights.
My assumption was that the "default" dimensions were what was fed, but in reality, there is an algorithm that uses the dimension of the items in the shopping cart, and the default values are only fed when the product has none entered.
However, it was the details of that algorithm that were throwing the rates off.
In order to estimate the package size - an extremely complex problem few have tackled - the module uses a "book packing" model, and looks at the maximum width and maximum length of all of the items in the cart, but then sums the height. That works OK for nice, discrete, square-cornered objects that must be stacked (like books), but ended up overestimating the package size needed for a mixed assortment of items that are conical, cylindrical, nestable, bendable, or foldable, as is the case for my product line.
I have modified the code to use the maximum of all three dimensions, and so far, that seems to be estimating better.
Qphoria has done a very nice job of integrating package dimensions to be fed to FedEx for rating, accounting for dimensional weights.
My assumption was that the "default" dimensions were what was fed, but in reality, there is an algorithm that uses the dimension of the items in the shopping cart, and the default values are only fed when the product has none entered.
However, it was the details of that algorithm that were throwing the rates off.
In order to estimate the package size - an extremely complex problem few have tackled - the module uses a "book packing" model, and looks at the maximum width and maximum length of all of the items in the cart, but then sums the height. That works OK for nice, discrete, square-cornered objects that must be stacked (like books), but ended up overestimating the package size needed for a mixed assortment of items that are conical, cylindrical, nestable, bendable, or foldable, as is the case for my product line.
I have modified the code to use the maximum of all three dimensions, and so far, that seems to be estimating better.
Who is online
Users browsing this forum: No registered users and 5 guests
