Note 886532 - Pricing: Displaying and rounding numbers

 

 

Symptom
This consulting note describes
a) why certain data fields are displayed differently on screen than they are in the database
and
b) which effects the use of fixed point arithmetic has on arithmetic operations.
Symptom 1:
If you enter a condition rate for a percentage condition, you can specify a maximum of three decimal places for the condition rate. After you enter a condition rate, it is also displayed on screen as expected and also used correctly in the pricing results. However, the condition rate in the database table in question (or when the field is displayed in debugging mode) seems to be incorrect.

Example:
You enter a condition rate of '4.2' (for example, for a master data record or a document condition). To confirm this entry, you choose ENTER. '4.200 %' appears on screen. If, for example, this condition record is selected in the KONP (or KONV) table, '42.00', and not '4.200', is displayed in the KBETR field.

Explanation of this behavior:
See the section entitled 'Reason and Prerequisites' 1./2a./3a.

Symptom 2:
You enter a condition rate for a currency that does not have two decimal places (for example, Japanese Yen JPY has 0 decimal places). After you enter a condition rate, it is also displayed on screen as expected and also used correctly in the pricing results. However, the condition rate in the database table in question (or when the field is displayed in debugging mode) seems to be incorrect.

Example:
You enter a condition rate of '75' (for example, for a master data record or a document condition). To confirm this entry, you choose ENTER. '75 JPY' appears on screen. If, for example, this condition record is selected in the KONP (or KONV) table, '00.75', and not '75', is displayed in the KBETR field.

Explanation of this behavior:
See the section entitled 'Reason and Prerequisites' 1./2a./3b.

Symptom 3:
In a user-defined report, a WRITE statement is used to display a condition rate on screen. The condition rate that is displayed is incorrect.

Example:
The user expects the system to display a condition rate of '123 JPY', instead it displays '1.23 JPY'.

Explanation of this behavior:
See the section entitled 'Reason and Prerequisites' 1./2a./3b./4.

Symptom 4:
In pricing, the system seems to calculate incorrect values.

Example:
Sales quantity 3,763 M2
Condition rate8,42 EUR / 1 KG
Quantity relation 1000 M2 = 4567 KG
The user expects a condition value of

3,763 / 1000 * 4567 * 8,42 = 144,7029...
= 144,70 EUR (rounded)
The system takes account of the decimal places in the quantity fields and value fields and actually calculates the following condition value in two steps:
Condition basis: 3,763 / 1000 * 4567 = 17,18562...
= 17,186 KG (rounded)
Condition value: 17,186 * 8,42 = 144,7061...
= 144.71 EUR (rounded)
Furthermore, the pricing programs do not use the fixed point arithmetic.
Explanations for this subject area:
See the section entitled 'Reason and Prerequisites', in particular 5.
Other Terms
Percent, decimal places, fixed point arithmetic, rounding error,
Power of ten, 10^N, factor, 10,
KONV, KONP, CURR, QUAN, DEC, KBETR
Reason and Prerequisites
This is the standard behavior of the R/3 system:
1. The value fields refer to a data type in the ABAP dictionary and this data type determines how the content of the value fields is displayed on the database or in debugging mode.
For example, the condition rate in pricing (KONV-KBETR) refers to the KBETR data element. In turn, this data element refers to the WERTV6 domain with the following attributes:

Data typeCURR
Length 11 Decimal places2

Therefore, the condition rate in the KONV database table and in debugging mode (for example, in the internal table XKOMV) is displayed with two decimal places.
2. The system requires a reference field in order to correctly display a value field on screen. The system moves the decimal point to the correct place, in accordance with the currency specified in the reference field.
a) For example, the condition currency is used as a reference currency for the condition rate. Therefore, the corresponding currency field RV61A-KOEI1 is specified as the reference currency in the ABAP dictionary when defining the KONV database table on the 'Currency/Quantity Fields' tab page.
b) Alternatively, the document currency VBAP-WAERK is specified as a reference field for the net value of an order item (table VBAP, field NETWR).
3. The system always assumes that a currency works with two decimal places. If a currency has a different number of decimal places, maintain it in the TCURX table and specify the number of decimal places:
a) For example, this table contains 'Japanese Yen' (JPY) with no decimal places or 'Tunisian Dinar' (TND) with three decimal places.
b) For percentage conditions (currency = '%'), the currency '3' is used internally as an alternative currency and this currency is also maintained in the TCURX table with a different number of decimal places (3).

4. If, in a report, a WRITE statement is used to display a value field and a reference currency is not specified in this case, the system assumes that there is a standard currency with two decimal places (see 3.). As part of a WRITE statement, value fields should therefore always be displayed with the CURRENCY addition, so that they are always displayed correctly.

