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.
What is Cumulative Graduated Pricing and Discounts?
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 for Achieving Cumulative Graduated Pricing and Discounts in SAP
There are a number of solutions that came to mind when initially thinking about this issue, but each had its own snag:
Scales
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.
Condition Update
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. 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.
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.
Final Thoughts on SAP’s Cumulative Graduated Pricing and Discounts
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.
rEALLY INFORMATIVE FOR ME …PLEASE SOME MORE WHICH WE CAN LEARN MORE
Do you have a particular question I can answer?
This is exactly what I looking for. Great article. Thanks. 🙂
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
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?
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
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
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
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
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.
The requirement is correct.
Yes, I simulated this KP00 and KP01…both just works fine.
Thanks much for the reply. Really appreciated.
-prab
I’m glad that you got your scenario working! Thanks again for joining the discussion.
Hi prab gow. Could you share how did you achieve it ? I have the same requirement but I can’t yet see how to achieve % with standard KP00. $ works fine though. when dealing with % with a copy of KP00 I think scale is the way to go for the % to be applied on a full pallet only.
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,
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
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
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
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
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
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.
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
Yvonne,
Sorry for the delayed response. Have you tried using group conditions to meet this requirement?
Michael
Hi, Michael !
Have you faced with situation, when cumulative update should be counted for specific partner role (not sold-to or pay-to) ?
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.
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.
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
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.
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.
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?
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?
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
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
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
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?
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!
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
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!
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
I think the original functionality you wanted is provided by IS-Oil pricing – scale base routine 431.
https://help.sap.com/doc/PRODUCTION/erp2005_ehp_06_hana/6.0.6VERSIONFORSAPHANA/en-US/30/9607362b89e30ae10000009b38f839/frameset.htm
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!
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
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
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:
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.
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?
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
Hello Michael,
Thanks for great information. I have a question is there a way to set minimum order in a graduated scale?
Hello. Thanks for visiting. Can you please use an example of what you mean by “minimum order in a graduated scale”?
Hi Michael,
Please help me how to input this in ME11, Create Gross Price condition
Qty 1-9 $67.50
Qty 10-99 $54.00
Qty 100-499 $36.00
Thanks
Necay, thanks for posting. I’m not intimately familiar with the procurement pricing transactions. I typically maintain the Purchasing Info Record and maintain the conditions there. There should be a “Conditions” button on the top. Usually, you can double click the condition field to jump into the scales. If you cannot, I would double check that scales are allowed on the pricing condition type. Good luck!
Hi Michael,
Appreciate your analysis here, excellent work. Our requirement sounds similar to Hannah’s
from October 30, 2015 at 7:40 pm
Tier’d Pricing Requirement (cumulative throughout contract lifetime)
Gap: When order quantity goes over the threshold max hours of a tier,- next tier pricing is not automatically picked and applied to the over-and-above quantity.
For example two rates:
Tier-1: $100 for the first 100 hours and
Tier-2: $200 for the next 200 hours
Say first DMR of 90 hours is correctly priced at
90 x $100 = $9,000
Suppose the next DMR is supposed to bill for 11 hours — one more than the leftover threshold left on Tier-1.
2nd DMR is priced:
10 x $100 = $1,000
and 1 x $200 = $200
as that extra quantity of 1 went over the threshold of Tier-1 and Tier-2 is inactive because Tier-1 already exist on line item.
We got pretty close,- with a remaining issue that the pricing of the overage of one Tier to the next within one DMR billing document does not seem to be in standard. As per your excellent analysis.
Rebates is not for us.
At this point I am considering a user exit that creates a second line item (as an exact copy of the first), calculating the qty as the overage quantity between the billing quantity and the base qty from line item one. Combining with a formula to determine the second tier price. One of the issues it seems is that the cumulative info structure S071 is not updated in memory by the first line item, therefore the pricing of the second artificial line item doesn’t kick in properly. Your thoughts are highly appreciated.
Hi Michael, I have a requirement to have Scales for cumulative values of a condition type.
Ex. If the customer buys 300 MT in the month of July 2020
1 to 50 MT -> 1 USD / MT
51 to 200 MT -> 2 USD / MT
201 to 300 MT -> 3 USD / MT
Customer will be eligible
50 X 1 = 50 USD
150 x 2 = 300 USD
100 x 3 = 300 USD
Total Rebate for the month of July 2020 -> 650 USD
as our normal scales will work for individual sales orders.. but i want to apply above said scale for the whole cumulative quantity in a given period of time.
Thanks in advance
Hello, Dhanasekar. Thanks for the question. Perhaps I am misunderstanding your question or your example, but I think this is the topic that I cover in this article. Have you considered the suggestions I wrote about?
Thanks for your reply. Topic which you covered , Discount its calculating in the Sales order level . I want to calculate the rebate at the month end , to cumulative billing quantity against the each customer.
Hello. As my article states, the only way that I found to meet this requirement in standard SAP is to implement a Rebate Agreement in SAP ECC. If you are looking to avoid the Rebate Process, then you’re probably looking at some custom pricing solution. I’m not sure if this helps you.
Hi Michael,
I wanted to give you an update how we solved the tier’d pricing at our customer. I thought you might find this interesting.
Initially we attempted to solve our Tier Pricing requirement in SD order user exits. We identified a couple exits, that are applicable, with real good promising results. However, …not all use cases could be achieved via teh U.E. specifically we had issues, like
– fields not being available for updates
– when updating the field, we’d get another item copy
– outcome of logic in one U.E. needed to update fields in another U.E., did not want to mess with global variables 🙂
– creating a second item for the new tier became really hard, the new item would not save properly
With that…after weeks of analysis, debugging and troubleshooting we decided to implement tier’d pricing in our front-end workbench, the BWB. With the immediate benefit, that we control all items being created in a DMR billing document, with just one or several tiers being created.
Also, the user gets to see on the UI the tier’d pricing proposal and can make manual changes as needed.
We are quite happy with the result and so is the business. It is one of harder requirements I have come across. Again, kudos for your interesting site and good conversations here.
Cheers
Soren
Hi Michael
Requirement :- customer got a list of material to select – discount will given on number of items he select from the list
Example; 50 Materials
In as sales order
1) select 30 material for an order will get 15 % discount .
2) select 10 materials for an order get 5% discount.
wanted to know if there is an option of discount condition per order with number of line items .
Hi Ravi, thanks for the question. From what I gather, you’ll want to explore a percentage based discount condition with quantity based scales. If these materials are different material numbers, you’ll need to make sure you enable group condition functionality so that the scales will see the desired volumes. Group conditions will need some sort of grouping criteria, so you may need to decide between a few options. Good luck!
Hi Michael, Thank you so much for the detailed process. This is exactly what Im looking for. I used the Condition Update approach. So just with Cond. base value, I was able to have the Customer-Material combination work until certain qty. But I’m facing challenge at the Credit memo level. The cumulative values are not being considered, and Credit is being processed for more Qty than what is billed for customer. Any suggestions please?
Thanks for the comment. And that is an interesting question. I’m wondering whether you can see the Credit Request documents when you view the documents through the condition record as mentioned in this help article: https://help.sap.com/viewer/04ed152d92884a6da49c778a13aecb21/6.18.06/en-US/498dc95360267214e10000000a174cb4.html
Yes, the Credit Memo request document is also updated on the Extras>Cumulative values- Sales Orders list.
If the Qty haven’t reached the Condition base value, its working good. But once the Cumulative value reach the Max.cond.base value, then the Credit memo req. is not behaving correctly to the Qty that we should credit.
Also, Im noticing that the S001 structure is not updating for all the Orders (sales Order qty, Billed Qty, Credit qty). I only see1 of the 3 orders created. Why will a standard S001 structure got impacted
Ok. You might want to check whether the Statistics Update Group is set for the other document types. I believe that you will want to see all relative documents in the SIS table to confirm that they are being taken into consideration.
S001 structure is now being updated as soon as I assign the Statistics group on Item category. (OVRI tcode). But still the price (Surcharge Price with Max.Cond.base. Quantity value) at the Credit Memo request level is not reflecting as per the reference Billing Document Qty and Cumulative values.
The Max.Cond. Base value that is set on the Condition record of the Pricing condition Type is NOT being considered for Returns , Credit Memos.
And so the Qty mentioned on Return Order , Credit Memo request are blindly considered irrespective of what actual cumulative value is / for what Qty on the referencing Document is the Additional Price collected from customer. So ending up crediting more 🙁
I’m not sure what the solution is. Here is an article which mentions issues with S001:
https://answers.sap.com/questions/9362728/s001—negative-qty-and-value-updation.html
Hi Michael,
Interesting topic. I have somewhat related discussion. We work with 2 channels, one is a shop, one is online. We use 1 SD model with a channel to separate specific conditions.
In the shop we give a discount for several material, if you buy a minimum amount, say buy 6 get 10% off. The scale will work fine here.
Online however, you only want the same condition to apply on the multiples of 6 since these are boxes that you do not want to separate in individual EA’s. You could force the customer to order in multiples only, so there is no way to order eg 7 pieces.
But sometimes we have customers that get a discount if they purchase a complete pallet, but 1 single box is also fine. The multiple/minimum order quantity does not work then, because when ordering a pallet + 1 EA will give the discount for the pallet also on the 1 EA.
Do you have an idea on that one?
regards,
Patrick
Hi, Patrick. Thanks for commenting. Interesting scenario. I can’t say that I follow the requirements completely, but you may want to investigate using two separate Distribution Channels to represent your two models — shop, and online. This gives you the ability to specify different material sales attributes for each channel. You could then use rounding rules to enforce ordering quantities. For the discount, you would probably need some sort of scale active on the material to give a discount on multiples that equate to a pallet. That’s the direction I would look first.
Hi Michael,
Thanks for sharing the great stuff!
I have an query , We need to create the no. of condition type based on No. of Slabs.
For example we have a 6 slabs in the requirement ,so we need to create 6 condition types.
Kindly advise .Thanks.
Regards,
Kanagaraj K
Thanks for commenting. I’m afraid I need some more information: are the slabs what the customer is buying? Why do you need six different conditions in your example?
Hi Michael,
Thanks for the reply .
Actually my requirement is similar to yours , But here we have 5 slabs as below,
slab-1 : 0-200 qty – 23 OMR
Slab-2 : 201- 25000 qty – 18 OMR
Salb-3 : 25001-50000 qty – 17.75 OMR
Slab-4 : 50001-100000 qty – 17.50 OMR
Slab-5:100001-125000 qty – 17.25 OMR
In their business process order contains only one line item also single delivery and billing ..No partial delivery and billing .
Aparat from contracts or agreement process , is there any other way to achieve this .
I’m still not sure I understand what a “slab” is. Does the pricing tier you describe apply to One order? Multiple orders? This sounds like either a Group tiered pricing discount (single order) or a Rebate agreement.
Hi Michael,
Yes , it is just a Pricing tier .
Possibilities to have Sales price based on a quantity slab (pricing tier) for the particular customer within a period (1 year)
As per the above pricing structure..
Sale order Customer Quantity Tier price calculation Cumulative Qty
Sale Order-1 40449 100 1 23*100 100
Sale order-2 40449 125 1 & 2 23*100 + 18*25 225
Sale order-3 40449 2000 2 18*2000 2225
Sale order-5 40449 23000 2 & 3 18*22775 + 17.750*225 25225
Ok. I think I was confused on the terminology. This is a very similar requirement to what I was trying to get to in my article. Unfortunately, my article sums up the solutions that I was able to explore. I think a custom solution would probably end up being the best route.
Have you find any solution for your requirement . Because I just looking for the possibilities achieve this requirement . Custom solution means ,only way to achieve this on VOFM right. Thank you so much for your response.
you posts always pushes the analytical thinking abilities.Much appreciated
Thank you, vikraena. I’m always happy to receive this type of feedback.
Hi Michael,
I have the below requirement to achieve in Rebate processing
slab-1 : 0-200 qty – 23 OMR
Slab-2 : 201- 25000 qty – 18 OMR
Salb-3 : 25001-50000 qty – 17.75 OMR
Slab-4 : 50001-100000 qty – 17.50 OMR
Slab-5:100001-125000 qty – 17.25 OMR
I have created Rebate agreement with above scales ..I tried to create the sale order like as below,
SO-1 : 100
SO-2 : 150
As per the customer requirement ,it should calculate
1. 100 * 23 = 2300 OMR
2.100*23 + 50*18 = 2300 + 900 = 3200 OMR
but when I have checked the rebate analysis , it shows 250 * 18 = 4500 OMR
cumulatively calculate the total qty * present Pricing tier
Kindly advise.
On the condition type, try using the ‘graduated to’ scale option. That should behave the way you expect.
I have made the changes as per your input but still its calculating as same as I mentioned above .
We need to do settlement and then have to check .
Hi Michael,
I have made the changes as per your comments .but still getting same results as mentioned earlier . Please advise .
Try creating new condition records and new Sales Documents. Use your SD troubleshooting skills. You’ll figure it out. Good luck!
Hi Michael,
Thank you so much! It is working fine .I thought of respond you on yesterday itself ,but I missed out .Thanks alot.
Awesome! Nice work! Hopefully, that will meet your requirements.
Hi Michael,
Can you please elaborate your potential solution mentioned here…
“Rebate Agreements
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.
I have a requirement as mentioned below and do you think solution explained in your article works ?
Eg :
If customer meet the 1st 1000 ordered quantity, get X amount of rebate (1st tier).
If customer meets the quantity from 1001 – 2000, get Y amount of rebate. (2nd tier).
If customer meet the quantity from 2001 – 3000, Z amount of rebate (3rd tier).
Up to 3 tiers. Quantity to meet does not have time limit. Can be in multiple sales orders.
Appreciate your response and any inputs.
In your scenario, the customer would get X+Y+Z? If so, you would be looking for a graduated scale rebate, and I’m not sure if that is supported by standard CCM. You may need to test that. If not, you could try to break this up using separate condition records, or condition types of THAT doesn’t work.
Hi Michael,
This was really helpful!
My requirement is to restrict the offered discounts to a fixed material qty. and this qty. may be distributed among different orders. The client is to use the sales deal/promotions functionality and not the rebates.
For fixed discounts offered per unit, I could achieve it by using the Graduated sales and condition Update functionality by setting the Max.Cond.base value in the additional tab.
However, I’m unable to define any such value in case of percentage discounts.
Any suggestions to achieve this?
Thanks for the question. I’ve written a couple of articles relating to the ‘Condition Update’ functions. While there are several use cases which are met using these functions, you’re seeing that there are some limitations. I think some custom routines in conjunction with the S-table could be used in a custom pricing solution. That may be the best solution.
Thanks Michael. Would reach out to the ABAP resource and try out some custom routine.
Can you suggest what tables can be referred to fetch sales deal (VB21) specific data as the standard tables A144 & A145 are not populated with any data in my case.
Has there been any replacement for these in S/4 HANA model or is it some configuration I might be missing?
I don’t actually have a ton of experience with Sales Deals. Those types of functions may use a standard condition table (A145, for example), but may use another table (A900, maybe). The condition details will be in a separate table with the condition detail.
Hi Michael, thanks for the explanation.
I used the scenario 2, adding a maximum value for a discount on a service contract. Maybe good to point out that the maximum allowed amount should be maintained with a minus sign in order to have a maximum allowed discount amount to be working, so the value should be ‘-1000’.
I struggled a bit to get it working, but with a bit of debug it became clear where the issue came from.
Thank you, Bouwina, for sharing that tip!