I have had the opportunity to steep myself in SAP S/4’s new SAP Settlement Management module. While I’m sure that I’ve barely scratched its surface, it has a demonstrated a strong capability to provide a framework for structuring complex Trade Promotions agreements. One particular scenario seemed like it was going to require some development, but I was surprised at some of the legwork SAP has already done to assist us consultants. Read on to learn more.
SAP Settlement Management Background
Like its predecessor — ECC’s Rebate Agreement functionality — Settlement Management uses a combination of a contract master and pricing conditions to determine accrual and settlement condition values. A new element called ‘Business Volume’ can be thought of as a giant filter which is used to identify Sales Document items that are relevant for each agreement. At a high level, these three pieces work quite well together, but it’s when you look at the implications of traditional SAP pricing that you find some quirks.
SAP Settlement Management Quirks
It’s not uncommon that you may have situations where multiple contracts should be accruing for a single Sales Line item. Multiple brokers may have a stake for a customer order, or perhaps multiple rebates could apply for an item. In a situation where a Condition Type has a selection of different condition tables you could run into conflicting requirements
Here is an example: you have a sales order item that is relevant for two condition contracts: 50001 and 50002. These contracts utilize the same condition type, ZTPM, which can determine different rates at the ‘Contract/Material’ or ‘Contract/Material Group’ level.
For contract 50001, Material Group ‘A’ earns a $0.50 per EA rate except for material ‘12345’ which earns a $0.75 per EA rate. Material ‘12345’ is also part of Material Group ‘A’.
Contract 50002 is slightly different. It offers a flat rate of $0.10 per EA for any item on the ‘Contract’ level only.
The access sequence for ZTPM would like something like this:
The ‘Exclusive’ indicator is set because we do not want multiple conditions to apply for the same contract. However, when we carry out pricing in this scenario, the pricing process for material ‘12345’ will apply the $0.75 rate from table 905 and stop due to the ‘Exclusive’ indicator. The $0.10 accrual for contract 50002 will not be made.
If we remove the ‘Exclusive’ indicator from the Access Sequence, then the $0.10 accrual for 50002 is made, but contract 50001 will have two accruals made — $0.75 for at the ‘Contract / Material’level, and $0.50 at the Contract / Material Group level.
With or without the ‘Exclusive’ indicator, the accruals are not posted correctly.
Solution
I began brainstorming this conflict:
Was there configuration on the Condition Contract that would influence this behavior? I checked, but couldn’t find anything.
How about on the pricing condition? No that doesn’t make sense; this is really just standard SD pricing here.
The more I thought about it, the more I decided the issue was stemming from the Access Sequence itself. The ‘Exclusive’ indicator didn’t quite meet the requirement here. But before I started getting programmers involved, I decided that this really isn’t that rare of a requirement; maybe there is a routine available on the Access Sequence that can help me?
So, I took a look and — sure enough — something caught my eye: Routine 67, named “CCS: AccrMultVal”. “CCS” stands for Condition Contract Settlement which is really what got my attention. This routine (program LV61A067) seems to do exactly what I need. Here is a comment from the code that explains more:
* used in the access sequence for accruals condition types in source documents (e.g. Billing Documents / Purchase Orders) * If the exclusive indicator is set in the access sequence, it means that if for one of the relevant contracts (from the multi values table) a condition * record is found, no further steps in the access sequence are processed. By using this method in a formula assigned in the access sequence, the conditoin access * is continued with the next step, but contracts for which condition records are found are filtered out for further access * this means that with this formula the "exclusive" flag works on condition type + contract level and not only on condition type level.
Long story short: After applying that requirement on all my Accesses, it does exactly what it says: “…the ‘exclusive’ flag works on condition type + contract level…”. The scenario that I outline above now works almost flawlessly. I’ll get to that in a minute…
How does it work?
This is almost as interesting as the scenario itself. The solution uses a variable called “CONTINUE_FOR_MVA” which appears to be newly introduced in SAP S/4HANA. When set to “X”, the system continues to search for the remaining value fields. In my example above, the ‘value fields’ contain all the condition contract numbers that are in scope. Based on my research, this function exists within SD-BF-PR (Pricing), suggesting that it is not limited to Condition Contract pricing. Here are the SAP Notes which explain this in a bit more detail:
- 2594842 – Other condition type found multiple times when multi-value attributes
- 2468210 – Access with multiple-value attributes in access sequence with exclusive indicator
Hol up… Did you say “Almost Flawless”?
Yes. Almost. In order to test the scenario, I ended up deleting some Condition Contract conditions and ran into a problem. Our current condition configuration does not permit conditions from being immediately deleted; instead, the deletion flag is set on the condition in the contract. This normally isn’t a problem, but in the case of this routine the logic is not differentiating between a deleted condition and a valid condition. The result is that a deleted condition in table 905 from my example will count toward the Contract / Condition combination and will not consider condition records from lower accesses.
Allowing for these conditions to be deleted permanently is the only workaround that we have. This is not a great solution since retaining historical pricing records may be an important (legal?) requirement. Raising a note with SAP relating to this program could eventually result in the issue being resolved. A creative ABAP programmer may also have some ideas as well. But, for the time being, things are working just fine.
It is worth mentioning that SAP Note 2468210 specifically mentions that the process should consider the Deletion Flag, so perhaps there is another note that addresses this bug.
Summary
Sometimes SAP surprises you! I’m glad that I checked the existing routines and that the “CCS” prefix was used to differentiate those intended for use with Condition Contracts. I’m also intrigued by the CONTINUE_FOR_MVA flag and am curious about how this may come in handy for other pricing scenarios. This could have been an ordeal and launched an additional RICEF object for my client, but the impact turned out to be minimal. Do you plan on using this Access Sequence Pricing Routine? Have you used the ‘CONTINUE_FOR_MVA’ flag? Let me know how in the comments. Thanks for reading.
Fantastic! I felt happy reading this article. SD Routines are not the first things that comes tom mind when working on problems like this. I remembered the first time I discovered and used a routing to apply additional restrictions in data transfer. ABAP development or debug experience comes very handy in investigation. Thanks again!
Pardon the spelling mistakes. Not sure how it happened. a)Tom = to, b)Routing = Routine.
Fanastic explanation, many thanks for your efforts
Thank you for your feedback. I hope this helps you out. I am still quite new to Settlement Management. Good luck!
Hi, may I consult your experience for historical records migration? Our client plans to go live in The coming November. They are now using E.C.C. They request to record the rebate accrual at brand level, which is one of the COPA characteristic at material level. We found it disfficult to do open in by using condition contract. Never mind the sales return after go live will impact the base fo rebate calculation. Any suggestions from you? Expect doing a manual post in FI module, what are the other Wu yon suggest to do the historical records of rebate accrual?
Thank you for the question, Clare. I think I am detecting a couple of questions here. First, you are asking about determining rebates around a material characteristic. Do you mean a value on the Characteristics tab on the material master? It sounds like you will need an enhancement in order to get this value into your Business Volume table. You are also asking about historical data. This is an interesting question. There are a couple of approaches to doing this: (a) you could develop a custom Sales Order/Billing process which you could use to make an accruals-only posting. This would need to post the accrual and update the business volume to enable settlement. Or, (b) you could just directly update the Business Volume table using a custom program along with an FI journal entry for the accruals. Method (b) is quick and dirty; method (a) is probably the cleanest. Alternatively, you could settle rebates in your legacy system PRIOR to go-live and start fresh in S/4HANA. What do you think?
Dear Michael,
Thanks for the quick input. Our client has feedback that settle rebates prior to go live are not applicable, because their channels are more powerful and signing back those rebate just because of system transition are almost impossible.
No matter which method to be used, the business need to considering the sales return as a minus on sales record and recalculate the rebate amount. With this nature of business, I will think method (b) might be more realistic, considring add-on table has the flexibity to customize many details per request.
And you are correct, the charteristic value is from material master. This is saying that business volume need to down to the level of materials. We have double checked some OSS nots and consulted other projects to think about out of box solution. Your input is valuable and thanks for sharing.
Clare
I tried doing some searching and cannot find any sort of best practice around migrating business volume for Settlement Management. I’m not sure that one exists. Please keep me posted on your progress and how it worked out. Best of luck!
Hello Michael, thanks for sharing your knowledge.
Currently I’m working with CCM to adjust the ECC solution and I have several questions that you may have any suggestion:
1) Remove tax calculation in CCM: in the sales pricing procedure (US scenario) the taxes are not calculated and in CCM it should work in the same way; Do you have any idea on how to deactivate the tax determination in settlement documents? – I’ve tried to change the settlement document 0S11 the default option for “Entry of Tax Code” to option 3 but it’s not allowed.
2) The Display Business Volume t-code WB2R_BUSVOL does not show the net rebate amount to pay to the customer, you can find that value using the same filters in the Settle Condition Contracts (customers) t-code WB2R_SC when you run it in test mode. Do you know if there is any standard way to unify this through the BV t-code, maybe changing any parameter in customizing?
3) Have you adjust ECC pricing formulas into CCM?
Thanks in advanced.
Luciana.-
Hello, Luciana. Here are some comments:
1) There are probably several ways to do this. If Tax calculation will NEVER be needed as part of your settlement process, I would just copy your settlement pricing procedure and remove any tax conditions.
2) This is standard behavior, I believe. The Business Volume table will have the inputs to the calculation (base values, quantities) but typically not the settlement amount. If you are looking for projected payout amounts and you are using accruals, then you may want to implement some sort of accrual report.
3) Regarding pricing formulas in CCM, yes, I have been involved in pricing formulas both on the accrual and settlement side of the equation. It works identically to normal SD pricing formulas (VOFM routines), so if you’re familiar with that, then you already know the CCM Settlement side.
Not sure if this helps you out. Let me know if I’m missing something.
Good luck! -Michael
Hello Michael,
Thank you so much for your reply;
For 1) your suggestion is not working but once I figure it out I will share my findings in case someone face the same scenario.
Definitively for 2) it should be done an enhancement in the std… and for 3) VOFM is good for me so if in CCM works in the same way, all settled!!!
Hope you the best, regards.
Luciana.-
Luciana, Please do let me know what you find out on the Tax issue; perhaps I’m just missing something. Best of luck to you! -Michael
Luciana, I’m wondering if you found a solution for #1 above. I have a colleague who is facing some similar challenges relating to settlements and unnecessary tax codes. Thank you!
Hello Michael
Thank you for the sharing.
I’m new to CCM and tring to reproduce your secnario but failed.
May I ask which transaction are your using for the settlement? Is that WB2R_SC?
My scenario as below.
Billing Info
Material 12345
Contract 1
RES1 Contract/Material 12345 (table 4AB) 10%
Contract 2
RES1 Contract (table 163) 5%
I assumed the WB2R_SC for Contract 2 will adopt rebate 10%, but it didn’t happen. 5% was adopted.
How could I reproduce your scenario?
Thanks you very much
Maybe I’m missing something, but I don’t see why Contract 2 would get 10% based on your statements. Can you elaborate on why you would expect that?
Thanks for the reply.
I think you had explained the scenario very clear and sorry for that I haven’t understood yet.
I’m tring to understnad why settlement for Contract 50001 needs to access the conditoin record of Contract 50002.
As my understanding
Settlement1: WB2R_SC for 50001, table 905 will be accessed.
Settlement2: WB2R_SC for 50002, table 925 will be accessed.
The total accrual amount for material 12345 = Settlement1 + Settlement2.
—————————————————-
However, when we carry out pricing in this scenario, the pricing process for material ‘12345’ will apply the $0.75 rate from table 905 and stop due to the ‘Exclusive’ indicator. The $0.10 accrual for contract 50002 will not be made.
—————————————————-
As the statement above, your scenario seems to be like settlement for 50001 and 50002 in the same time.
I just don’t know how to get this done?
Are you using some other transaction different with WB2R_SC which could deal with multipul contracts in the same time?
Hello Michael,
We have exact scenario you discussed in the post. We are using routine 67 along with Exclusion indicator on the access sequence.
Still multiple CCM contracts were determined on the Sales Order.
Below is the scenario:
CCM Contract 1:
Created with Condition Table 901: Condition Contract/Customer/Material
CCM Contract 2:
Created with condition Table 902: Condition Contract/Material.
The access sequence has routine 67 assigned and exclusion indicator checked.
Still Contract 1 and Contract 2 were determined on the Sales Order. (Ideally only CCM contract 1 should have determined and CCM Contract 2 should have been ignored)
Any Idea if I have missed anything?
Thank you!
-Sushant
Hello, Sushant. Thanks for the question. Unfortunately, I wrote this article some time ago and the topic isn’t quite fresh in my head. I tried to document the process as best as I can in the article. I don’t have any other tips for you. Perhaps someone else can contribute?