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
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.
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
