Condition Contract Management

• Sales
• Purchasing

Introduction to Condition Contract Management.

Sales 

The sales rebate processing capabilities of Settlement Management support you in providing rebate incentives to customers and paying rebates on schedule. You can define, monitor, and modify sales rebate agreements flexibly based on customer, product, and volume-based sales commitments.  

Concepts

When you create a new condition contract, you specify the condition contract type.

• To which business partner the agreement belongs, for example, a customer or a supplier.
• How the business volume is determined.
• How settlement documents are created.
• Which rebate and accruals conditions you can specify.

Process flow 

Creating Sales Rebate Agreements

To define sales rebate agreements, you create customer condition contracts. You can create condition contracts without any reference to a document or as the successor of an existing condition contract.

Monitoring Sales Rebate Agreements

To monitor the life cycle of sales rebate agreements and the development of their business volumes, you can search for and display customer condition contracts, display an overview of condition contracts and their conditions, and display an overview of the business volume for condition contracts and for the settlement documents created in the settlement process.

The release of condition contracts is an important milestone because condition contracts are then available for operational use in end-to-end sales business processes. You can also configure workflows that handle the approval process for the release of condition contracts.

Posting Accruals for Sales Rebates

Accruals can be created when you post transactional documents, such as goods receipts or billing documents, or you can post accruals in an accumulated form during delta accruals settlement. During this settlement run, the system creates dedicated settlement documents to post the accruals based on the relevant business volume.

Settling Sales Rebates

To settle sales rebates, settlement documents are generated for customer condition contracts to create the corresponding amounts receivable and payable in accounting for the relevant customers. You can perform partial settlements, final settlements, delta settlements, and delta accruals settlements. For more information about the different types of settlement, see Settlement Date Types.

If you identify any problems with the settlement document created for the condition contracts or with the settlement run, you can cancel settlement documents, for example, by using the Reverse Settlement Documents - Condition Contracts app, and repeat the settlement run in one processing step.

Reviewing Sales Rebate Settlements

To review sales rebate settlements, you can display a list of settlement documents for condition contracts by using the Display Settlement Documents - Condition Contracts app.

You can view an itemization of the business volume for settlement documents in the form of detailed statements. For more information, see Detailed Statements.

Configuration 

 
These are the scenarios and their corresponding condition contract types: 

