They are actually all closed as these orders have been completed.
I’m trying to find what action(s) we’re doing could be causing this. It’s post-mortem research, as it rarely happens, but does.
The major issue is that the OrderAck form uses the OrderHed.DocTotalxxxx fields for printing the order summary. If you add up the lines on the printed order, they don’t match the total printed.
I don’t know, but I just spent a month going back and forth with support over the calculation for the demand quantity in order entry. They finally did get the correct answer from development because what I was seeing didn’t match the field help. But the field help is still wrong.
At first I thought the fields I was comparing weren’t correct. But the copy of that errant order comes through as expected (yellows are equal, red is not). There’s a slight difference between the original order and the copy, as the exchange rate was been updated in between them.
@ckrusen
Not sure what, but something can mess up the Totals, here is on in 2022.1 that I am currently trying to troubleshoot. The issue here is that the SO Ack prints exactly as it looks on screen, both which are not correct (obviously). So the SO Ack is sent to the customer for review and approval and the customer signed off on the Order Total of $4,736, but Charges (and line ExtAmt adds up to ) 5,179. Then they get an invoice that has the Line and Order Totals agreeing and they want to know why they are being over charged:
Nopes, the correct value is 5179, both fields should read that.
Looks like a bug to me.
Int he test DB I changed the unit price of a line and then back to what it should be and the Totals recalculated properly.
I got proper totals after a recalc that was initiated from simply re-opening a release.
There must be some condition where the totals don’t calc properly. If it was always of by the values of one or more lines, then we could narrow it down to what was special about those lines (drop ship, a BPM ran, they were copied from another order, whatever…)
I had a bug a couple years back where a miscellaneous charge from a copied order got stuck in the orders total calculation for the new order. If I recall correctly, it was the second generation duplicate. Problem is, I cannot reproduce the error, when trying now. Was the order a copy? Was it copied from another with a miscellaneous header or line charge that was $443?
It’s not just the line charges that Order Entry can choke on. We had an order last week that was double counting misc charges. It’s a known issue (KB0119346) and I just requested the fix from CS, per the KB. The fix ID’ed (and fixed) several other orders that also had discrepancies between the MiscChg details and the OrderHed totals.
They have an article for OrderLine-OrderHed issues (KB0126437) that has its own fix program. KB says they can’t replicated the issue, but suspect it’s related to line deletions. So they suggest you just run the fix.
Running the fix doesn’t help much if its not noticed until after you sent an Order Ack that says the total is $24,000, even when if you add up the lines and get $32,000.
Yeah the Fix would correct that, but you either need to put a BPM to flag when the fix needs to be applied, or have someone double check the math on the Order Ack (which seems stupid).
I’m not here to argue against the idea that an ERP system should be able to handle basic addition on a sales order. Quite the opposite. This is pretty fundamental stuff that this very expensive program is failing on.
I’m just adding that this is a known issue (bigger than was originally suggested) with KB’s and post hoc patch programs available so people facing this problem can fix it and get their order confirmations out. Maybe the KB’s might give you insight into how this even happens so you can reproduce it. Maybe not. I’m just providing facts and summaries of the articles, not a definitive answer to the problem.