S/4 Condition Contract Management – Purchasing
As all SD and MM consultants know rebates processing in classical way of ECC in S/4 they are not available any more. The replacement for rebates from ECC has been done via Condition Contract Management. The CCM has some roots in agency business settlement that has been extended to really very powerful tool but on the other side heavy to configure.
In this article I would like to focus on purchasing side of CCM including two flows configuration, classical rebates based on invoice from Vendor and same approach but with use of accruals and delta settlement.
Configuration for condition contract management is split into four main steps:
- Condition type – two configuration steps
- Settlement process
- Settlement documents
Condition type configuration is more logistics related settings process where settlement process and settlement document configuration is place where FI knowledge is very useful. Basic configuration like condition types and pricing procedure are not described here. Nice article which can be treated as addition can be found here
I will not focus here on number of basic and quite well understandable from other areas customizing settings as a number of options to configure is tremendous.
I start with a bit upside down approach means with condition type configuration. Customizing location is Logistics – General -> Settlement Management and then respective subsection.
Condition contract type
Contract type customizing is split into two parts where first one contains more general setting like number range, fields to show/hide or next processing.
From this contract type customizing important is:
- Type of contract partner – V Supplier
- Type of Eligible Partner – this setting allows you to further limit selection of business volume
- Condition contract category – it’s a grouping of contracts parameter
- Purchasing Condition type group is the most important parameter to assign here, as it indicates which condition types can be maintained in a contract.
In my example purchase condition type group ZUR1 has been created where three condition types are going to be used. ZUC1 is a percentage condition, ZUC2 is a fix amount condition and ZUC3 is an accrual condition. Important is that condition types in the group are set as relevant for CC determination.
Second part of condition contract type configuration is more sophisticated and divided into couple of steps combined later on in setting of contract type.
Business volume determination
What I like very much about this new CCM concept is that rebate can takes into account business volume of transactions already settled in the system. In classical ECC rebates processing this was also possible but required filling in some S-table and was always error prone. In CCM, newly created contract receives a database view and when settlement process starts, it calculates quantity, value ad-hoc. View with transaction data and description of main fields are done in profile for business volume determination.
In my case I take into account business volume as a MM invoice posted into system. Additionally, I need to assign basic fields used by condition contract processing like which field correspondents to Vendor or data.
* To see detailed business volume assigned to your contract you can use tcode: WB2R_BUSVOL.
In ECC rebates processing base amount field of document used later on for calculation of rebate was determined in pricing procedure of entered document and stored in subtotal 7 – Carry over value to KOMP_BONBA (rebate basis 1). In new CCM concept, field that carry amount value is fully configurable throughout the process. As presented in below screenshot I will take a amount value from WRBTR. Target condition type ZUR3 is used in pricing procedure executed during contract settlement. Field name BUSVOL_1 is used in detailed reporting for business volume.
There is an option to assign as well other amount fields and used them later on in pricing procedure during settlement processes (subconfiguration of additional quantities on left hand side)
This option allows to decide what is the level of data aggregation in settlement document. As presented below out of condition contract only one settlement document is created (as no header level split) with multiple lines – one per item (as material is a split criteria)
As a business volume view can be used by number of contracts where data inside the view is the same and selection fields will allow to restrict the results. Here only the fields for selection are chosen but the values are assigned in instance of contract. Second use case for selection fields is the applicability to select of eligible partner, which is deeper restriction of business volume done by basic selection fields.
After creation of field selection, they must be assigned to group of selection fields.
Condition type group for Accruals
This is optional configuration step which is valid only if you use accruals and later on you need to settle them as delta with condition contract settlement.
In this case ZUC3 condition type carry the value set in instance of condition contract to condition ZUX1 which poses already settled accruals. Value is used later on during a again delta accruals settlement or final settlement in pricing procedure during CC (condition contract) settlement.
Second step of condition contract type – Settlement process
As the first part on condition contract is a bit more “technical” from process perspective the second one is way more business related with emphasis on business data maintenance and settlement.
Number of parameters split per sections is high one and rather on user friendly to set it up. Below description and brief explanation of them.
- Business Volume – assignment of previous set up business volume, group for set of field and optional eligible partners.
- Settlement – indicate how each contract type is going to be settled if supplier or customer type.
- Supplier Settlement – indicates which settlement process (more details later on) is going to be used in each scenario like regular settlement , partial settlement or delta accruals etc.
- Accruals – valid only in case if accruals scenario is in use, here to set which accruals condition group is going to be used and the status indicating validity for settlement process.
Next steps are related to settlement process and consists of creation of settlement process and settlement document type. As mentioned before this section is more finance oriented. Minimum requirement is to have at least one settlement process for which would settle the rebate process. Processed could be different depends on the complexity of process (partial settlement, accruals processing etc.) and time span (partial settlement, delta accruals etc.). I use ZM01 for regular rebate processing and ZM02 for delta of accruals.
Again, the number of options for configuration is overwhelming. Below brief explanations:
- Price determination – controls side of pricing procedure determination.
- Pricing procedure determination type – controls based on which parameters determination of pricing procedure is done.
- Check allowed settlement doc. Types – checkbox to control if only assigned in configuration table settlement document type to settlement process is allowed.
- Post business volume in accounting – controls based on what data accounting documents postings are created. Either pricing procedure posting is run (multiple lines possible) or simple two lines accounting posting Vendor/Customer with offset posted according to account key for clearing set in settlement document type.
- Settlement partner category – indicates if settlement process can be used for both sides (Vendor, Customer)
- Couple of settings regarding tax determination and if no value for tax means error.
- Settlement document type – define which settlement document type is used to settle this process
Finally, the last step of configuration (as this article is really limited to milestones of configuration without describing details like setting transfer procedure etc) which is settlement document type.
Again, this is one most complex step with the highest number of configuration possibilities so I will describe only the most important (below screenshot presents only couple of sections).
- Settlement document category – describe mainly way of processing of document (Invoice/Credit memo) in FI.
- Pricing section contains parameters to describe what kind of pricing procedure is used (in my case M – Purchasing) and Document schema group is one of parameters used in pricing procedure determination in settlement process
- Account key for clearing line – as mentioned before indicated account key for posting business volume if pricing procedure is not used.
Each settlement document type executes pricing procedure (if posting is to be settled) and below presented two different pricing procedures one for regular rebates (ZUK002) and second one of delta accruals (ZUK003). As ZUR3 is the condition that has value coming from business volume update, ZUC1/ZUC2 are conditions set in condition contract. In the accruals processing ZUX1 condition has value of already processed accruals in delta settlement then ZAC3 condition is a copy of ZUC3 condition but without accruals checkbox set in a condition type and use as a reference condition ZUC3.
If you reached this paragraph means you are really persistent. My personal opinion about the subject is that CCM is very flexible and powerful tool but to complex to configure it comparing to previous version of rebates processing. Looking forward to hear more from other logistics or finance consultants. At the end short summary of a number of setting that you have to pass through:
- Condition contract type -> Around 60 drop lists or input fields – 22 checkboxes
- Settlement process type -> Around 45 drop lists or input fields – 10 checkboxes
- Settlement document type -> Around 114 drop lists or input fields – 29 checkboxes
Thanks For the Info. I have small doubt in Condition Contract.
Can we undo Delete a Condition Contract ? If Yes, How?
You can set it to status inactive or delete technically in transaction WCOCOALL
After Deleting , can we Undo it?
Yes, you can reverse, block and release
My contract works well but I cannot use all buttons of delection, block, release, reverse, and I cannot find in where I have to enable them for transactions, could you help me please?
there are two potential reasons for that. First reason is that you cannot change from every system status to any other system status. So for example, you can only lock a condition contract if it was released before.
The other reason could be missing authorizations. The relevant authorization objects for Settlement Management can be found in this SAP Help document.
Thanks Miciej .Very informative.
Thank you for the información. Do you have the customizing to sales module (SD)?
Customizing is quite similar to MM. The difference will be only to to conditions and pricing procedure (and customizing of respective documents).
That’s a good and first step in the CCM area.
First, I would recommend to be a little more detailed in the split of criteria (only material as split can lead to error with finance, posting and reporting. E.g Cost center only assigned to 1 Ccode)
Second, do not forget the conditions for reversal (settlement, accrual, accrual settlement, rebates accrual total…)
Also, you need to have (Best practices) Rebates condition + respective accrual in the pricing procedure of the Delta accrual. Because of that you will be able to use condition exclusion in order to take the best condition(s) between rebates and accruals.
Last thing, to correct what you said, the accrual and rebates conditions are almost the same YES but beside the checkbox of accrual there are other differences (sign, group condition section)
My contract works well, but I cannot find the step to enable in wcocoall for example all the buttons to release, block, delete, prepare to archiving and reverse.
Could you please tell me what I missing in my customizing?
Thanks for this Article Maciej,
We are trying to use CCM for our client
I am able to create the condition contract and my PO is now reflecting the REA1 condition and the rebate percentage is picked from the contract created in earlier step.
I try to settle the rebate using "WB2R_SV - Supplier Contract Settlement" however system is picking the already processed PO's as well.
In other words I have created multiple contracts and multiple PO's for the same material and supplier combination. Every time I created the contract I have settled them against the respective PO's but the new settlement that I created against the latest contract is considering the business volume from the already processed PO/Settlement agreements. I am not sure where I can restrict the system from picking the other documents that are not relevant for the subjectd condition contract.
Any help/suggestions in this regard is highly appreciated.
Sorry for late answer. In configuration for business volume please include some more restrictions as this seems to be normal functionality. System is not able to find dependencies between different contracts.
Thanks for the great blog.
For new phase wise implementations, where I have global condition contracts but have some plants on SAP and some on legacy, how can we make this work? Is there a way system can consider volume data thru interface or manual entry for non-sap plant?
I assume you need to check your BVB table to find a field that can be used or if not successful extend it.
Thanks for sharing your knowledge in this blog, rally helpful.
During purchasing rebate settlement document creation process , do you know how to store SAP MIRO supplier invoice number ( RBKP-BELNR) in table WBRK/WBRP , in standard settlement management process i did not find this information anywhere in these tables.
Excellent Document to refer. Thanks for creating it.
I ma facing an issue in settlement process, wherein I have FIXED amount settlement condition in WCOCO and settlement document split at header level.
In split scenario, FIXED amount is supposed to be distributed across all settlement documents as per Business Volume.
This is not happening in my case and same fixed amount is applied in every settlement document created due to header split criteria. Kindly help to resolve this issue.