First of all, I need to quote from the F1 help of
"Fixed point arithmetic" checkbox in the program attributes for the meaning of this technical terms:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Fixed point arithmetic
If you mark this checkbox, all calculations in the program will use fixed point arithmetic.
If you do not, packed numbers (ABAP/4 type P, Dictionary types CURR, DEC or QUAN) will be treated as integers when they are used in assignments, comparisons, and calculations, irrespective of the number of decimal places defined. Intermediate results in arithmetic calculations will also be rounded to the next whole number. The number of decimal places defined is only taken into account when you output the answer using the WRITE statement.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SAP Note 886532 point 5 has provided an example to explain the calculation within program
without fixed point arithmetic, which demonstrates why the adjustment factor is needed in order to get the correct result.
Here I'd like to give another example to show you some further details about how does the internal calculation work
without fixed point arithmetic.
Prerequisite: In the program attributes, "Fixed point arithmetic" checkbox is
NOT set.
Test program:
REPORT ZZ_NO_FIXED_POINT_ARITH_V1.
DATA: waers LIKE konv-waers,
zzkawrt LIKE konv-kawrt,
zzkbetr LIKE konv-kbetr,
zzkbetr2 LIKE konv-kbetr,
zzkwert LIKE konv-kwert,
zzkwert1 LIKE konv-kwert,
zzkwert2 LIKE konv-kwert.
zzkawrt = '1000.00'.
waers = 'EUR'.
WRITE : 'Base price', zzkawrt CURRENCY waers, waers, /.
zzkbetr = '105.00'.
waers = '%'.
WRITE : 'Percentage rate', zzkbetr CURRENCY '3', waers, /.
zzkbetr2 = 100000 - zzkbetr. <<< step 1
waers = '%'.
WRITE : 'Percentage rate 2', zzkbetr2 CURRENCY '3', waers, /.
zzkwert = zzkawrt.
zzkwert1 = zzkwert * 100000 / zzkbetr2. <<< step 2
waers = 'EUR'.
WRITE : 'Gross price', zzkwert1 CURRENCY waers, waers, /.
zzkwert2 = zzkwert1 - zzkwert.
waers = 'EUR'.
WRITE : 'Condition value', zzkwert2 CURRENCY waers, waers, /.
Execution result:
Test program for no fixed point arithmetic
Base price 1.000,00 EUR
Percentage rate 10,500 %
Percentage rate 2 89,500 %
Gross price 1.117,32 EUR
Condition value 117,32 EUR
Some detailed explanation on calculation steps 1 & 2:
For step 1:
zzkbetr2 = 100000 - zzkbetr.
Check the parameters value in debugging:
It may look confusing that how could 100000 - 105.00 come to the result as 895.00.
Within a program without fixed point arithmetic, the internal calculation is done like this:
zzkbetr is treated as integer during internal calculation, irrespective of the number of decimal places defined.
So the calculation is done with
100000 - 10500 = 89500, afterwards it gets assigned to zzkbetr2.
Since zzkbetr2 is defined as decimal places 2, you can see
zzkebtr2 = 895.00 in debugging.
For step 2:
zzkwert1 = zzkwert * 100000 / zzkbetr2.
Check the parameters value in debugging:
The same rules apply here. During internal calculation, both zzkwert & zzkbetr2 are treated as integers:
100000 * 100000 / 89500 = 111731.8435...
Please notice that the calculation is performed using
integer accuracy here, therefore this intermediate result will be
rounded to the whole number: rounded commercially to
111732
Afterwards it gets assigned to zzkwert1 which is defined as 2 decimal places ->
zzkwert1 = 1117.32 in debugging.
============================================================================
This is how we could interpret the calculation happens internally within the
NO fixed point arithmetic program.
As it's been stated in
SAP Note 886532 point 5, the 'fixed point arithmetic' checkbox in the attributes of the
SAPLV61A program is
not selected, that is, pricing does
not work with fixed point arithmetic.
Therefore the above explanation could be helpful to understand the calculation happening inside the pricing module. With the understanding of this internal calculation within
NO fixed point arithmetic program, when the system is working with customer own defined calculation formula for pricing, we'll be able to see clearly how it comes to the result in each calculation step, and check whether the appropriate adjustment factor has been set in order to get the expected result, just like '100000' in the above test program.