The situation we have found relates to an AppSetting “ExcludeUPSServiceChargesFromFreightAmt” found in recent versions of QuickShip. What we found to be happening is UPS will return our negotiated rate all in and when “ExcludeUPSServiceChargesFromFreightAmt” is not set to true in the AppSettings they add the FULL service charges on top of your negotiated rate. It can heavily inflate the charges being returned to Epicor, causing over-billing to customers, and angry customers. Support indicated development has been asked to change this in the past and they have not so an idea has been created. These service charges should not be applied when you’re returning Customer Rate from UPS.
I could try to detail the math a bit more in the Idea. But the summary of it from testing was:
Negotiated Rate from UPS in the CarrierXML all in was 262
Invoice from UPS was 262 (bang on)
Rate returned to Epicor was 450 (because the street rate included Service Charges of 188 which are discounted and included in the 262)
If you have seen this as well, have the CarrierXML and JSON files to support it, and feel the same that this is a gross oversight and should not be an Idea feel free to reference our case CS0004608963
No idea. It totally depends on the charges for the shipments. In this case the Service Codes were for Hundred Weight. If you don’t trip the service codes you won’t see the issue.
You want it to be true so it excludes the Service Charges in the total amount. Now if you weren’t using Customer Rate (your negotiated rate) you would probably want this set to false so you don’t eat those costs.
This happened to me too. For example, rate shop quoted $63 for UPS Ground on a large 51# package. After my shipper clicked Ship, we noticed that the Actual charge skyrocked to $105. If we were billing the customer, shipping would’ve cost more than the item they ordered. Fortunately we weren’t billing them, and my UPS invoice was right at $63.
We’ve known about this a while. Shipments over 50# trigger the code for additional handling, so we just use UPS’s platform WorldShip in those cases. It was only this week in an unrelated open support case that my support tech told us he added this ExcludeUPSServiceChargesFromFreightAmt setting to our account and asked me to toggle it to true. It worked! Definitely feels like a bug not being defaulted to true.
^ that did fix our problem of some UPS prices increasing after shipping from what the rate shop “Actual” said it would be. FedEx and USPS/Endicia were never affected.
BUT now we’re noticing a few cases of the Actual price dropping after shipping. Small amounts, like $1.98 or $2.86 or $3.98 usually, but we’re still risking underbilling the customer if one slips through the cracks. I’ve checked my UPS billing invoices, and we were charged the QS rate shop Actual amount, not the reduced Actual amount after shipping.
I have a theory that it’s a delivery area surcharge or fuel surcharge being duplicated. Just a theory because:
I can’t see a rate shop rate itemization for UPS since we have negotiated rates (the new tooltip beside each rate shop price), and
I can’t prove my theory about what’s happening because we were told to turn off our XML file generation because it was crashing our site. Sigh…
QS says they can’t reproduce the price drop, but it happens almost daily to us. I’ve been back and forth with UPS support and QS support for 2 months. They each blame their other for the discrepancy like the Spider-Man pointing meme. I can’t prove my theory and I also can’t find a common denominator of why it only happens sometimes. To help me get to the bottom of it, is there anyone else who changed that setting and now occasionally sees a UPS price drop after shipping?
We use UPS WorldShip software, not QuickShip, but we’ve been having all kinds of problems with published rates the past few months. WorldShip’s published rates are not reliably matching UPS.com. Sometimes it’s only a little off and sometimes it’s wildly off. Still waiting for answers from them…