This question comes courtesy of Val:

I’m configuring a series of % discounts in SD. Each needs to apply a % to the price, not to the value (SAP default), so the price per unit decreases with each discount. The result is a slightly different final total value from the standard method. I can’t find a way in standard config, all I can do is a standard value: can you suggest anything? Do I need a custom requirement?

A subsequent email from Val gets us closer to the issue:

[When calculating the discounts at the Net Value and Item Value levels] you’ll see that they come out with slightly different totals. The difference is larger or smaller depending on the quantity and price, and it still exists if you take the rounding off.

If the above statements aren’t crystal clear, here is a more concise summary: In certain circumstances, percentage-based discounts and surcharges sometimes calculate differently from what you would expect. Let me illustrate with an example:

A discount of 9% is granted for an article with a price of $135.50 per piece. The exact discount is then $12.195 and the net price $123.305. The standard pricing returns the following results:

a) For 3 pieces:

PR00 Price $135.50 per piece $406.50

RA00 Discount 9.00% $36.59

Net value $123.30 per piece $369.91 (instead of $369.90)b) For 10 pieces:

PR00 Price $135.50 per piece $1355.00

RA00 Discount 9.00% $121.95

Net value $123.30 per piece $1233.05 (instead of $1233.10)

The above examples come directly from SAP Note 80183. It explains that SAP calculates the unit value by dividing the net value by the quantity. Other systems — belonging to a customer, for example — may apply the discount to the * unit price* and then multiply the unit price by the quantity to reach the net value.

# Why is this a problem?

*So what if the Net Value is off by a few pennies? * Well, actually, the variance can grow significantly depending on the quantity and other types of calculations in the Pricing Procedure. What starts off as a penny can quickly grow. This variance could be large enough to disrupt automated EDI processes with failed pricing validations.

# What is the solution?

Fortunately, there are some solutions that may be able to help address this issue:

### Discuss the use of a pricing tolerance with your customer to allow for any rounding discrepancies.

If EDI validations are a concern, you can discuss the possibility of allowing for small price differences on the order line item level. SAP delivers standard Conditions Types EDI1 and EDI2 to manage this. EDI1 is used for ‘Customer Expected Price’; the value in this condition is compared to the unit price. A tolerance is specified in calculation type ‘9’; if the variance between these is within the tolerance then the order continues processing. Otherwise, the order is considered incomplete and must be reviewed and corrected. The tolerance value can be changed by copying the routine (FV64A009) to a new one and changing the “maximum” value.

EDI2 behaves the exact same way, except it compares the line item Value instead of the unit price. It uses calculation type ‘8’ (FV64A008).

### Use a different Pricing per 100 EA to get additional decimal places

You can try using different Pricing Units to either gain or reduce the number of decimals used in the calculation. In most cases, you probably price per 1 each, or per 1 case. Pricing

per 10 eaches or 100 eaches will change the nature of the calculation and may reduce instances of issues. It’s worth noting that I haven’t thoroughly tested this theory as of yet.

### SAP Note Solution: 80183

SAP Note 80183 includes a ‘consulting’ solution, since this isn’t a “bug” per se. * You will need to refer to the Note for the full solution. *The solution contains details behind three methods; each shares basically the same process. Here’s the summary:

*Set up the condition type NETP (rounding difference, not for variant 3, transaction V/06)**Set up the condition type PNTP (net price, transaction V/06)**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 want to use only condition value formula 920 but not 919, you should still create formula 919 completely because it contains a data definition for formula 920.**Change your pricing procedure according to one of the following three variants (specified in the note).*

Each of the three methods noted in the Note perform their actions slightly different; you’ll need to determine which one meets your specific requirement. In each case, the NETP and PNTP conditions are used to align the Unit Price and Net Price to be divisible evenly.

# Wrap Up

If you stay in the SD consulting game long enough, you’re bound to deal with rounding issues such as the one detailed above. While I wouldn’t describe SAP’s calculation method as quirky, it is different enough to cause the occasional inconsistency. Hopefully, one of the above methods can help you deal with this scenario. If so, let me know in the comments below.

Hi,

We have an issue that we have rates down to 100,000th of a cent . do you know a way to make this work without using a new non-USD currency since SAP only goes to 5 digit calculation .

For example, we have .0006587 rate

This is not an uncommon issue. People often feel limited by SAP’s five digit decimal. The best way around this is to price your product by a quantity greater than one. To use your example, you could price your product at $.6587 per 1,000 EA. This effectively does the exact same thing as an additional decimal. This requires some education and discipline by those maintaining conditions, but this solution is far less risky than introducing USDN or some other currency.