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.
Leave a Reply