Pricing Rounding Off Error

[Former Member]

Hi Gurus,

I have the following scenario

In a Sales Order there are two line items

1. In line item 1 there are 1 qty

2. in line item number 2 there are 2 quantity of same material.

The pricing condition is coming like this

For line item no 1.

Condn type Price Qty value

PR00 Price 98.10 1 98.10

ZCHD Discount 55 % 53.96 - ( the discount calculated is 53.955, system is taking 53.96)

Net value 44.14 1 44.14

For line item 2:

PROO 98.10 2 196.20

ZCHD Discount 55% 107.91

Net value 44.15 2 88.29

Now See above for line item no 2 the total value is coming 88.29 which is fine, and value for 1 item is 44.15, but

in line item no 1 the net value is coming 44.14 ,

Our client doesnt want this descrepency.

Can any one please suggest any solution to this problem.

Thanks,

Raja

[Former Member · Accepted solution]

Hi,

Try if the solutions already proposed work. Else you can write routines in the calculation type col of pricing procedure to avoid this. There are also some std routines for rouding off, check them too.

Regards,

Saurabh Diwakar

[Former Member]

Hi Raja,

How you resolved this. Can you share please. I am also facing the same problem.

Ratna

[Former Member]

Solved

[danny_roussel4]

Hi Rasja,

how did you solved this please?

danny

[former_member715991]

Hi Raja,

how did u solve your problem. I am facing exactly same situation .

Could you please share your solution

Regards,

Swati

[Former Member]

Hi Raja,

Can you share the solution with us, we have a requirement of similar kind in our project.

Deepul Jain

[Former Member]

Dear raja singh,

Quote : ZCHD Discount 55 % 53.96 - ( the discount calculated is 53.955, system is taking 53.96)

Here , instead of taking calculated value in 3 decimal , why do not you take in 6 digit , means,

instead of 53.955 ,

you take as 53.949999

and take into the variable type P with decimal 2 , for example

data : p_round type p decimal 2.

p_round = zchd_value " 53.949999

( here p_round will be 53.94 )

zchd_value = p_round.

now zchd_value will be 53.94 which will be taken care in multiplication of 2 or 3..etc.

This has to be written in alt calc type of pricing .

why do not you try this .

saravanan

Edited by: k saravanan on Jul 17, 2008 10:14 AM

[Lakshmipathi]

Dear Raja

Have you tried with this.

In your pricing procedure, for the net value field, you need to give Routine 16 in the Alt. Cal. Type. Addition to the above setting also add Routine 17 to Netvalue.

thanks

G. Lakshmipathi

[Former Member]

In IMG, go to your condition type ZCHD and see what rounding rule has been assigned.

By your example, it appears it is blank and hence system is taking Commercial rounding A .

In this rule, value of less than 5 will be rounded down and a value of greater than or equal to 5 will be rounded up. For example, 53.494 = 53.49, while 53.955 = 53.96

In this your business does not want this to happen, you can propose rounding rule 'B' - round down.

In this case, The value will always be rounded down, regardless of what the value is. For example, 53.494 = 53.49 and 53.957 = 53.95

[Former Member]

Hi,

You'll find different solutions for your problem in the OSS note : 80183.

Regards,

Lionel

[Former Member]

Can you please Post Link for OSS note.

Thanks,

Raja

[Former Member]

Hi,

OSS Note 80183 :

Summary

Symptom

Note that the solution described here is a workaround that is not included in the standard system. Inquiries and problem messages on this subject are not in the Support's responsibility but will rather be processed in the context of Remote Consulting which will be priced separately. For details, see Note 381348.

The value of "net price * quantity" can deviate from the net value displayed if the net value itself is determined by adding or subtracting surcharges from a base charge. Furthermore, under certain circumstances, the net price for different quantities may be rounded differently.

Example of both types of rounding problems:

A discount of 9% is granted for an article with a price of 135.50$ for each piece. The exact discount is then 12.195$ and net price 123.305$. Standard pricing supplies the following outcomes:

