Definitive Logic behind OrderHed.DocTotalCharges

Does anyone know the ins-and-outs of how the OrderHed totals are calculated?

And more importantly, what could cause the OrderHead.DocTotalCharges to be different from the sum of the OrderDtl.DocExtPriceDtl

I’ve got a handful of orders where they don’t match. The difference turns out to be whole lines not being included in the OrderHed Total.

None of the lines are voided, or sales kits components.

On that first row’s order, the OrderHed.DocTotalCharges equals the sum of lines when you exclude lines 2 thru 5. Nothing odd shows for those lines.

Copying the order creates a new order with the proper values in OrderHed.DocTotalCharges.

1 Like

Any lines closed?

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.

@aosemwengie1 - That’s not what you actually see. And I mean on any order, not just the ones giving me problems.

If you look at my first screen shot, you’ll see that the Total Charges matches the ExtPriceDtl (which is the sum of the extended prices).

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.

1 Like

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.

Some more info…

  1. I loaded order 174675 (5th row above), whose status was CLOSED, as all lines had been shipped.
  2. The Summary of charges showed $2,204.00.value. This is incorrect as the lines add up to $4,519.00
  3. Re-opened order. No change to summary charges.
  4. Re-opened line 4. No change to summary charges.
  5. Re-opened release on line 4. Summary charges updated to show $4,519.00 !!!

Looking at the change log for OrderHed, shows the TotalTax and DocTotalTax was updated 22 times.

  • This appears to be twice for each order line.
  • The first 11 lines in the chglog record take the tax down each time, from $340.73 to $0.00
  • The next 11 lines in the chglog record increase the tax each time, ending back with $340.73
  • There is just one text line in the changelog record, that shows the DocTotalCharges changing:

calvin.krusen 12:30:24
DocTotalCharges: 2204.000 → 4519.000

Edit

And now the OrderAck printout is actually correct!

Maybe someone accidently closed the release before the order was complete?

The value shown on the Summary was not off by the amount of the line I re-opened. It was off by the Sum of lines 1, 2, & 3.

It looks like re-opening the release merely triggered the process that re-calcs the whole order. And this time it decided to include lines 1 thru 3.

¯\_(ツ)_/¯

@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:
image

The sum of the ext price for the details adds up to $5,179, but the Order Ack prints $4,736 ??

The Sum of the details adds up to 5,179
The Order Summary says 5179 for Charges but the Order Summary Order Total says 4,736

When it comes to printing, both values print on the Order Ack, just as they are on the Order Summary.

Is the missing $443 (5179 - 4736) attributable to one or more lines?

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

1 Like

Hi Rick,

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. :thinking: 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?

Nancy

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.