# How to interpret the calculations without fixed point arithmetic in SD pricing program

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.

Cool! very helpful.

Thank you for your feedback!