a) For 3 pieces: PR00 Price 135.50 $ for each piece 406.50 $

RA00 Discount 9.00- % 36.59- $

Net value 123.30 $ for each piece 369.91 $ !!!!!! (instead of 369.90 $)

b) For 10 pieces: PR00 Price 135.50 $ for each piece 1355.00 $

RA00 Discount 9.00- % 121.95- $

Net value 123.31 $ for each piece 1233.05 $

!!!!!! (instead of 1233.10 $)

Other terms

Rounding error

Reason and Prerequisites

Standard pricing logic

Surcharges and discounts are related to net value. The resulting net price then results from a division of net value by quantity.

Solution

This note replaces Notes 19454 (it corresponds to variants 1 and 2 described below) and 38389 (corresponds to variant 3 described below) in Release 3.0A and subsequent releases.

Restrictions

1. According to the properties of absolute amounts (KRECH = "B"), the net price is always an amount derived from the net value and on account of the construction is also always quantity-dependent. The net price is also not developed independent of the net value, there is no parallel calculation on amount and value level and for this reason, no rounding differences can be displayed.

Rounding differences in this case, can only occur if you force the relation "price * quantity = value" on net value level. Only variant 1 can handle absolute amount conditions in this context. Due to their original budget for absolute amount conditions, variants 2 and 3 cannot principally offer a solution and the corresponding rounding formulas therefore lead to a price determination error.

2. For the lines in the pricing procedure after the price condition and before the rounding condition, problems may occur if conditions exist which could receive a surcharge from the rounding differences clearing as part of the group condition processing. These scenarios are not tested and their functioning is not therefore explicitly guaranteed in this advice note. Possible modifications or enhancements that may be required in connection with this fall into the area of advice. We therefore recommend that you suppress the rounding differences if necessary via a group key routine (compare Note 39034).

General reason: The rounding difference clearing is carried out with pricing type "F". If a condition in this pricing mode is then updated, the corresponding base and value formulas are no longer executed in the change mode, that is, all changes in the work area XKOMV or the variables XKWERT are rejected. In this case, the variables XKOMV-KKURS, XKOMV-KINAK, and XKWERT in the condition value formulas 19, 20, 919, and 920 are affected by this.

However, the following statements can be made for the individual variants:

a) Variant 1 is uncritical with regard to rounding difference clearing for the discount conditions because the discount conditions do not contain any formulas. However, the discount amount in the item containing the rounding difference clearing is, of course, no longer correct.

b) Variant 2 can probably be run despite formulas if a rounding difference clearing is carried out on the discount conditions. XKOMV-KKURS and XKOMV-KINAK should already be set correctly in the item pricing so that a new setting within the group condition processing should no longer be required. A surcharge for the discount condition based on rounding difference clearing should be caught again by the rounding condition NETP and should therefore not lead to a destruction of the relation "amount * quantity = value".

c) Particularly for variant 3, in the case of a surcharge for the discount condition based on rounding difference clearing, the relation "amount * quantity = value" would definitely be destroyed. The surcharge immediately affects the condition value of the net price condition PNTP.

3. In all the above solutions, the rebate amount is always rounded commercially and not the net price resulting from the calculation.

a) Take the calculations specified under variant 3 as an example.

Procedure in detail

1. Set up the condition type NETP (rounding difference) (not for variant

3) (Transaction V/06):

Condition class "A" Surcharges and discounts

Calculation type "C" Is quantity-dependent

Condition category "L" Always determine again

Manual entry "D" No manual entry

Item condition "X"

No access sequence is stored.

2. Set up the condition type PNTP (net price) (Transaction V/06):

Condition class "B" Prices

Calculation type "C" Is quantity-dependent

Condition category "L" Always determine again

Manual entry "D" No manual entry

Item condition "X"

No access sequence is stored.

