Thursday, May 5, 2011
sap sd pricing error rounding condition
Refer SAP note 80183 regarding Rounding.
1. Values calculated in pricing are always rounded to the amount of decimal places which the used document currency owns. As subsequent processing steps setup on this rounded value rounding differences can occur in the calculation of the price per unit or in subtotal line. To bypass such effects note 80183 describes possible solutions to reduce / bypass this effect.
A few problems in rounding after applying note 80183, variant 2 have been recorded where it was recommended to use the formulas 919 and 920 on all discounts and surcharges that appear before NETP and the problem was solved.
2. In transaction V/06 there is a field under header 'Control data1' which can effect how the system rounds off condition values during pricing:
- Rounding rule The rule that determines how the system rounds off condition values during pricing. The last digit will be rounded.
Example
- In the standard rounding rule '_', values are rounded off according to business standards:
10.454 - 10.45 DEM
10.455 - 10.46 DEM
- In rounding rule 'A', values are always rounded up:
10.459 - 10.46 DEM
10.451 - 10.46 DEM
- In rounding rule 'B', values are always rounded down:
1045.9 - 1045 LIT
1045.1 - 1045 LIT
In this example, the currency of the condition rate is Italian Lira. The Italian Lira does not have any places after the point.
3. Also check if the condition type is set as item condition as well as group condition in transaction V/06. What this means is that the system will calculate the value of the condition on header level and compares it with the sum of item values in the document.
Any rounding difference (KONV-KDIFF) detected, will be populated in the line item with greatest value or in first line item if all are of equal value.
In other cases where there is no adjustment because there is no rounding difference when comparing the header value and the sum of item values.
- Solution to this scenario -
If you remove the 'group condition' setting, the system will then calculate amount for the items directly and you will not get the
rounding. You must decide which setting is more suited for your business. This is not a bug, but works as per designed.
1. Values calculated in pricing are always rounded to the amount of decimal places which the used document currency owns. As subsequent processing steps setup on this rounded value rounding differences can occur in the calculation of the price per unit or in subtotal line. To bypass such effects note 80183 describes possible solutions to reduce / bypass this effect.
A few problems in rounding after applying note 80183, variant 2 have been recorded where it was recommended to use the formulas 919 and 920 on all discounts and surcharges that appear before NETP and the problem was solved.
2. In transaction V/06 there is a field under header 'Control data1' which can effect how the system rounds off condition values during pricing:
- Rounding rule The rule that determines how the system rounds off condition values during pricing. The last digit will be rounded.
Example
- In the standard rounding rule '_', values are rounded off according to business standards:
10.454 - 10.45 DEM
10.455 - 10.46 DEM
- In rounding rule 'A', values are always rounded up:
10.459 - 10.46 DEM
10.451 - 10.46 DEM
- In rounding rule 'B', values are always rounded down:
1045.9 - 1045 LIT
1045.1 - 1045 LIT
In this example, the currency of the condition rate is Italian Lira. The Italian Lira does not have any places after the point.
3. Also check if the condition type is set as item condition as well as group condition in transaction V/06. What this means is that the system will calculate the value of the condition on header level and compares it with the sum of item values in the document.
Any rounding difference (KONV-KDIFF) detected, will be populated in the line item with greatest value or in first line item if all are of equal value.
In other cases where there is no adjustment because there is no rounding difference when comparing the header value and the sum of item values.
- Solution to this scenario -
If you remove the 'group condition' setting, the system will then calculate amount for the items directly and you will not get the
rounding. You must decide which setting is more suited for your business. This is not a bug, but works as per designed.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment