Skip to Content
author's profile photo
Former Member

Rounding Issue with Pricing Conditions

Currently we have in place a pricing hierchery that consists of two pricing conditions. ZP for base price and ZD for a +-differential. Both conditions begin with 00. ZP00. ZP01, ZP03, ZP04. If a ZP01 exists it overrides a ZP00. If a ZP03 exists it overrides ZP00,ZP01, etc. So basically the higher the number means it overrides anything underneath it. The ZD conditions are setup exactly the same way. I am currently running into a round issue. We settle all transactions in USD however the manual and differentials are often based on prices that go out more than 2 decimal places. SAP is treating the calculation for the ZP and ZD as two separate calculations. It rounds each of them and then combines for a total price. So if the base price ZP02 is $2.245 multiplied by quantity 3,999 = $8,977.755 which it rounds to $8,977.76 and the differential ZD02 is $.0235 this = $93.9765 which it rounds to $93.98 for a total price of $9,071.74. However if you add the ZD02 + the ZD02 you get a total unit price of $2.2685. This multiplied times the quantity 3,999 = $9,071.731 which is correct. But because SAP does each calc separately the price comes out to $9,071.74 or off 1CT. I have seen various solutions on how to fix this from user exits to creating additional conditions that takes both ZP and ZD conditions and calculates them as one but I was hoping someone had come up with something better? Or if there was a preferred method?

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • author's profile photo
    Former Member
    Posted on Sep 28, 2007 at 08:41 PM

    Good Evening,

    1. Please review NOTE 80183 regarding Rounding.

    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

    o In the standard rounding rule '_', values are rounded off according

    to business standards:

    10.454 -> 10.45 DEM

    10.455 -> 10.46 DEM

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

    10.459 -> 10.46 DEM

    10.451 -> 10.46 DEM

    o 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.

    EXAMPLE: MWST - tax condition (a group condition)

    Item 10 16% of 100.90 = 16.14

    Item 20 16% of 100.90 = 16.14

    Total = 32.28

    I hope this helps you!

    Kind Regards,

    Martina McElwain

    SD Forum Moderator

    Add comment
    10|10000 characters needed characters exceeded

  • Posted on Sep 29, 2007 at 05:36 AM

    Brandon,

    Go to V/06...Select both Group Condition and Item condition...

    Then try again...

    I think Martina has explained in more details......

    Regds

    MM

    Add comment
    10|10000 characters needed characters exceeded