3. Create the formulas in the customer name range as described below (called condition base formula 917 and condition value formulas 906, 919, and 920 in the attachment) (Transaction VOFM). You only need base formula 917 and condition value formula 919 or 920 for variant 3. If you only want to include condition value formula 920 but not 919, you should still create formula 919 fully because it contains a data definition for formula 920.

4. Change your pricing procedure according to one of the following three variants:

Pricing procedure variant 1:

CTyp Description Reqt AltCTy AltCBV Stat Print PR00 Price 2

RA00 Discount 2

NETP Round. diff 2 6 3

PNTP Net price 2 906 3 X X

Net value 2

...Features:

Net value = Net price * quantity.

Net price is not invariable.

Discount calculated correctly.

This variant ensures the relationship "net price * quantity = net value" is complied with. However, the net price can still be different due to rounding.

Any number of discount conditions of the same kind can stand before the NETP condition.

Mode of operation of variant 1:

a) For 3 pieces: PR00 Price 135.50 $ for each piece 406.50 $

RA00 Discount 9.00- % 36.59- $

NETP Round. diff 123.30 $ for each piece 0.01- $

PNTP Net price 123.30 $ for each piece 369.90 $

Net value 123.30 $ for each piece 369.90 $

For the condition value of 406.50 $, a 9% discount is granted, that corresponds to 36.59 $ (rounded off). The result is a current net value of komp-netwr = 369.91 $. Base formula 3 uses for the condition type NETP the current net price of komp-netpr = 123.30 $ which results from this, so for this condition type the condition value is xkomv-kwert = 369.90 $. Condition value formula 6 now calculates a rounding difference of -0.01 $ which again is subtracted from the current net price. In condition type PNTP, the net price is now reset. A net value results in the subtotal line "net price" which can be divided by the quantity without rounding errors in the above construction. This way the relationship "net price * quantity = net value" is complied with.

If now after condition type NETP you would add a subtotal line item to enter the net value, because of the following reason (again with rounding) the net price could be different: The net price has two decimal places, the quantity has three decimal places; the net value, therefore, theoretically has six decimal places. Because the net value only uses two decimal places it has to be rounded. In contrast to normal condition type lines, subtotal line items calculate backwards, the net price from the net value. With an assumed billing quantity of 1,234 pieces, you would therefore get:

1221,60 $ / 1,234 pcs = 989,95(1377...)$,

whereas when you want to print a net price line/net value line you get:

989,95 $ * 1,234 pcs = 1221,60 $ (exactly: 1221,5983 $).

To rule out possible deviation here, in addition dummy condition type PNTP is introduced, which bypasses the calculation logic of the subtotal line item. It is mainly used to print a consistent net price line/net value line. With condition basis formulare 3 here from condition value a condition amount is calculated, which due to the standard pricing logic multiplied with the quantity results in the net value. Condition value formular 906 finally determines the net price and the net value resulting from it as price information.

In the last subtotal line item "net value" as described, theoretically a different net price may result; but it is of no importance.

b) For 10 pieces: PR00 Price 135.50 $ for each piece 1355.00 $

RA00 Discount 9.00- % 121.95- $

NETP Round. diff 123.31 $ for each piece 0.05 $

PNTP Net price 123.31 $ for each piece 1233.10 $

Net value 123.31 $ for each piece 1233.10 $

The net prices differ in both cases by 0.01 $.

Pricing procedure variant 2:

Pricing type Description Requ. Calc.formula BasFrm Stat Print PR00 Gross price 2

RA00 Discount 2 19

NETP Round. diff 2 6 17

PNTP Net price 2 906 17 X X

Net value 2

...

Features:

Net value = Net price * quantity.

Net price is invariable.

Discount calculated correctly.

Furthermore, this variant ensures that the net price is always the same.

Instead of condition type RA00, the following condition types can also be used with the following formulas:

Description Calc. formula Calc. type

RA00 Percent of gross amount 19 A

RA01 Percent of reduced amount 20 A

RC00 Quanity discount 19 C

RD00 Weight discount gross amount 19 D

RE00 Weight discount net amount 19 E

