As we move from the world of ERP Business suit to the world of S/4 HANA, there are many things which are changing in various modules like FI, SD, PP, Output management etc. and the question always arises how is my business going to be impacted, what is the way forward and am I getting into a totally unknown territory? The first thing which anybody would do is to search for topics on SCN blogs, Google, JAM pages which actually a good starting point. However sometimes ( or most of the times ) one finds it a bit difficult to run a hands-on end to end scenario for the new features which is going to be part of S/4 HANA. I faced similar problems while trying to understand “Condition Contract Management” within Settlements Management which is the replacement for traditional “Rebates Management” and hence I thought it would be nice to share my experiences.
The blog will cover the following topics
- Traditional Rebate Processing
- Comparison : Old Vs New
- General Process
- Step to create condition contract
- Sales Flow
- Actual Settlement
- Credit Memo Display
- Business Volume Display
- Important Transactions
- Useful Tips & Links
Knowledge of SD Rebate Processing ( to be able to understand the advantages of the new solution )
Moving into S/4 1610, New Rebate Agreements are no longer available for creation. Yes, you heard it right! You can’t create a new Rebate Agreement neither can you extend existing ones. Subsequent logical question which any sane person would ask now is “How do I provide rebates to my customers then?”
The answer is via Settlements Management.
Next logical question which would be asked is “Alright, but why Rebates Management has been done away with in S/4?”
The answer lies in the difference between the architectures of S/4HANA and traditional ERP business suite. So, before we move into Settlements Management, let’s touch upon how the traditional Rebate processing works to be able to appreciate the advantage Settlements Management offers.
Traditional Rebate Processing
As a reference from help.sap.com
A rebate is a special discount which is paid retroactively to a customer. This discount is based on the customer’s sales volume over a specified time period. You define the details of the rebate in a rebate agreement. In the agreement you specify, for example
- who receives the rebate payment
- on what criteria the rebate is based (customer, customer and material, and so on).how long the rebate agreement is valid
- Within the rebate agreement you create separate condition records for each product the customer buys. These records specify the rebate amount or percentage for each product. You can also specify a pricing scale so that the customer can earn a better rebate by ordering more. Because rebates are always paid retroactively, the system keeps track of all billing documents (invoices, credit and debit memos) that are relevant for rebate processing. The system can, if you wish, automatically post accruals so that the accumulated value of a rebate is recorded for accounting purposes.
- A rebate agreement is finally settled when you issue a credit memo to the customer for the accumulated rebate total.
Comparison : Old Vs New
Let’s focus on the line in bold in the above section.
Question. How does the system keep track of the invoices which relevant for rebate processing?
Answer. Table VBOX stores all rebate relevant invoices. The customer runs transaction VBOF to apply the rebate conditions in the invoices.
- Size: This Rebate index table could contain hundreds of thousands to millions to billions of entries in the system In fact for one of the customers we noticed 1 TB of data being occupied in total DB size of 5 TB. It won’t not take long for our BASIS, DB & ABAP colleagues to understand the repercussions of such a situation.
- Locks: If changes in one customers’ conditions occur the table needs to rebuild; while this rebuild is going on, all rebate data is locked throughout the organization
The solution to these issues lie in the Settlements Management
- The table VBOX itself has been done away with in S/4 HANA because the rebate conditions are applied instantly due to power of HANA. Hence Rebate Index need not be rebuild when new customers become eligible for rebates and previous business can be retroactively considered.
- This significantly reduces data footprint and memory.
- Sales document no longer reduce operations impairment in sales processes
Have a look at a side by side architecture of Rebate Management in Traditional ERP Vs Settlements Management in S/4.
The general process in the CCM differs from the standard Rebate processing in the sense that there are no rebate Agreements at the first step. There are Condition contracts which need to be created and released. The steps for the same are explained in Step 8.
Steps to create Condition Contract
- Execute transaction WCOCO ( W ko-ko ) and click on ‘Create’.
2. Select the type of contract you would want to create
- Enter the customer and period for which you want to create the condition contract.
- Enter the Sales data on the 2nd tab
- Enter the business volume selection criteria. This steps defines which invoices are relevant for application of this condition contract.
- Enter the settlement Material
- Enter the Settlement Calendar. This step defines when you would like to carry out partial/final settlements.
- Create Rebate Accrual condition
- Change condition Table
- Create Rebate condition
- Save the Condition Contract
- One thing is of utmost import is to release the contract. Hence release the contract in WCOCO
- Once done the light will become ‘Green’. Save it.
I won’t be explaining how to create a Sales document, Delivery, PGI, Invoice etc but what needs to be mentioned is that either these documents can be created before the condition contract creation or after the condition contract creation. In case Sales document is created after the contract creation, REBA accrual condition would be available in the conditions tab.
Don’t worry about the 7 % as opposed to 10 % I created earlier as this is from a different example.
In case the Sales document is already created before the contract creation, the rebate would be provided as part of the settlement process and rebate condition would be visible in Credit memo which will book the correct accrual amount to the respective accounts. So there is no need to adopt the Sales order anymore.
Run transaction WB2R_SC and enter relevant values. Please note that Run Type ‘Check Run’ does not post any data. For actual settlement use ‘Live Run’.
Once executed, you will get a message like shown below
In WCOCO, you can see a credit memo created with relavent values
In the Header conditions, you will find the Rebate condition we had created as part of the condition contract.
Run transaction WB2R_BUSVOL,
As you can see below, business volume 1.5 is updated against the condition contract
There is a whole list of important transactions for the new Settlement management solution.
Useful tips and Links
- Condition contract settlement is also available in the SAP Business Suite. Therefore you use condition contract settlement if you are planning to create new rebate agreements before you upgrade to SAP S/4 HANA.
- SAP Business Suite customers can move from various releases to SAP S/4 HANA, on-premise edition and still process the existing rebate agreements. It is not possible to create or extend the existing type rebate agreements.
- Help SAP – Condition Contract LINK
- Help SAP – Condition Contract Based Settlement LINK
- S/4HANA OP1610 simplification list LINK
- Settlements management is also available on FIORI apart from SAP GUI.