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
Hi Michael,
How did you create the Condition formula for alternative calculation type = 906?
We currently don’t have it in our system, but from your screenshot (under https://i2.wp.com/michael.romaniello.co/wp-content/uploads/2016/05/NETP-and-PNTP.png?ssl=1) this is already created and in place for the standard pricing procedure.
Appreciate your valuable responses.
Cheers,
Edward
Edward, if the routine is referenced in the SAP Note (which it is), that typically means it was delivered by SAP. However, since it starts with a “9”, that also means it is not a standard SAP object. I think it SHOULD get created when you implement the note referenced in my article. Here is what the SAP note contains in the correction:
form frm_kondi_wert_906.ykwert = xkwert.
ywaers = xkomv-waers.
ykbetr = xkomv-kbetr.
endform.
Hi Michael,
great article, I am trying to implement note 80183 (variant 2) to over come rounding issue.
appreciate if you can clarify questions below
1) I cannot see Caltype (906) in the system, is it something that needs to written if yes whats the logic behind it.
2) what function PNTP performs?
Thanks
Umar
Thanks for the question, Umar. Here are my responses:
(1) The routine 906 is delivered as part of the SAP Note you mention (80183). You can look at the development correction instructions in the Note to see the logic. I have also pasted it in my response above to Edward.
(2) The PNTP effectively becomes your adjusted net price while the NETP condition contains the rounding difference. The whole point of the note is to ensure that the net price is divisible by the quantity to arrive at the unit price. The solution is calculating the rounding difference and then using that to determine what the adjusted net price will be.
I hope that this helps. -Michael
Thanks Michael for your prompt response, I managed to find the code for the calculation 🙂 and just to be clear PNTP will be the net price after discount (without rounding issue)?
Hi Michael,
I have added a Freight condition type KF00 in the pricing procedure before the Net Value calculation for the Item, without any sub-totals. But the Freight cost is not getting added to the Net value. Please help me know what could be missing.
Hi, Peeyoosh. Thanks for the question. Typically, the issue here would be that the freight line is not included in the calculation scope of the Net Value line. The Net Value line will have a “From” and “To” line reference and the freight amount would need to be within those lines. Also, make sure that your freight condition is not set as statistical. Hopefully it is one of those two things. -Michael