RF00 Volume-based discount 19 FAny number of discount conditions each with the corresponding value formular can stand before the NETP condition.

Mode of operation of variant 2:

a) For 3 pieces: PR00 Price 135.50 $ for each piece 406.50 $

RA00 Discount 9.00- % 36.59- $

NETP Round. diff 123.31 $ for each piece 0.02 $

PNTP Net price 123.31 $ for each piece 369.93 $

Net value 123.31 $ for each piece 369.93 $

In contrast to variant 1, here the discount is calculated by condition value formula 19 directly from the net price, thus, the net price no longer results from a division of net value by quantity. As a result, the net price is always the same. This net price calculated this way is then set as a condition rate in condition base formula 17. However, the standard procedure in which the discount is calculated from the net value runs parallel. In condition value formula 6, now the difference between the product net price * quantity and the net value calculated independently from it is determined again. The net value is then corrected by this amount. Using condition value formula 906, the condition type PNTP resets the net price and net value determined this way.

b) For 10 pieces: PR00 Price 135.50 $ for each piece 1355.00 $

RA00 Discount 9.00- % 121.95- $

NETP Round. diff 123.31 $ for each piece 0.05 $

PNTP Net price 123.31 $ for each piece 1233.10 $

Net price 123.31 $ for each piece 1233.10 $

In variant 2 the relationship is always "net price * quantity = net value" and the net price is always the same.

Pricing procedure variant 3 (so-called P-variant from R/2):

Pricing type Description Requ. Calc.formula BasFrm Stat Print PR00 Price 2

RA00 Discount 2 919

PNTP Net price 2 906 917 X X

Net value 2 X...

Features:

Net value = Net price * quantity.

Net price is invariable.

Discount not calculated correctly.

This variant also ensures that the relationship is always "net price * quantity = net value" and the net price is always the same. Rounding differences, however, are no longer displayed separately but contained in the discount.

Instead of condition type RA00 you can also use the following condition types with the following formulas:

Description Calc.formula Calc.type RA00 Percent of gross amount 919 A

RA01 Percent of reduced amount 920 A

RC00 Quantity discount 919 C

RD00 Weight discount gross amount 919 D

RE00 Weight discount net amount 919 E

RF00 Volume-based discount 919 F

By using formula 920 you continuously grant the discounts for the accumulated new value/net price. For formula 919 every discount for the net value/net price is calculated before the first condition to which formula 919 or 920 is assigned.

Any number of discount conditions (each with the corresponding value formula) can come before the PNTP condition.

Mode of operation of variant 3:

a) For 3 pieces: PR00 Price 135.50 $ for each piece 406.50 $

RA00 Discount 9.00- % 36.60- $

PNTP Net price 123.30 $ for each piece 369.90 $

Net value 123.30 $ for each piece 369.90 $

Here first the net price is calculated directly and then the net value is calculated from it. The discount is calculated by determining the difference between the new net value and the initial amount. If the discount calculated this way is then subtracted from the initial amount, you receive the first calculated net value again. This variant does not display any rounding differences since this differences are contained in the discount.

b) For 10 pieces: PR00 Price 135.50 $ for each piece 1355.00 $

RA00 Discount 9.00- % 122.00- $

PNTP Net price 123.30 $ for each piece 1233.00 $

Net price 123.30 $ for each piece 1233.00 $

Requirement 906 :

form frm_kondi_wert_906.

ykwert = xkwert.

ywaers = xkomv-waers.

ykbetr = xkomv-kbetr.

endform.

917 :

form frm_kond_basis_917.

xkwert = ykmeng.

xkomv-kmein = ykmein.

xkomv-kpein = ykpein.

xkomv-kumza = ykumza.

xkomv-kumne = ykumne.

xkomv-waers = komk-waerk.

if nettopreis is initial.

xkomv-kbetr = komp-netpr.

else.

xkomv-kbetr = nettopreis.

xkomv-kkurs = 100000. "acts as 1.00000

endif.

endform.

919 :

data: bruttopreis like komp-netpr.

