This question on SAP discounts 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 SAP 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.

Hi

We got stuck with the issue. Below is my scenario,

Quantity = 200

Price = 441.86

Discount= 6%

Now Value that SAP maintaining after discount in SAP

441.86 88,372.00

6.000- 5,302.32-

415.35 83,069.68

Client is calculating in this manner

415.35 * 200 = 83070

As per SAP we are getting net value 415.3484(back-end) and user wants to make it 415.35 and i am not able to do it.

I have maintained routing 2 decimals in condition base value VOFM. but no result.

Please suggest. I will be grateful to you

Best Regards

Sarah

Sarah, thank you for commenting. I’m assuming that you read the article; did you read Note 80183? If so, are you trying to implement one of those solutions?

Thanks for the reply. Yes i have read this note and I have copied all the routines created into VOFM. i will update you if i face any issue,

Thanks

Sarah

Hi Michael,

I have applied this note and its working fine. But i am facing issue at discount level ERS.

As per note PNTP Req (2) Caltype (906) Basetype (3) ERL

I have a GL for Discount as well (ERS) but i am only getting ERL (PNTP)

Kindly Suggest how to populate 2 GLs (ERL and ERS) using PNTP

Thanks

Sarah

Sarah, Sorry for the delayed reply. It sounds like you’re referring to the Accrual Key? It’s not clear what you want to accomplish. I don’t think it’s possible to have one condition (PNTP) hit two G/L accounts and I’m not sure why you would want to. Can you elaborate? -Michael

I have another question.

My customers have different price based on discount %. So that means my PR00 should not be the regular price but Regular price – customer discount for each material.

Example:

Wholesale customer PL for material 123 = $10

Same material for my customer has a price of WS – 1% = $9

Therefore PR00 needs to be wholesale PL ($10) – 1% (-1) = 9

Is there a routine for this, or should I have one created?

Hi Michael,

Great article !

I’m trying to make VAR 3 of 80183 work for a scenario where we have several discounts going of a sub-total. 920 is always cumulative so we have ruled it out. If I use 919 alone, I see the unit price changing with the quantity and I see that 919 can be used only once in the procedure. All the % based discounts which have 919 assigned after the first condition type have zero condition value.

Does it mean VAR 3 does not work for the scenarios where several discounts are based on sub total?

Appreciate your inputs.

Thanks

RM