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
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.
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.
Amount field
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)
Split criteria
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)
Selection fields
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