Example:
The program

REPORT test_decimal_places.
 DATA: kbetr LIKE konv-kbetr VALUE '1.23',
waers LIKE konv-waers.
 waers = 'JPY'.
WRITE: kbetr, waers, /.
WRITE: kbetr CURRENCY waers, waers, /.
waers = 'EUR'.
WRITE : kbetr CURRENCY waers, waers, /.
waers = '%'.
 WRITE : kbetr CURRENCY '3', waers, /.

displays the following information: 1,23 JPY
123 JPY
1,23 EUR
0,123 %

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. In this case, packed numbers (ABAP type p, dictionary types CURR, DEC or QUAN) are considered as integers the case of assignments, comparisons and arithmetic operations, regardless of the number of predefined decimal places for the underlying ABAP dictionary data types. If an arithmetic operation (for example, a multiplication) is executed and the outcome of the operation is used for an assignment, the outcome is adjusted by a corresponding correction factor to the correct number of decimal places for the result field (see the following example).

Example:
The program (without fixed point arithmetic)

REPORT arithmetical_operations .
DATA: waers LIKE konv-waers,
kawrt LIKE konv-kawrt,
kbetr LIKE konv-kbetr,
kwert LIKE konv-kwert.
kawrt = '140.52'.
waers = 'EUR'.
WRITE : 'Condition basis', kawrt CURRENCY waers, waers, /.
kbetr = '5.36'.
waers = '%'.
WRITE : 'Condition rate', kbetr CURRENCY '3', waers, /.
WRITE : 'No adjustment takes place ==> Wrong result:', /.
kwert = kawrt * kbetr.
waers = 'EUR'.
WRITE : 'Condition value', kwert CURRENCY waers, waers, /.
WRITE: 'Adjustment takes place ==> Correct result:', /.
kwert = kawrt * kbetr / 1000.
waers = 'EUR'.
WRITE : 'Condition value', kwert CURRENCY waers, waers, /.

displays the following information:
Condition basis 140,52 EUR
Condition rate 0,536 %
No adjustment takes place ==> Wrong result:
Condition value 75.318,72 EUR
Adjustment takes place ==> Correct result:
Condition value 75,32 EUR

To achieve greater accuracy, deactivate the fixed point arithmetic in pricing (see sections 6 and 7).

6. For the internal display of packed numbers (data type 'p'):

Example:
a) Declaration of a packed number with four decimal places:

DATA: number TYPE p DECIMALS 4.
b) The value "1.2345" is assigned to this number:

number = '1.2345'.
c) Internally, however, this value is saved in the form of two integer values. In the following section, the integer values are A and B:
A contains the value of the saved number without a period: '12345'
B contains the information about the number of decimal places for the saved number: '4'
d) This reformatting ensures greater accuracy with arithmetic operations because interim results do not have to be rounded off (see section 7).

7. Different display for numbers, depending on whether or not fixed point arithmetic is activated:

Example:
a) Also, in this example, four numbers of the type p are created again:

DATA: number1 TYPE p DECIMALS 4,
number2 TYPE p DECIMALS 4,
number3 TYPE p DECIMALS 4,
number4 TYPE p DECIMALS 4.
b) The following values are assigned to the numbers and then displayed:

number1 = 1000. WRITE: number1, /.
number2 = '1000'. WRITE: number2, /.
number3 = '1.2345'. WRITE: number3, /.
number4 = '1.23456'.  WRITE: number4, /.
c) As was explained in section 6, internally all numbers are saved in the form of two integer values (An,Bn).
d) The processing result is then as follows:
o    Fixed point arithmetic is activated:

Internal display:  A1 = 10000000 B1 = 4
A2 = 10000000 B2 = 4
A3 = 12345  B3 = 4
A4 = 12346  B3 = 4 (the number was
rounded off)

Numbers displayed: 1.000,0000
1.000,0000
1,2345
1,2346
o    Fixed point arithmetic is not activated:

Internal display:  A1 = 12345 B1 = 4
A2 = 1000  B2 = 4
A3 = 1000  B3 = 4
A4 = 123456  B4 = 4

Numbers displayed: 0,1000
0,1000
1,2345
12,3456
Solution
Note that this is a consultation note. Further questions about the subject area described above are not processed by regular support, but by consulting and are subject to separate remuneration. 

 

Relation notes:

2437878 Field quantity (MENGE) has 3 decimals 
2535937 Incorrect number of decimal places for percentages 

You have implemented the option to display KONP information in the condition information in accordance with SAP Note 2403097.
When percentages are displayed in the ALV grid, you notice that the value displayed has increased by a factor of 10.
153707 Currency translation miscalculates by 100, 1000..

2535937 - Incorrect number of decimal places for percentages