/support/notes/service/sap_logo.png){kind=logo}
SAP Knowledge Base Article - PublicSymptom
You create a debit memo request (DMR) using App "Release Billing Proposals" (F0780). The debit memo request item shows an amount per 10, 100 or 1000 units instead of per 1 unit.
"Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental."
Environment
- SAP S/4HANA Cloud Public Edition 1908 and later
Reproducing the Issue
For better understanding an example is used to illustrate the situation.
- You did maintain a service price for a service material to be used in the debit memo request
- You release a billing proposal creating a DMR using above service material
The Amount and Net Amount in the detail view show a difference caused by rounding. - You show the DMR item conditions e.g. using App "Manage Debit Memo Requests" (F1988)
The pricing unit is 100 instead of 1. The Amount is also multiplied by 100 (approximately).
Cause
E.g. In a time and expense scenario the individual confirmations can lead to calculated cost that will be rounded when stored in the journal. This is because the journal allows only for a limited number of decimal places.
In the example above the following 4 confirmations were done (price is 58,33 per H):
The data shown in column "Rounded cost" is stored in the journal. As you can see the calculated cost were mathematically rounded to two decimal places. The total amount (in this table calculated by summing up the lines) shows a rounding error of 0,01.
Meaning, the rounded sum of the individual calculated cost deviates from the sum of the rounded individual cost.
The dynamic item processor (DIP; that is the logic calculating the amounts and quantities to be billed) gets the information from the journal. In the above example the DIP will compute a sum of 991,62. This is then transferred as condition PCO1 to the DMR.
The difference between that amount and what is computed by pricing (17h x 58,33 = 991,61) is considered a rounding difference for the condition PCO1.
To handle that difference and show the (mathematically) correct amount and pricing unit the system multiplies in steps of factor 10 to show the correct figures.
The (mathematically) correct amount per hour in the above scenario would be 58,330588235294... (991,62 / 17H).
But as that amount would be shown as 58,33 in the condition screen that would be wrong (17H x 58,33 per 1 H = 991,62 is incorrect).
Multiplied by 10 the line would show 17H x 583,31 per 10H. That would still be incorrect (17 x 583,31 / 10 = 991,62 is incorrect; the correct not rounded amount would be 991,627, rounded to 991,63).
Multiplied by 100 the line shows 17H x 5.833,06 per 100H. That is now correct (17 x 5833,06 / 100 = 991,62 is correct; the correct not rounded amount is 991,6202, rounded to 991,62).
Resolution
The described scenario is a mathematical necessity to ensure consistent data display.
This happens only in very specifc scenarios where the used rates and increments lead to rounding errors.
Keywords
KBA , PS-FIO-REV , Fiori UI for Project Systems-Revenues and Reso. Rel. Billing , How To
/support/notes/service/facebook.svg)
/support/notes/service/twitter.svg)
/support/notes/service/youtube.svg)
/support/notes/service/linkedin.svg)
/support/notes/service/instagram2.svg)