First off, this post is mostly stemming from frustration. So, if you’re expecting some sort of magic bullet to handle cumulative graduated pricing, I can’t offer you much. What I can offer you is a list of options, how they work, and why they may not fully satisfy the requirement. It seems simple: You want to offer your customers gradually reduced pricing — or gradually increased discounts — as they purchase throughout the year across multiple sales orders. Though seemingly simple, the solution is not.
Over the course of the past few weeks, my research has turned up several methods for accomplishing similar processes, but only one method for accomplishing this exact scenario. Now, some of you may be saying, “Why not just develop a custom pricing formula to achieve your goal?” Of course, that is an option. And that’s the source of my frustration; I can get to 99% of the requirement using standard SAP functionality, but it’s that last 1% that may make the custom code necessary.
First, let’s examine the requirement.
To do so, let’s analyze the phrase “cumulative, graduated pricing”. To be considered cumulative, the process must consider the total volume of orders for a given customer over a period of time — not just the volume of a single order.
Further, to be considered graduated, you must be able to apply several different prices or discounts to a single line item. Let’s use an example:
You normally offer your customer a unit price of $4.00 / lb for a particular material and the customer typically purchases from you in increments of 50 – 100 lbs. You wish to incentivize your customer by offering the first 100 lbs at the $4.00 rate, but offering the NEXT 100 lbs at a reduced rate of $3.90 / lb. And to complicate things further, you want to offer the third 100 lbs at an even lower price of $3.80 / lb.
This creates three tiers of pricing. But, this is not considered Scales per se. The example plays out over the next three sales orders:
- Order 1: Total quantity of 80 lbs
- 80 lbs @ $4.00 = $320.00
- TOTAL = $320.00
- Order 2: Total quantity of 80 lbs
- 20 lbs @ $4.00 = $80.00
- 60 lbs @ $3.90 = $234.00
- TOTAL = $314.00
- Order 3: Total Quantity of 80 lbs
- 40 lbs @ $3.90 = $156.00
- 40 lbs @ $3.80 = $152.00
- TOTAL = $308.00
While this is not rocket science, it is just tricky enough to cause problems.
There are a number of solutions that came to mind when initially thinking about this issue, but each had its own snag:
The first thing you think of when you see this type of requirement is the normal, run-of-the-mill scales functionality as it exist in the condition record. While being brilliant at calculating price breaks, the functionality is limited to one single order. A normal scale typically delivers just one price. So, in our example above, an order of 150 lbs would get you one price of $3.90 for the entire order (150 x $3.90 = $585.00). This is not correct per our scenario.
However, there is an option called graduated scales which will perform like we need. You just select scale type “D” (“Graduated-to interval sc”) on your condition type. Using this method would get you the desired behavior in the scenario. An order of 150 lbs would get you two prices: 100 @ $4.00 and 50 @ $3.90 = $595.00. Unfortunately, we’re still limited to just one single order.
The condition update function is also a setting on the condition type in the IMG. This checkbox tells SAP that you want to consider additional criteria when applying the condition. Here’s how it works.
Set the update condition indicator on your price or discount/surcharge condition type and save it. Next, create your condition using VK11. Apply your scales as needed. Navigate to the Additional Sales Data screen and you will notice a new section titled Limits for pricing. Three fields are now available for you to use:
Max.condition value allows you to specify a maximum dollar amount that a customer can receive from the promotion. For example, you give your customer a 10% discount through this condition but you only want them to receive a maximum cumulative discount of $1,000.00. At that point, the condition will cease to apply automatically.
- Max.number.of.orders allows you to specify a limit to the number of documents that can apply the condition. This would be ideal if you wanted to give your customer a discount off the next 3 orders regardless of when they are made.
- Max.cond.base value is quite similar to the Max.condition value, only it applies to the base. For example, you offer a 10% discount per case of product and you want to only apply this discount to the next 10 cases.
Behind the scenes, SAP is utilizing a standard SIS structure (S071, Condition Update) to capture sales volumes and for use in pricing calculations. These functions work great for their respective examples, but don’t help us out much in our scenario — reason being that these limits only apply to one single condition type. In order for this to work for my scenario, I would need to have these limit fields available at each individual scale. After realizing this, I thought that perhaps I could use an array of condition types to represent the different tiers.
Condition Update + Exclusion Groups
Since the limits enabled through the Condition Update function cannot be placed on the individual scales, perhaps a good approach would be to use an array of pricing conditions to represent the individual tiers. So, to go back to our example, we could do the following:
CnTy Description Amount Max.Cnd.Base Z001 Pricing Tier 1 $4.00/lb. 100 lbs Z002 Pricing Tier 2 $3.90/lb. 100 lbs Z003 Pricing Tier 3 $3.80/lb. 100 lbs
Assuming these conditions have the Condition Update setting enabled, the above structure should be able to get us closer to our requirement. We have the tiers. We have the ability to max out each condition value using the Max Condition Base field on the condition record. But not quite. If maintaining this configuration and data alone, it would result in all three conditions appearing on the Sales Order line item at once. Ideally, to fit our scenario, SAP would allow us to specify not just the upper limits for the Condition Update, but also the minimums. In theory, this would allow us to maintain a $3.90/lb. rate for tier two, but only after 100 lbs. has already been ordered. So how do we only select the one condition type needed for the sales order line item?
One answer to this question is Exclusion Groups. Creating an exclusion group allows you to specify a set of conditions that are likely to be applied to a sales order and create a rule telling SAP which condition to apply and which to ignore. For our scenario, we could create an exclusion group called Tiered Pricing and assign condition types Z001, Z002, and Z003.
Finally, we would assign our exclusion group to our desired pricing procedure and specify which rule to use. In our case, we would want to use rule ‘L’ which selects the “Least favorable between conditions types” because we would want to exhaust the quantity at the $4.00 rate before offering the $3.90 rate.
This would select the highest price from our three condition types.
So now we’re a step closer, but we’re still not quite there. Here’s why: Eventually, the orders in our scenario will cross the threshold between the different tiers. When this happens, we will need to potentially determine two different conditions types on one line item. If the customer orders 101 lbs of product from our scenario, 100 lbs. will be at the $4.00 rate and 1 lb. will have to be at the $3.90 rate. The limitation of the exclusion group is that only one rate can be determined — meaning that ONLY the $4.00 rate will be determined for that example. Bummer.
Oddly enough, this is the option that gets me the closest to the requirement. In fact, it 100% meets the requirement if your client has the appetite for implementing the Rebate Management process and making a fairly significant process change — namely taking an accrual vs. determining a price and offering the customer a monthly check instead of an immediate discount.
In order to implement a proof-of-concept, I created one Rebate Pricing Condition — copied from Bo01 thru Bo06 — making sure to select the Scale Type ‘D’ (Graduated-to interval scale). I inserted it into my Pricing Procedure then assigned it to a new Condition Type Group. I copied one of the standard SAP agreement types and assigned it to my new Condition Type Group. After all that’s done, you should be able to create your new Rebate Agreement using VBo1. Add your new condition type, maintain your desired scales and save. That’s the setup.
The function in terms of rebate calculation is exactly what you would need for our scenario. By default, the rebate agreement considers cumulative order amounts when calculating accruals from the scales. There is no need for an Update Condition setting — in fact, the setting doesn’t exist on rebate conditions. I’ve tested the calculations several times, and it’s always spot-on: each tier is calculated correctly. If a line item crosses tiers, it captures the correct rates for the correct quantities. The rest of the rebate process — accruals, reporting, settlements — works as it always has.
Custom ABAP programming
Yes. Creating custom code is always an option and it’s almost always worth mentioning. But as a functional consultant, I prefer to keep as much control in my own two hands as possible. Business functions controllable through configuration and master data are more flexible and predictable than functions involving custom logic.
That said, considering this scenario, if my client is unwilling to jump to Rebate Processing my options are limited. I haven’t designed a custom solution for this particular scenario, but several alternatives have been suggested. In my opinion, the most logical starting point would be the “Condition Update” or “Condition Update + Exclusion Groups” process mentioned above. The only missing piece of this solution is the ability to maintain two rates on one line item. A custom Condition Base Value Formula (using VoFM) may be able to fill this gap. Taking this approach would still leave most of the control in the hands of users and their SD consultants.
Based on the amount of online discussions I’ve seen on this and related topics, I think cumulative graduated pricing is a process that is not completely uncommon in the SAP community. It’s clear, however, that SAP intends for this type of requirement to be handled through the Rebates process. While this process delivers several advantages over a simpler conditions-based process, oftentimes users are just looking for that simpler solution. It would be great if we had a choice in satisfying this requirement. Hopefully, this has given you some insight; if you have implemented one of the above solutions — or one I hadn’t considered — please drop me a line below. I’d love to know.