SAP Logo

SAP: Cumulative, Graduated Pricing and Discounts

First off, this post is mostly stemming from frustration.  So, if you’re expecting some sort of magic bullet to handle this scenario, 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.

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.

POTENTIAL SOLUTIONS

There are a number of solutions that came to mind when initially thinking about this issue, but each had its own snag:

Scales

Run-of-the-mill Scales as seen in VK12.
Run-of-the-mill Scales as seen in VK12.

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.

Scale Type "D":  Graduated to Interval.
Scale Type “D”: Graduated to Interval.

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.

Condition Update

The 'Condition Update' setting on the Pricing Condition configuration screen.
The ‘Condition Update’ setting on the Pricing Condition configuration screen.

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:

  • 'Condition Update' enables limits to be maintained on the condition record.
    ‘Condition Update’ enables limits to be maintained on the condition record.

    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.
The S071 structure is used to store 'Condition Update' sales volumes.
The S071 structure is used to store ‘Condition Update’ sales volumes.

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?

Condition Exclusion configuration nodes in the IMG.
Condition Exclusion configuration nodes in the IMG.

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.

Assigning an exclusion group to a Pricing Procedure with rule 'L'.
Assigning an exclusion group to a Pricing Procedure with rule ‘L’.

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.

Available rules for condition exclusion.
Available rules for condition exclusion.

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.

Rebate Agreements

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.

CONCULSION

Based on the amount of online discussions I’ve seen on this and related topics, I think this 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.

SAP: Cumulative, Graduated Pricing and Discounts was last modified: April 21st, 2014 by michael

