Hi all.
I'm using the stock Fedex module and it is returning incorrect rates for my items. It gives me the correct rate for Fedex Ground, but all options(ie: 2 day, overnight, etc) come back as just over double the cost that they should be.
If Fedex would charge me $7.53 for Ground and $17.00 for 2day, the OpenCart Module returns $7.53 for ground and $40 for 2day.
Does anyone have any ideas for this? I've entered the EXACT same Fedex values and product values into a test install of Magento and it returns the correct Fedex prices.
I'm using the stock Fedex module and it is returning incorrect rates for my items. It gives me the correct rate for Fedex Ground, but all options(ie: 2 day, overnight, etc) come back as just over double the cost that they should be.
If Fedex would charge me $7.53 for Ground and $17.00 for 2day, the OpenCart Module returns $7.53 for ground and $40 for 2day.
Does anyone have any ideas for this? I've entered the EXACT same Fedex values and product values into a test install of Magento and it returns the correct Fedex prices.
I'm having the same issue. I did call Fedex and they told me that the weights are coming in wrong for a single item. The ground rates reflect the correct rate for the weight yet the Express rate are for a different weight. They said for example the 2 lb item was rated for ground but somehow data was transmitted that it was 25 pounds for the express.
I had figured it out a few days after the post. The Fedex module has hard coded package dimensions of 20x20x10 in it, which is why my rates were so off.
Indeed, parcel size are hardcoded in the default fedex module, this is in the file catalog/model/shipping/fedex.php in the xml sent to fedex (line 131):
In order to correct this, i created a VQMOD that adds 3 functions in system/library/cart.php. The first one adds products height, and the two others take the biggest width and length.
Then it changes the catalog/model/shipping/fedex.php to have actual cart size sent to feded. further to this, the VQMOD changes the units from inches to centimeters. The solution is not the best, but at least rates are closer to reality.
Code: Select all
$xml .= ' <ns1:Length>20</ns1:Length>';
$xml .= ' <ns1:Width>20</ns1:Width>';
$xml .= ' <ns1:Height>10</ns1:Height>';
$xml .= ' <ns1:Units>IN</ns1:Units>';
$xml .= ' </ns1:Dimensions>';
$xml .= ' </ns1:RequestedPackageLineItems>';
Then it changes the catalog/model/shipping/fedex.php to have actual cart size sent to feded. further to this, the VQMOD changes the units from inches to centimeters. The solution is not the best, but at least rates are closer to reality.
Attachments
VQMOD made for opencart 2.0.0.0 but should work with others.
Note: this hard coded box size seems to be fixed in 2.0.1.0 and beyond, so there is a backport potential there. Checking it out now to see what its about.
EDIT: the backport potential is worse quality than your fix above It just allows you to set 3 static sizes instead of calculating. Use the vQ above its more accurate.
With their recent 2015 rate increase and DIM tweaks this means that these hardcoded values will mimic a 33% jack in shipping costs for items under something like 30 lbs. That isnt good for many thousands of stores on 2.0.0.0 or earlier (including all 1.5.x.x).
EDIT: the backport potential is worse quality than your fix above It just allows you to set 3 static sizes instead of calculating. Use the vQ above its more accurate.
With their recent 2015 rate increase and DIM tweaks this means that these hardcoded values will mimic a 33% jack in shipping costs for items under something like 30 lbs. That isnt good for many thousands of stores on 2.0.0.0 or earlier (including all 1.5.x.x).
https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.
Hmm here is a formula that might be useful -- apparently the new DIM tweaks apply to boxes 36x36x36" or less. All it does is convert each box to a "virtual weight" based on a simple add-em-up and divide premise. Total box "volume" of all the products in order isnt important per-say...its more about the weight based on individual sizes. Technically its straight weight based shipping. This is pseudo-code how it works, foreach is not included in this for simplicity:
Some sources say to divide by 166, others by 194, but im going off of the fedex DIM calc here...sure it maybe outdated but its on the fedex site: http://www.fedex.com/ae/tools/dimweight.html as opposed to the 166/194 divider found in this rando Fedex pdf http://images.fedex.com/us/rates2007/DimWeight.pdf
Code: Select all
$virtWeight = ((($length + $width + $height) / 139) * $qty)
$realWeight = ($weight * $qty)
$finalWeight = $realWeight
if ($virtWeight >= $realWeight) {
$finalWeight = $virtWeight
}
return $finalWeight
https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.
Dhaupin wrote:Hmm here is a formula that might be useful -- apparently the new DIM tweaks apply to boxes 36x36x36" or less. All it does is convert each box to a "virtual weight" based on a simple add-em-up and divide premise. Total box "volume" of all the products in order isnt important per-say...its more about the weight based on individual sizes. Technically its straight weight based shipping. This is pseudo-code how it works, foreach is not included in this for simplicity:
Some sources say to divide by 166, others by 194, but im going off of the fedex DIM calc here...sure it maybe outdated but its on the fedex site: http://www.fedex.com/ae/tools/dimweight.html as opposed to the 166/194 divider found in this rando Fedex pdf http://images.fedex.com/us/rates2007/DimWeight.pdfCode: Select all
$virtWeight = ((($length + $width + $height) / 139) * $qty) $realWeight = ($weight * $qty) $finalWeight = $realWeight if ($virtWeight >= $realWeight) { $finalWeight = $virtWeight } return $finalWeight
Technically you shouldn't need to do that. FedEx will do its own calculation of dimensions and weight on their site and return the appropriate weight.
Aye you are correct, but turning each parcel into weight VS dimweight could make easier "package managers" on OC side. Im thinking it may be easier to stack weight than to make some crazy 3d volume builder that is reliant on box sizes fitting into other box sizes. If it was a volume->multiplier->weight since Jan then we can think of it like the multipler constant makes it containers inside containers of weight instead, which is a single dimension. Logically it seems easier to mitigate a linear dimension like that rather than individual 3 dimensionals.
So maybe its just me, but seems like it would be beneficial to have the DIM weight handy on OC side rather than relying on Fedex to do the same thing (and having nothing to QA or mitigate before its sent for quote). Or maybe im misunderstanding how Fedex/UPS DIM hax work now haha.
To adjust to taste in such a system there would have to be "polar fuzziness". Basically it would work to tweak the rate in various dimensions depending on your store. Example, stores that ship many small boxes or stores that ship mostly large. Fuzzy on the constant. Or if you used more padding in your boxes, or they needed space, fuzzy on the dimension or final dim greyline.
So maybe its just me, but seems like it would be beneficial to have the DIM weight handy on OC side rather than relying on Fedex to do the same thing (and having nothing to QA or mitigate before its sent for quote). Or maybe im misunderstanding how Fedex/UPS DIM hax work now haha.
To adjust to taste in such a system there would have to be "polar fuzziness". Basically it would work to tweak the rate in various dimensions depending on your store. Example, stores that ship many small boxes or stores that ship mostly large. Fuzzy on the constant. Or if you used more padding in your boxes, or they needed space, fuzzy on the dimension or final dim greyline.
https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.
It might be good to have locally, but you won't want to send that to FedEx as they may double calculate and you may end up with the wrong rate.Dhaupin wrote:Aye you are correct, but turning each parcel into weight VS dimweight could make easier "package managers" on OC side. Im thinking it may be easier to stack weight than to make some crazy 3d volume builder that is reliant on box sizes fitting into other box sizes. If it was a volume->multiplier->weight since Jan then we can think of it like the multipler constant makes it containers inside containers of weight instead, which is a single dimension. Logically it seems easier to mitigate a linear dimension like that rather than individual 3 dimensionals.
So maybe its just me, but seems like it would be beneficial to have the DIM weight handy on OC side rather than relying on Fedex to do the same thing (and having nothing to QA or mitigate before its sent for quote). Or maybe im misunderstanding how Fedex/UPS DIM hax work now haha.
To adjust to taste in such a system there would have to be "polar fuzziness". Basically it would work to tweak the rate in various dimensions depending on your store. Example, stores that ship many small boxes or stores that ship mostly large. Fuzzy on the constant. Or if you used more padding in your boxes, or they needed space, fuzzy on the dimension or final dim greyline.
Who is online
Users browsing this forum: No registered users and 82 guests