form frm_kondi_wert_919.

data: nettowert like komp-netwr,

xkbetr like xkomv-kbetr.

• take into account only if active

check xkomv-kinak = space.

if nettopreis is initial.

nettopreis = komp-netpr. "in currency KOMK-WAERK

bruttopreis = nettopreis. "in currency KOMK-WAERK

endif.

• prepare local XKBETR

XKBETR = XKOMV-KBETR. "here XKBETR is in currency XKOMV-WAERS

• convert XKBETR from XKOMV-WAERS to KOMK-WAERK in two steps

IF XKOMV-KRECH NA PERCENTAL AND XKOMV-WAERS NE KOMK-WAERK.

• first step: convert XKBETR from XKOMV-WAERS to KOMK-HWAER

IF XKOMV-WAERS NE KOMK-HWAER.

CALL FUNCTION 'CONVERT_TO_LOCAL_CURRENCY'

EXPORTING

DATE = xkomv-kdatu

FOREIGN_AMOUNT = XKBETR

FOREIGN_CURRENCY = XKOMV-WAERS

LOCAL_CURRENCY = KOMK-HWAER

RATE = XKOMV-KKURS

TYPE_OF_RATE = KURSTYP

IMPORTING

EXCHANGE_RATE = XKOMV-KKURS

LOCAL_AMOUNT = XKBETR

EXCEPTIONS

OTHERS = 4.

ENDIF.

• second step: convert XKBETR from KOMK-HWAER to KOMK-WAERK

IF KOMK-WAERK NE KOMK-HWAER.

CALL FUNCTION 'CONVERT_TO_FOREIGN_CURRENCY'

EXPORTING

DATE = xkomv-kdatu

LOCAL_AMOUNT = XKBETR

FOREIGN_CURRENCY = KOMK-WAERK

LOCAL_CURRENCY = KOMK-HWAER

RATE = KOMP-KURSK

TYPE_OF_RATE = KURSTYP

IMPORTING

EXCHANGE_RATE = KOMP-KURSK

FOREIGN_AMOUNT = XKBETR

EXCEPTIONS

OTHERS = 4.

ENDIF.

ENDIF. "now XKBETR is in currency KOMK-WAERK

• prozentuale Konditionen

if xkomv-krech = 'A'.

nettopreis = nettopreis

+ ( xkbetr * bruttopreis ) / 100000.

• mengenabhängige Konditionen

elseif xkomv-krech = 'C'.

nettopreis = nettopreis

+ ( xkbetr * ykpein * ykumza * xkomv-kumne )

/ xkomv-kumza / xkomv-kpein / ykumne.

• gewichts- oder volumenabhängige Konditionen

elseif xkomv-krech ca 'DEF'.

if komp-mglme ne 0.

nettopreis = nettopreis

+ ( xkbetr * ykpein * ykumza * xkomv-kawrt )

/ komp-mglme / xkomv-kpein / ykumne.

endif.

else.

xkomv-kinak = 'X'.

komp-prsok = ' '.

endif.

• Nettowert und Rabattbetrag bestimmen

nettowert = ykmeng * nettopreis / ykpein / 1000.

if not komp-shkzg is initial.

nettowert = - nettowert.

endif.

xkwert = nettowert - komp-netwr. " Rabattbetrag

endform.

920 :

form frm_kondi_wert_920.

data: nettowert like komp-netwr,

xkbetr like xkomv-kbetr.

• take into account only if active

check xkomv-kinak = space.

if nettopreis is initial.

nettopreis = komp-netpr. "in currency KOMK-WAERK

bruttopreis = nettopreis. "in currency KOMK-WAERK

endif.

• prepare local XKBETR

XKBETR = XKOMV-KBETR. "here XKBETR is in currency XKOMV-WAERS

• convert XKBETR from XKOMV-WAERS to KOMK-WAERK in two steps

IF XKOMV-KRECH NA PERCENTAL AND XKOMV-WAERS NE KOMK-WAERK.

