I have the data, and I am working with support. It seems that the orderAmt is going off the CCDocAmt. The CCAmt is correct, but not the OrderAmt or Doc OrderAmt. As a recent example:
Bad Order (the correct total is 12534):
Good Order (copied from bad order which corrected issue):
while you’re talking to support, can you get them to say why the CC field are used, when not processing credit cards.
Definitely! The rep assumed we were using credit card processing and I had to tell him we aren’t lol
“The CC columns are for credit card processing, but this field gets populated regardless of if it is a credit card order or not.”
This issue has moved into how the total charges are calculated. Nothing to do with CC as those should mirror the total charges and doctotalcharges. Ugh, more to come
I really honestly am starting to get worried. If order totals are not calculated correctly, regardless of order input conditions, then we mind as well go back to paper. I know in our case it’s at most 300 orders out of thousands or millions but still. And I can see why Epicor would ask if users are doing anything “different” during order entry. Other thing is, I’m looking thru the data and service connect (in the past) or our current integration solution that utilizes the sales order BO, some orders also have mismatching totals, in addition to manual entry. We almost let an order go thru at -27K, but it was caught and voided , re done and the totals were correct
I’d make a BAQ Report to find new orders with bad totals and run it every night, emailing yourself the results.
Maybe a BPM to send you an email the instant an Order.Update happens with an out of balance total.
I thought the same thing…but the bigger question is…why should I have to monitor for what base functionality should take care of
Support has been extremely responsive and helpful today. We went thru a webex session and still investigating.
However, minutes ago I found that the “Rounding” column on orderhed on our negative problem orders is set to a negative value, the same value in which the orders are off by in the total charges vs doc total charges
Can anyone here query your orderhed table where the rounding column is less than 0.00 and see if it’s happening?
We do not have any OrderHed records with rounding < 0. However, we do have one with it > 0 and the funny thing is, it is the one I show in screenshot with the weird cc amount at -8005.
We have some too all seem to be when going from USD to CAD. Also, we too do not use Epicor’s Credit Card processing extension. I checked a few orders where the CCDoc Amount <> Doc Amount and the invoicing always goes off the Doc Amount (OrderHed.DocOrderAmt) column.
While doing some experimenting, I realized that the OrderTotal displayed on Order Entry Screen only accounts for open lines. So the root of the problem may very well be that an associated cost (tax, misc charge, etc…) for closed lines, might be incorrectly included in the calc of the Order Total.
Odd thing is, it does not require the Release to be open to include it in the total.
For example if an order has a line for a qty of (5) with a unit price of $200, and with two releases of (3) and (2):
- With all lines and releases open, the order totals $1,000.
- After I close Release 2, the order total still shows $1,000.
- After closing close release 1, line 1 automatically closes and shows a $0 order total.
- I re-open line 1 (but leave releases 1 and 2 closed, the order total shows $1,000
@Randy I see that too on Euro orders. I think thats exchange rates and the like kicking in. I see massive negative rounding on only USD orders.
@ckrusen Yes, when a line is manually closed via the actions menu it is removed from the total because it is marked as voided. As part of this whole RCA I will propose changing the verbage in the actions menu to void instead of close.
Stt investigating. But something between doc and non doc unit prices are throwing line totals out of balance. When that happens, the difference is then put into the rounding column. I am currently investigating USD (base currency) orders only.
I was never 100% clear on the difference between a closed line and a voided line.
If using Actions -> Order Line -> Close Line always set it to voided, that’s a problem. Consider the following:
- A multi-line order is created, line 1 has a different ShipTo, and is currently open
- Line 1 ships completely, this automatically closes the order line
- During invoicing, tax connect fails to resolve the ShipTo Address for line 1 *
- Line 1 re-opened, and the address updated.
- Line 1 is then manually closed
*(the address on the packer was good enough for the shipping company, but not for AvaTax)
What was the status of line 1 after shipping?
And what was it after being manually re-opened, and re-closed?
And I HATE that closed lines (even if from a prior shipment) don’t show on Order Acks. We often have to add to existing orders, after some of it has already shipped. Then when we print the updated order, the already shipped items don’t show
I agree Calvin, I feel it adds more complexity to the process that is not needed.
It appears orders can have a negative round value and still be correct, while some others are not. Here is an example. For some reason the TotalPrice column is not matching with the rest of the line because the unit price is not matching doc:
This total price column is part of the epidataview only (not DB)
The summation of all of those total prices goes into the rounding column as a negative:
Doc totals and doc rounding remain correct so the order total is correct. I’m seeing instances where this negative value is staying on the order hed and the non doc rounding amount is subtracting from the doc order amount
Thanks for the hint Calvin. I had the same and Close/reopen lines succeed to recalculate the order total.