• Basic scenario with a condition contract for one customer (0S01) 
• Condition contract for multiple customers (0S02) 
• Condition contract for one customer with a two-step settlement (0S03) 
• Condition contract for multiple customers with a two-step settlement (0S04) 
• Condition contract for one customer with goods-related rebate taxation (0SG1) 
• Condition contract for multiple customer and goods-related rebate taxation (0SG2) 
• Condition contract for one customer, goods-related taxation, 2Step settlement (0SG3) 
• Condition contract for multiple customer, goods-related taxation, 2Step settlement (0SG4

Pricing

• RES1 Rebate: use this condition type in a condition contract to maintain rebate conditions in the non-TPM salesrebate scenarios
• REA1 Rebate Accruals:  use this condition type in a condition contract to maintain accruals conditions in the non-TPM sales rebate scenarios.
• REJ1 Rebate Adjustment: use this condition types in a condition contract to maintain a correction for the rebate amount
• REBV Rebate BusVol Delta: You use this condition type in a settlement run for the business volume, use this condition type in a settlement run for the business volume,  Fixed Amount – is determined by the settlement program
• RES2: Use this condition type in a settlement run for the total amount of previous partial settlements
• REA2: Use this condition type in a settlement run for the amount of the accruals reversal
• REA5: Use this condition type in a settlement run for the amount of the accruals index update
• RED1 Rebate Accruals: use this condition type in a settlement run to determine the accruals amount for delta accruals
• RED2 Rebate Accr Total: use this condition type in a delta accruals settlement run for the total amount of already reversed accruals.
• RETX Rebate Tax: In scenarios in which you regard sales rebate agreements as a kind of service, you use this condition type in a settlement run for the tax condition.
• RETT Rebate Tax Trigger: In scenarios with goods-related taxation of the rebate amount, you use this condition type in a settlement run for the tax condition
• RETI Rebate Tax Inbound: In scenarios with A/P settlement of the rebate amount, you use this condition type in a settlement run for the tax condition
• RENT Rebate Net Amount: use this condition type for the business volume in manually created settlement documents
• MWAS Output Tax: use this condition type to adopt the result of the tax determination triggered by RETT
• MWVS Input Tax: use this condition type to adopt the result of the tax determination triggered by RETT

Pricing schema

A10005

• 100 REBV Rebate Business Vol.: Contains the business volume amount that the system transfers to the pricing procedure in the settlement run.Statistical.
• 105 REBD Rebate BusVol Delta in the condition contract to adjust the business volume amount.
• 200 RES1 Rebate: The condition basis for the rebate amount calculation is line 100 and line 105; using account key 0S1
• 204: REJ1 Rebate Adjustment: To adjust the rebate amount calculated with condition type RES1
• 205 REV1 Rebate Verified in the condition contract. You use this condition type to invalidate the previous rebate calculation
• 300: RES2 Rebate PartSettl Rev: Contains the total amount of previous partial settlements. The system determines this amount in the settlement run and transfers it to the pricing procedure.
• 399, Net Amount Contains the net rebate amount which is the actual calculated rebate amount minus the amount of previously settled rebates.
• 400, tax condition type RETX Rebate Tax
• 410, tax condition type RETI Rebate Tax Inbound According to requirement 66 LO-AB: Tax det Suppl, this condition type is valid only for an A/P settlement
• 499, Gross Amount Contains the gross amount as sum of net amount and tax amount
• 800, condition type REA2 Rebate Accruals Rev Contains the amount of the accruals reversal. The system determines this amount in the settlement run and transfers it to the pricing procedure
• 850, condition type REA5 Rebate Accruals Rev Contains the amount of the excessive accruals amount that shall be written back to accruals index table WCOCOF.
•  900, Effective Value Contains the effective value which in fact equals the gross amount. The calculated amount is stored in subtotal S (KOMP-EFFWR).

The condition exclusion procedure 1 for the three pricing procedures A10005/6/7/6 controls that condition types RES1, RES3, and REJ1 are excluded when a condition record for REV1 has been defined in the condition contract.

 

Additional

2708348 - Structure of IDoc segments in Settlement Management

You are using IDocs with IDoc type INVOIC02 for the creation/generation of Settlement Management (Agency Business) documents. The IDoc segments are on the same level and you are looking for an enhancement point. You can change the structure of the standard segment by using the BAdI implementation WLF_INVOICE01_REGU to introduce levels creating a hierarchy if desired.

Partner determination in Settlement Management

SPRO: Logistics - General -> Settlement Management -> Basic Settings -> Specify Settings for Partner Determination -> Partner Determination on Header level

In Settlement Management, similarly as in SD, an automatic partner determination is only carried out on header level.

The logic of partner determination in the Settlement Management area depends on-field „Partner Determination from Master Data” (TMFK-DET_PARTNER) in the settlement document type customizing, under the following path:

SPRO: Logistics - General -> Settlement Management -> Settlement Documents -> Settlement Document Types -> All Document Types

TMFK-DET_PARTNER can have the following values:

• (initial) – „Are Not Determined from Master Data”
• 1 – Are Determined from Master Data

A.payment recipient/ AZ/ LNRZB

Sales

1. based on the bill-to-party (KOMLFK-KUNRE) the program checks the customer account group (TKUPA-KTOKD), which was maintained in the customer master (KNA1-KTOKD).
2. then based on the customer account group, the system checks the partner determination procedure (TKUPA-PARGR)
3. finally, the relevant partner functions are read from the determined partner determination procedure which was assigned to the customer master group (TPAER-PARGR)

Purchasing

1. based on the invoicing party (KOMLFK-LIFRE) the program checks the supplier account group (T077K-KTOKK), which was maintained in the supplier master (LFA1-KTOKK)
2. then based on supplier account group, the system checks the partner determination procedure (T077K-PARGE), which was maintained in the relevant supplier account group
3. finally, the relevant partner functions are read from the determined partner determination procedure (TPAER-PARGR)

Partner determination takes place in Method SET_DOC_PARTNER of CL_WLF_ADDITIONAL_PARTNER

If you wish to change some data for the partners which were determined by the system (the content of KOMWBPA structure), you may consider to implement your own logic using WLF_PARTNER_ENHANCE (Method: PARTNER_COMPLETE).