Post by yorkfirearms » Sun Dec 29, 2013 9:59 pm

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.

Newbie

Posts

Joined
Sun Dec 29, 2013 9:55 pm

Post by Blaccard » Wed Jan 08, 2014 1:43 pm

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.

Newbie

Posts

Joined
Mon Jan 06, 2014 4:00 pm

Post by yorkfirearms » Wed Jan 08, 2014 7:52 pm

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.

Newbie

Posts

Joined
Sun Dec 29, 2013 9:55 pm

Post by youngmedia » Sat Nov 15, 2014 6:40 am

Where did you find it was hard coded?

Newbie

Posts

Joined
Fri Aug 23, 2013 1:35 am

Post by rch » Wed Dec 24, 2014 6:44 pm

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):

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>';
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.

Attachments

VQMOD made for opencart 2.0.0.0 but should work with others.


rch
Newbie

Posts

Joined
Wed Dec 24, 2014 6:31 pm

Post by Dhaupin » Fri Jan 16, 2015 10:55 pm

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).

https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.


User avatar
Active Member

Posts

Joined
Tue May 13, 2014 3:45 am
Location - PA

Post by Dhaupin » Sat Jan 17, 2015 4:42 am

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:

Code: Select all

$virtWeight = ((($length + $width + $height) / 139) * $qty)
$realWeight = ($weight * $qty)
$finalWeight = $realWeight

if ($virtWeight >= $realWeight) {
	$finalWeight = $virtWeight
}

return $finalWeight

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

https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.


User avatar
Active Member

Posts

Joined
Tue May 13, 2014 3:45 am
Location - PA

Post by Qphoria » Tue Jan 20, 2015 3:22 am

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:

Code: Select all

$virtWeight = ((($length + $width + $height) / 139) * $qty)
$realWeight = ($weight * $qty)
$finalWeight = $realWeight

if ($virtWeight >= $realWeight) {
	$finalWeight = $virtWeight
}

return $finalWeight

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

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.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Dhaupin » Tue Jan 20, 2015 7:40 am

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.

https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.


User avatar
Active Member

Posts

Joined
Tue May 13, 2014 3:45 am
Location - PA

Post by Qphoria » Thu Feb 12, 2015 10:41 pm

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.
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.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am
Who is online

Users browsing this forum: No registered users and 3 guests