45 thoughts on “SAP: Cumulative, Graduated Pricing and Discounts”

  1. Do you know of any way to scale an accrual?
    Example 0-3,500,000 no rebate
    3,500,000-4,000,000 1.5%
    4,000,000-4,500,000 2.0%
    4,500,000-5,000,000 2.5%
    5,000,000+3.0%
    The issue I am having is I can only apply 1 accrual rate. Do you know of any way either programatically or functionally to fulfill this requirement.

    Thanks,

    Troy

    1. Thank you for your question, Troy. If this is for a cumulative accrual — across many documents over a period of time — then I think a rebate agreement is your best bet. If your rebate condition allows for scales, you can maintain the “Amount” and the “Accruals” values independently for each scale level. This is intended to allow you to accrue at a different rate than the Amount your customer/partner is earning so you’re not hit with a huge windfall when your customer hits the 3.5M threshold. Thoughts?

      1. Thanks Michael, I was able to achieve what I was looking for. Since only one accrual rate could be applied and not scaled and the business did not want to use a blended rate and accrue for something that may never occur as there is a possibility the first threshold may not be met. They chose to review the rebate at month end and accrue via a journal entry.

        Thanks again,

        Troy

  2. That’s very well explained. I have also have a very tricky / complex scenario on the discount. The material is entered in ‘each’ but has got the alternative uom as Pallet, which is equal to 180 each.
    Discount needs to be applied as follows

    1) any where from Quantity 1 to 179, the discount is 5%
    2) at 180 it is 10 %
    3) at 360 each at 15% and so forth at the incremental of 180.

    if the sales order quantity is 230 each, then discount should be given as
    a) 180 quantity at 10%
    b) The remaining quantity (230-180=-50) should be given at 5%

    and so forth so on …

    appreciate any heads up.

    Thanks
    prab

    1. Hi, Prab. Thanks for the question. I think the scenario you describe is very similar to what I was trying to achieve. If your discount is to be applied ONLY to a single order, then you’ll want to check the Graduated Scale functionality. As I mentioned in my post above, “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.” Only, in your case, you would want to have a graduated scale on your discount condition. That should get you what you want. Let me know if that works or if I am not understanding your scenario. -Michael

  3. Hi Michael, Thanks for your time and reply. Graduated scale did not work on this scenario. Here is what I am trying to do ..

    order quantity: 250

    I have maintained the Graduated scale and condition record as
    to—179 = 5%
    to…359=10%
    to.. 539=15%

    So discount should be applied as follows
    Quantity 180= @10%
    remaining Quantity (250-180=30) should get discount @ 5%.

    What system does with a graduated scale in this scenario is
    it gives
    1. 179 Quantity gets 5%
    2. 71 quantity gets 10%

    My requirement is basically a complete and incomplete palette discount.

    Quantity would be entered in Each, and the alternative UOM is palette. so 1 palette is 180 Each

    if 250 quantity is entered in the order, then 180 quantity should get 10% and the remaining quantity 30 should get 5% discount.

    I was thinking to solve this with 2 condition type ( full palette, and incomplete condition type KP00, & KP01 ) Or do a Scale formula. Any suggestion please.

    Thanks
    prab
    prabgow@gmail.com

    1. Hello. I think your requirement is more clear now. My interpretation is that you want a 10% discount for all product in multiples of 180 ea. In your example of 250, 180 ea should get the 10% and 30 ea should get the %5. To expand upon the example, if you have a quantity of 380, then 360 ea (2 full pallets) should get 10% and the remaining 20% should get the 5%. Is this correct?

      If so, then I think you are correct; scales are not going to satisfy this requirement. What you really need to look into is Pallet Discounts and Surcharges. You’ve already mentioned KP00 and KP01 which are the standard SAP conditions for handling these types of scenarios. The secret to their functionality is in their base value calculation formulas. You can see the standard configuration in one of the SAP standard Pricing Procedures. I hope it works for you! Let me know, if you can.

      1. The requirement is correct.
        Yes, I simulated this KP00 and KP01…both just works fine.
        Thanks much for the reply. Really appreciated.
        -prab

  4. Hello again Micheal,

    I have a similar requirement for another one of our clients and they do not wish to wait for the discount via rebate. The requirement is scaled on a month to month basis on cumulative hours.

    Scenario
    The first 100 hours in a month the client has a piece of equipment they are charged 15 dollars and the anything after that they are charged 10 dollars, which it accumulates over multiple sales orders.

    Any ideas or suggestions on how to handle with condition update and VOFM or other custom ABAP.

    Thanks again,

    1. Hi Troy,

      To meet this requirement, I would probably try to use two condition types. Here’s what I’d do:

      Setup a “Base Price” for the service at your $10/hr rate. This condition can have a longer validity period. Let’s say that you have a 1-year agreement with your customer; your base price condition would be valid 1/1/2015 thru 12/31/2015.

      Next, create a secondary pricing condition using the “Update Condition” indicator in Configuration. This will serve as your slightly-higher initial rate of $15 / hr. When you maintain your pricing condition in VK11, set the “Maximum Value” to 100 h on the “Additional Sales Data” screen. Since you want to reset everything monthly, you will need to create 12 pricing condition records for the year with validity periods matching each calendar month.

      After that, you want to create a Pricing Condition Exclusion Group with these two conditions included. You’ll want to set this exclusion group to take the Least Favorable price.

      The way this SHOULD work is that SAP will run through its pricing and find both condition records. Since it will take the least favorable price, it should determine the $15 rate initially. Once the 100 h is exhausted, it will no longer determine that condition record and should switch over to the “Base Price” of $10/h. Once the month is over, it should switch to the next month’s condition record and have the 100 h allotment available.

      In theory something like this should work, but I am not sure what will happen when you cross that 100 h threshold. If you have an invoice for 3 h and it’s the 99th, 100th and 101st hour I’m not sure how SAP will react.

      I’m trying to think of an alternative… Adding ABAP to a process like this gets messy because you would need to find a way to do reversals in the event that you over-bill, for example.

      Thoughts?

      Michael

      1. Thanks Michael,

        I appreciate the discussion on this.I was thinking of the same issue of over billing and how will that would be handled.Like yourself I keep reverting back to the rebate where I can fairly easily meet their requirement if they can accept a credit to their account or a cheque, I am going to talk to them more about this.

        Thanks again,

        Troy

  5. Hi Michael,

    I enjoyed reading your document here. It contains useful information with a lot of analysis details for different potential solutions. Thanks for sharing.

    I have a similar situation where I need to track customer’s sale orders volume over a defined period (eg. quarterly) and based on the customer’s order volume during that period, I want system to apply different scale price.

    For example: every time a Sale Order is booked for this Customer A, Product B, I want system to track the total Sales Order volume for this customer + product within the current quarter (or any defined time period) and depends on their sales order volume up to date, I want system to apply different scale price as following:

    Order Volume in Current Quarter Price Per Unit
    1-100 Units $100/PC
    101-200 Units $90/PC
    >=201 Units $80/PC

    As you already mentioned above, the Scale Basis config will trigger scale price based on Sale Order Qty, but that only works for single sales order or single line item. My understanding is that the Scale Type “D” won’t work for my scenario either. Is that correct? How about the Condition Update? I am not sure if I followed your explanation correctly. Will the Condition Update config be able to track the Sale Order volume for a customer over a defined period and apply correct scale price (Different price) based on the cumulative Order Qty?

    Appreciate any info/suggestion you can share.

    Thanks
    Hannah

    1. Hello, Hannah,

      Your scenario looks a lot like my scenario from the article. Unfortunately, I have yet to find that elusive “magic bullet” to solve this scenario. Here’s a quick summary of the approaches I tried and why they didn’t quite work:

      (1) Normal Scales: These only work in a single order. Scale Type “D” (Graduated To) fits our scenarios perfectly, but will only calculate within a single order.

      (2) Condition Update: This does work across orders thanks to its use of the S-table mentioned above. It can track and enforce limits on your condition amount. There are a couple of limits here: (a) I don’t think this will key off of quantities (only dollar amounts; for example, you can set a discount condition to apply up to $1,000 and then it will stop applying. (b) This is a binary setting; it’s either applying the condition, or it isn’t. In order to setup a multi-tier scenario, you would have to cobble together several conditions with these settings and have them switch off one at a time to get to your different tiers. This MIGHT work, but would be very difficult for users to setup and maintain.

      (3) Condition Updates with Exclusion Groups: I couldn’t get this to work properly, and even if I could, using multiple conditions introduces unwanted complexities.

      (4) Rebate Agreement: This is the only scenario that I could find which delivers (almost) all of my requirements with easy setup for the user. It’s the simplicity of the Scales pricing function with the cumulative nature of the Condition Update. The problem, of course, is that this is a new process (assuming that this is not currently used) and the discount/price change is not delivered immediately. Standard rebate processing uses a periodic settlement (weekly, monthly) to distribute the customer’s payment.

      I hope this clarifies the article a bit. Please let me know if you have any other thoughts. This is clearly a common requirement, and a problematic one also.

      Michael

      1. Hi Michael, thanks for writing back.

        For the Condition Updates setting, for my scenario, I think it might work if there is a way to set the minimum condition value (vs. maximum condition value). I am thinking to create 3 different condition types. For the sake of the discussion, let’s call them ZR01, ZR02, ZR03. They will all have the same access search sequence. Let’s say: by Customer/Product

        ZR01: $100/PC. Min. Condition Value: $0. This means by default, the customer should receive purchase price of $100/PC.

        ZR02: $90/PC. Min. Condition Value: $10,000. This equates to 100 units x $100/PC. This means, when the total sales orders value by Customer/Product within a defined time reaches $10,000 (sales order volume reaches 100 units or more), any subsequent orders will receive $90/PC.

        ZR03: $80/PC. Min Condition Value: $19,000. This equates to [(100 units x $100/PC) + (100 units x $90/PC)]. This means when the total sales order value by Customer/Product within a defined time period reaches $19,000 (sales order value reaches 200 units or more), any subsequent orders will receive $80/PC.

        Then, we can config the Condition Exclusion to allow the ZR03 takes precedent over the ZR02 and ZR01 if they are all determined. The same concept is applied to the ZR02 if only ZR02 and ZR01 exist. Unfortunately, there is no option to set the Min. Condition Value.

        As for the Rebates Agreement, that solution won’t be feasible for us because our customers are looking for an frontend discount/rebate, not the post sale or backend rebate.

        Have you ever thought about using Contract to create some sort of Contract price that represents a scale?

        For example, in my scenario, I would create 3 different contracts as following:

        Contract Document #1: Customer A, Product B, Quantity 100 Units, Start Date 10/01/2015. End Date 12/31/2015. Price $100/PC.

        Contract Document #2: Customer A, Product B, Quantity 200 Units, Start Date 10/01/2015. End Date 12/31/2015. Price $90/PC.

        Contract Document #3: Customer A, Product B, Quantity 10,000 Units, Start Date 10/01/2015. End Date 12/31/2015. Price $80/PC.

        Steps to execute:
        1) When Customer A orders the Product B the 1st time during this quarter for 10 Units, system will find the Contract Document #1 and create the Sales Order with reference to the Contract and copy pricing ($100/PC).

        2) Next, system will track the Order Qty up to date for this Customer A/Product B is 10 units.

        3) Next week, let’s say Customer A orders the Product B again for 80 Units, system will go search for the Order volume up to date (10 units + 80 units), and will again create the Sale Order off the Contract Document #1. Price will be copied from the Contract for $100/PC.

        4) System will continue tracking the Order Qty up to date for this Customer A/Product B. Total Sales order volume now goes up to 90 units (10 + 80).

        5) Still in this same quarter, Customers A orders the Product B again for 50 Units. System will go search for the Order volume up to date (10 + 80 + 50 = 140 units) and will create the Sales Order against the Contract Document #2. System will not find the Contract #1 because the Sales Order volume exceeds the Contract Qty (140 units vs. 100 units). Price will be copied from the Contract Document #2 ($90/PC)….

        6) and so on……

        This idea of using Contract might have a lot of holes for I haven’t given this a lot of thoughts. Also, I am not sure how reporting/price list will be done for this option. It also likely requires some level of customization/coding in order for the option to work. However, I just want to throw this out there and see if anyone has ever tried this option and what their thoughts are.

        Thanks-Hannah

        1. Hannah,

          Sorry for the delayed response. Hopefully, you were able to find a suitable solution. I have considered multi-line contracts as a potential solution to this. However, I find myself hard-pressed to recommend a solution which requires so much maintenance — be it multiple pricing conditions or multiple SD documents. As a functional consultant it’s difficult for me to concede that some requirements are best met with custom solutions.

  6. Hello, Really appreciate for your sharing!!!
    I have another scenario, and hope maybe you can give some suggestions.
    Client set the price PR00 on sub-group level (may contain many P/N), eg: sub-group A1 100/each (with scale price 90 if order 50), A2 110/each (scale price 100 if order 50)… if customer place an order to order A total 50 pcs (include sub-group A1 and A2), client hope to charge scaled price by A1 90*qty and A2 110*(50-qty).
    Regards,
    Yvonne

    1. Dmitry,

      Sorry for the delayed response. In the case of your requirement, you will probably need to add your partner function to the field catalog for rebate pricing. This will involve adding the “zz” field and updating the value in this field in the appropriate user exit. After that, create your new condition table, update your access sequence, etc.

  7. Hi Michael,
    I have a business Requirement to Configuring rebates on Aggregate Quantity Tiers, But the twist is Scale based Rebates are based on Ship to parties.

    Scenario:
    Sold to Party -100 has two Ship to parties

    SH – 200—Scale based Rebates for this SH is

    Quantity Rebates
    0 to 100 — 0.125
    100 to 300 — 0.100
    301 — > — 0.085

    SH – 210 —Scale based Rebates for this SH is

    0 to 100 — 0.115
    100 to 300 — 0.090
    301 — > — 0.075

    Same Material is used for deliveries.
    ———————————————————————————————-
    I Could Achieve for one SH based on the above example but when the second SH invoice is Created Rebate Agreement accruals are not calculating the way it should.

    Could you through some light as how to configure this requirement.

    1. Thank you for commenting, Vamshi. To the best of my understanding, the requirement you outline above should be achievable on a single rebate agreement consisting of 2 condition records — one for each Ship-to. The scale values are straightforward and shouldn’t give you any issues. Your rebate conditions should appear on your billing documents as expected. Can you elaborate on what issue you are having with the 2nd ship-to? -Michael

      1. The Issue has been Resolved, if the rebate scales are different specific to ship to’s for the same material group then. the accruals were not calculating correct in the Rebate agreement. Business has agreed on the proposal to have two rebate agreements based on the ship to groups.

  8. Hello Michael, Though my concern here does not relate directly to your topic, but thought of asking while you discussed on Rebate.
    I am working on S/4HANA 1511 platform and as per S/4HANA feature, rebate functionality is no more available and has been updated to Settlement Management under LO. Do you have any idea on how to settle the accruals once you have raised the invoice. I was trying to run a complete scenario but unable to close it with the last step which settlement of rebate. In case you have worked on it, you may wish share a piece of knowledge.
    Thanks in advance.

    1. Unfortunately, I haven’t dealt with the Settlement functionality in S/4Hana. If this behaves anything like the old version in ECC, then the accruals should be settled when a partial or final settlement is performed. Perhaps another reader could comment?

  9. Hello Michael

    The document was very helpful. I have similar kind of scenario.
    ———————————————————————————-
    At the moment we are charging 10$ for Part A to the customer.

    Once we have delivered the 60,000 pcs to the customer, the price for the new pieces will be 5$ i.e. Amortization cost will be removed from the original price.

    users are keeping track of the number of delivered pieces based on Invoices. Is it possible to setup the condition record where SAP will change the price for the part automatically based on the number of delivered pieces or is there any other solution available to meet the below requirement.

    Based on ur document i think that condition Update scenario will be applicable here but I have few queries.

    At the moment only one price is maintained with PR00 and we have already delivered the few pcs. Is it possible to implement in between?

    What happens if we create order for 100 pcs but deliver only 80 pcs. does it consider the actual quantity which is delivered or invoiced?

    1. Hi Jayesh,

      These are both questions that I contemplated. In general, I think that the Condition Update will be the best solution. There are probably a few options, but the one that makes the most sense to me would be a base PR00 of $5, in your example, and an additional Surcharge condition ZAM1 with your $5 Ammortization. You would make your ZAM1 “expire” after your 60,000 pc using the condition update.

      Regarding the partial delivery question… The condition update relies on the SIS structure mentioned in the article. It should only apply during billing document creation, but you would need to verify this. If it does apply during billing doc creation, then things like credits and returns may also affect these numbers.

      Regarding starting the process part-way through the agreed upon 60,000 pcs… I don’t think that the update condition can work retroactively like rebates. You could manually calculate how many units have been invoiced and then just make the Update Condition amount equal to the difference.

      Hope this helps.

      Michael

  10. Hi Michael,

    You have great blog , I am very pleased to visit it and thank you for contributing to the community in need . I have a few queries in the area of mm pricing . I request you to tell me based on your experience is, if the below design is possible.

    In the MM pricing procedure /schema the calculation are as below .

    Initial calculations – 1000000 @ 1% = 10000 Amount
    Total – 10000
    X-rev 50% – 5000
    Y-rev 20% – 2000
    Total 2: 7000
    Already settled amount – 2000
    Net – 7000-2000 = 5000

    What i want to calculate is the ratios equivalent values for Xrev and Yrev based on the net amount

    X Rev contribution – contribution = 5000*5000/7000 = 3571.43 – Account key posted to my OBYC accounts 1234

    Y rev contributions = 5000*2000/7000= 1428.57 – – Account key posted to my OBYC accounts 5678

    The above is for rebate calculations and they are calculated periodically using a cumulative method , Hence the effective contributions are to be calculated for individual condition types for accounts posting based on revenue/condition type. You thoughts on achieving this please.

    Thanks,
    John

  11. Hi Michael,
    Thanks so much for your detailed information. I am searching for a solution when I came across your post. Your thoughts would be greatly appreciated. Here is the issue we are trying to solve. We are creating purchase orders with Acct. Assgn. category “P” projects. Our business requirement is to deduct a discount when we pay the vendor (but not a pay terms discount). The discount is based on volume. .22% up to 300M, .33% over 300M annually. We were trying to determine if we could use PO conditions to calculate the discount amount while posting the discount to a specific GL Account and cost center. As of this time we have only been able to arrive at a statistical posting in the GR document. Any suggestions would be appreciated.
    Thanks so much,
    Kristie

    1. Hi, Kristie. What you’re describing sounds EXACTLY like what I was wrestling with on the SD side: Cumulative, tiered discounts. I’m less familiar with the MM/PP side, but I fear that you will face the same dilemma. I know that there are Purchasing Rebate Agreements which may be structured like the SD side. This should give you the capability to maintain accruals on the PO automatically. Other than that, you are probably left to designing a custom solution using a Procurement pricing condition, a custom routine, and perhaps an LIS structure to hold the cumulative quantities. Have you had any luck?

      1. Thanks so much for your feedback. We are planning to look at this process again in January when we have more data. We currently do not utilize the rebate functionality and it is unlikely we would turn this on for one vendor. At this point it does sound like we will land on a custom solution. Thanks for your time!

  12. Requirement
    Client need to create a new condition type YCXX called Qty limited Price condition for multiple sales orders and this condition type needs to be as follows:
    Example
    1. Price = $10/PC up to a maximum Qty of 1000
    2. If Sales Volume exceeds the Max Qty defined for the Qty Limited Price (YCXX), don’t apply the Qty Limited Price, put Line Item on some line item hold.
    3. An approval number need be maintained at condition records level for each YCXX condition records created for audit trail and to track condition records by approval number.
    My Proposed solution
    The client does not want a rebate option, so we are left with either the Condition update or Condition update + Exclusion grp and then ABAP Programming (though I am unsure on the config required for each, steps to doing this will be appreciated).
    Can you advise the best SAP standard solution and possibly any ABAP programing that might be needed?
    I also feel that Sales deal can work fine on this but I don’t fully know the set up required to achieve this. Does sales deal combine sales deal set-up with condition update and/or Exclusion in any way?

    I will greatly appreciate a stepwise solution that you have for this. Thanks

    1. Hi, Bola. Thanks for your comment. Here are a few comments on your points:
      1 & 2: You want to specify a price up until the maximum quantity, above which you want to put on a hold. You don’t specify if this is on a per-order quantity or across multiple orders. I’m assuming this is across multiple orders. If Rebates are out, then I would try the Sales Deal as you suggested. Sales Deals might be able to leverage the Condition Update and Exclusions; you would have to test this. You may also want to suggest Product Allocation; you can establish a Maximum quantity for a given time period. Only quantities up to the maximum will confirm on your Sales Order; anything above will not confirm and will need to be treated like a backorder. You could also try setting up a tiered price with $10 up until your maximum and then have anything ABOVE the maximum at $1,000,000 per piece. This would (hopefully) trigger a credit check which you could use for your “hold”. That’s probably a riskier solution, though.

      3: There are text fields available on the condition records which can capture your approval ID number. You can access them using the Goto –> Condition Texts. However, you will first need to assign a Text Determination Procedure to your Condition Type (YCXX in your case).

      Good luck!

  13. Hello Michael,
    Like all the other clients, this is a very helpful post. I was in search of a solution when I found your post. Everyone in this dialog has had a similar scenario, with a different twist. I was hoping to see a post similar to my requirements, but I did not. I consider all the options that you listed. I am at the point of the custom formula.

    My requirement: During sales order creation, multiple materials quantities need to be summed and applied to one material code. Currently, this is a manual step, which needs to be automated in the system. At that point I can use the graduated (tiered) pricing at that point.

    The material pricing group option sums the quantities, but each material get the same price instead of one material getting the tiered pricing.

    Any ideas would be greatly appreciated.
    Shirley

  14. Hi Michael,
    Requesting you to look at the below scenario.
    There are two services that we provide to our customer.
    1. Material A.
    2. Material A + B.
    Material 2 is nothing the same services that material A offer + something extra. The price of the second material includes some incentive as they are ordering 2 services

    Now to incentivize these services we have offered the customers the following:
    Material 1: (which can be achieved through quantity scales)
    Quantity till 100 – 10 USD
    Quantity till 200 – 5 USD
    Quantity > 300 – 2 USD.
    Material 2: (which can be also be achieved through quantity scales)
    Quantity till 100 – 10 USD
    Quantity till 200 – 5 USD
    Quantity > 300 – 2 USD.

    The trick is business need to include the quantity of material 2 ordered while scales of material 1 is calculated, but not the vice versa.

    For example if order has 2 lines:
    Line 1 – Material 1 – 200 qty – Price should be – 2 USD ((include the quantity of both material 1 and 2 – thus 400)
    Line 2 – Material 2 – 200 qty – Price should be – 5 USD (include only the quantity of 200 of material 2)

    How do we solutions this.
    Appreciate your help!

    1. Adai, thanks for your note. I think I understand your scenario. You could try to do this using a material discount on ‘Line 1’ in your example. This discount would be tiered similarly to what you describe above. The discount would also be a group condition keying off of Material Price Group, perhaps, and should only apply to the first line item. Perhaps give that a shot and see if that works. -Michael

  15. Hi Michael
    I’m trying to apply the principle that you’ve in your blog. This is a public sector client and they give 50 qty of their product for free to certain customers after that they’ll charge the customer. These customers are eligible for 50 free product per fiscal year. I’ve created a new discount condition type for 100% discount which appears in pricing procedure correctly. These are the problems I’ve faced.
    1. In the condition record VK11/VK12 I don’t see ‘maximum condition basis’ which you can specify quantity according to note 615370 this field should be in the condition but I’m missing it
    2. Then I tried to use maxim condition value and I’m not getting the desired result, regardless of the value of the order the system keeps applying the condition for 100% discount

    1. Thanks for posting, and apologies for the delay. And thank you for sharing the note. I skimmed the Note and though I cannot predict what the exact issue might be, I can perhaps recommend a course of action. The Note seems to be a ‘consulting note’ which is basically just an explanation of how SAP is intended to function; there is no need to “apply” this note to your system. I would double-check your configuration to make sure that you have enabled the ‘Condition Update’ checkbox in order for ANY options to appear in the condition record (VK11, VK12). Also, if you want to use the

      According to SAP Help (https://help.sap.com/saphelp_erp60_sp/helpdata/en/4c/8dc95360267214e10000000a174cb4/frameset.htm), the Quantity option will only be available for quantity, weight, or volume dependent conditions:

      Specifying the Maximum Quantity
      You can specify the maximum quantity when you maintain an existing condition record. The calculation type of the respective condition type must be defined as quantity, weight, or volume dependent (otherwise the necessary field will not appear in the condition record). The condition update indicator must be maintained in Customizing for Sales for the corresponding condition types.

  16. Hi Michael,
    I have a requirement as follows and would appreciate your thoughts on how best to implement it.
    Material A – Quantity 1 – 30, Fixed flat price 960 EUR
    Material A – Quantity 31 – 60, Fixed flat price 1350 EUR
    Material A – Quantity Greater than 60, Price = 19,5 EUR per EA

    Please note: The price for first two tiers above is not per EA but a flat price.
    Any advice will greatly be appreciated. Thanks much.

    1. Erin, thank you for your comment and apologies for the delayed response. This is an interesting scenario; i’ve never come across a situation where 960 EUR will buy me 1 or 30 of something. I’m going to assume that your scenario is relating to a single order on a single line item; please correct me if this is not the case. Your scenario is a mixture of two different calculation types — Quantity based (C), and Fixed Amount (B). I would try the following. Two condition types:

      Z00X is a fixed amount Price with quantity based scales. You will only need two scales — 1-30, and 31-60 with the respective prices as outlined above.

      Z00Y is a quantity based Surcharge (you can only have one active price) also with quantity based scales. You will need only one scale from 61 upwards to capture the third tier.

      How’s that sound?

  17. Hi Michael
    Greetings!

    Can you please help me with your suggestions

    Requirement: Business wants the rebate accrual should stop after it reaches a maximum monetary value. After the maximum value is reached, if further invoices are posted to sales order, the rebate pricing condition should not be pulled up in the invoice.

    I did the following.

    1) Configured graduated scale (D) in scale type in rebate pricing condition type. Scale Basis : Value . The maximum value is 4 dollars (scale value )and the accrual rate was set up as 1 dollar/1 TON. The invoiced qty is 6 Tonnes, so the accrual should stop after 4 dollars, however, it is pulling up 6 dollars.

    2) Configured “To Scale” ((B) in scale type in rebate pricing condition type. Still it pulled up 6 dollars (above example)

    3) Understanding that there is “no caps” possible for rebate pricing condition, I tried to minimise the further accrual as 1 cent/TO. So, i tried the “check” in scale configuration as ascending, descending and no check. But , in each of these cases, scale currency and unit coloumn in the scales was “grayed out”.

    Requesting for your advice.
    Regards
    Arijit

What say you?