• first step: convert XKBETR from XKOMV-WAERS to KOMK-HWAER

IF XKOMV-WAERS NE KOMK-HWAER.

CALL FUNCTION 'CONVERT_TO_LOCAL_CURRENCY'

EXPORTING

DATE = xkomv-kdatu

FOREIGN_AMOUNT = XKBETR

FOREIGN_CURRENCY = XKOMV-WAERS

LOCAL_CURRENCY = KOMK-HWAER

RATE = XKOMV-KKURS

TYPE_OF_RATE = KURSTYP

IMPORTING

EXCHANGE_RATE = XKOMV-KKURS

LOCAL_AMOUNT = XKBETR

EXCEPTIONS

OTHERS = 4.

ENDIF.

• second step: convert XKBETR from KOMK-HWAER to KOMK-WAERK

IF KOMK-WAERK NE KOMK-HWAER.

CALL FUNCTION 'CONVERT_TO_FOREIGN_CURRENCY'

EXPORTING

DATE = xkomv-kdatu

LOCAL_AMOUNT = XKBETR

FOREIGN_CURRENCY = KOMK-WAERK

LOCAL_CURRENCY = KOMK-HWAER

RATE = KOMP-KURSK

TYPE_OF_RATE = KURSTYP

IMPORTING

EXCHANGE_RATE = KOMP-KURSK

FOREIGN_AMOUNT = XKBETR

EXCEPTIONS

OTHERS = 4.

ENDIF.

ENDIF. "now XKBETR is in currency KOMK-WAERK

• prozentuale Konditionen

if xkomv-krech = 'A'.

nettopreis = nettopreis

+ ( xkbetr * nettopreis ) / 100000.

• mengenabhängige Konditionen

elseif xkomv-krech = 'C'.

nettopreis = nettopreis

+ ( xkbetr * ykpein * ykumza * xkomv-kumne )

/ xkomv-kumza / xkomv-kpein / ykumne .

• gewichts- oder volumenabhängige Konditionen

elseif xkomv-krech ca 'DEF'.

if komp-mglme ne 0.

nettopreis = nettopreis

+ ( xkbetr * ykpein * ykumza * xkomv-kawrt )

/ komp-mglme / xkomv-kpein / ykumne.

endif.

else.

xkomv-kinak = 'X'.

komp-prsok = ' '.

endif.

• Nettowert und Rabattbetrag bestimmen

nettowert = ykmeng * nettopreis / ykpein / 1000.

if not komp-shkzg is initial.

nettowert = - nettowert.

endif.

xkwert = nettowert - komp-netwr. " Rabattbetrag

endform.

Regards,

Lionel

[Former Member]

Still Not Solved, Can anyone help.

Thanks,

Raja

[Former Member]

Try to have 3 or 4 decimal places and then your problem might be resolved.

For this you will have to define a new currency for ex:US$ and have 3 decimal places assigned to it and make this currency as priary currency. Then maintain the ratio between USD and US# as 1:1.

Look at T.codes OY03, OY04

Regards

Sai

[Former Member]

What is the Base unit of measure, Sales unit of measure and Unit of measure (which maintained in condition records)?

[Former Member]

Hi,

Pl check the rounding rule in the condition type for Basic price and discount.

Path: IMG->Sales& Distribution->Basic Functions->Pricing->Pricing Control->Define Condition Types-> Maintain Condition Types.

The rules are as under;

In the standard rounding rule '_' Commercial rounding , values are rounded off according to business standards:

10.454 -> 10.45 INR

10.455 -> 10.46 INR

In rounding rule 'A', values are always rounded up:

10.459 -> 10.46 INR

10.451 -> 10.46 INR

In rounding rule 'B', values are always rounded down:

10.459 -> 10.45 INR

10.451 -> 10.45 INR

In standard condition types like PR00 Commercial rounding rule is active, hence minor discrepancies will occur. Hence, if that has to be avoided use rule A or B , which ever is applicable.

Hope the above was helpful, kindly reward points if so.

Regards,

Vinu