Settlements Management

CCM - Description of delivered configuration

Sales Rebate Processing

Sales Rebate Processing is a specific scenario within the Condition Contract Management (CCM) application.

These are the scenarios and their corresponding condition contract types:

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)
Condition contract for TPM integration, one customers (0ST1)
Condition contract for TPM integration, multiple customers (0ST2)
Condition contract for TPM integration with claims, one customers (0ST3)
Condition contract for TPM integration with claims, multiple customers (0ST4)

Configuration

Configure Pricing including Condition Contract Conditions

#Configure settings for pricing used in settlement documents as part of condition contract settlement

Pricing table ( examples: 4AB, 163, 4AM...)
Access sequence
Condition types

AS01 Tax Trigger: You use this condition type as trigger for the tax determination in manually created settlement documents

Tax conditions are not determined via pricing; they are taken from the corresponding tax code determination in FI directly.

MWAS Output Tax: You use this condition type to adopt the result of the tax determination triggered by RETT or AS01
MWVS Input Tax: You use this condition type to adopt the result of the tax determination triggered by RETT or AS01
REA1 Rebate Accruals
REA2 Rebate Accruals Rev
REA3 Rebate TPM Accruals
REA4 TPM Accruals Rev
REA5 Rebate AccrualsSettl
REAT Rebate TotalAccruals: You use this condition type for the posted accruals in manually created settlement documents, see pricing procedure A10008
REBD Rebate BusVol Delta
REBV Rebate Business Vol.
RED1 Rebate Accruals
RED2 Rebate Accr Total
RED3 Rebate TPM Accruals
RED4 TPM Accr Total
REJ1 Rebate Adjustment
RENT Rebate Net Amount: You use this condition type for the business volume in manually created settlement documents
RES1 Rebate
RES2 Rebate PartSettl Rev
RES3 Rebate TPM
RES4 TPM PartSettl Rev
RETI Rebate Tax Inbound
RETT Rebate Tax Trigger
RETX Rebate Tax
REU1 Rebate Unlikelihood: You use this condition types in a condition contract to handle the unlikelihood for a rebate payment.
REV1 Rebate Verified

Specify CC-Relevance for Condition Types

The Relevant for Condition Contract Determination in Pricing indicator controls that a condition type is relevant for the determination of applicable condition contracts during pricing for a document.
Check the Relevant for Condition Contract Determination in Pricing indicator and the Usage parameter for the following condition types
Settlement Management ® ConditionContract Management ® Condition ContractConditions ® Sales ® Specify CC-Relevance and Copy Controlfor Condition Types

Define Condition Type Groups
Assign Condition Types to Condition Type Groups
Define Account Keys

Logistics - General ® Settlement Management ® Basic Settings® Revenue Account Determination (SD) ® Define And AssignAccount Keys ® Define Account Key
The account key 0S1 Rebate Sales is used in the pricing procedures to control the account determination for rebate and accrual condition types.

Define Pricing Procedures

Pricing procedures A10005 Rebate (Germany), A10006 Rebate Delta Accrual(Germany), A10007 Rebate (Goods Rel.) (Germany), and A10008 Rebates Manual (Germany)
Step 100, condition type REBV Rebate Business Vol.

Contains the business volume amount that the system transfers to the pricing procedure in the settlement run. Accordingly, the Manual indicator is selected for this condition. In addition, the Statistics indicator is selected as the business volume amount shall not be considered for the net amount. The business volume amount is stored in subtotal 7. The print ID is A Total: General

Step 105, condition type REBD Rebate BusVol Delta

In this step, the system determines the condition record with a fixed amount that you have maintained for condition type REBD Rebate BusVol Delta in the condition contract to adjust the business volume amount. The condition record is determined with access sequence RE01.
Therefore the Manual indicator is not selected.

Step 200, condition type RES1 Rebate: The condition basis for the rebate amount calculation is line 100 and line 105 (see From Step and To Step column). Base formula 214 in column Alt.Cond.Base Value controls that in case of a fix amount rebate condition the condition base value is positive (see formula documentation).

The account for the FI posting is determined using account key 0S1 (see column Account Key).
The calculated value is stored in subtotal 1. The print ID is A Total: General

Step 204, condition type REJ1 Rebate Adjustment

In this step, the system determines the condition record with a fixed amount that you have maintained for condition type REJ1 Rebate Adjustment in the condition contract. You use this condition type to adjust the rebate amount calculated with condition type RES1 in line 200.

Step 205, condition type REV1 Rebate Verified

In this step, the system determines the condition record with a fixed amount that you have maintained for condition type REV1 Rebate Verified in the condition contract. You use this condition type to invalidates the previous rebate calculation. This invalidation is based on an exclusion rule

Step 210, condition type RES3 Rebate:

Similar to step 200, now for TPM-related scenarios.

Step 300, condition type 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. Accordingly, the Manual indicator is selected for this condition. The total amount of previous partial settlements is stored in subtotal 3. The print ID is A Total: General

Step 310, condition type RES4 Rebate:

Similar to step 300, now for TPM-related scenarios.

Step 399, Net Amount

Contains the net rebate amount which is the actual calculated rebate amount minus the amount of previously settled rebates. The print ID is A Total: General

Step 400, tax condition type RETX Rebate Tax

According to requirement 76 LO-AB: Tax det Cust, this condition type is valid only for an A/R settlement (the Price Determination parameter in the relevant settlement process type is Customer Side). The tax value is determined using the corresponding access sequence. The condition basis is the net amount of the previous line. The print ID is A Total: General.

Step 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 (the Price Determination parameter in the relevant settlement process type is Supplier Side, see chapter Define Settlement Process Types). The tax value is determined using the corresponding access sequence. The condition basis is the net amount of the previous line. The print ID is A Total: General.

Step 499, Gross Amount

Contains the gross amount as sum of net amount and tax amount. The calculated gross amount is stored in subtotal 9 which copies the value to KOMP-BRTWR (gross value). Print ID is A Total: General

Step 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. Accordingly, the Manual indicator is selected for this condition. In addition, the Statistics indicator is selected as the amount of the accruals reversal is not relevant for the total net amount. Account key 0S1 (see column Accruals) is used to determine the accruals account for the FI posting. The calculated value of the line is stored in subtotal 2.

Step 810, condition type REA4 TPM Accruals Rev

Similar to step 800, now for TPM-related scenarios.

Step 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. The amount is calculated by condition value formula 91 CCS: Accr. in Settl, entered in column Alt.Calculation Type, as the difference between the absolute value of subtotal 2 and the net value.

Step 900, Effective Value

Contains the effective value which in fact equals the gross amount. The calculated amount is stored in subtotal S (KOMP-EFFWR).

Condition Exclusion For Groups Of Conditions

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.
Similarly, the condition exclusion procedure 2 for pricing procedure A10006 controls that condition types RED1 and RED3 are excluded when a condition record for REV1 has been defined in the condition contract.

Define Document Schema Groups for Settlement Document Types

You assign the document schema groups to settlement document types

Pricing Procedure Determination
Specify General Settings

The setting for the Accruals Total in Manual Settlement parameter identifies the condition type containing the posted accruals as basis for the automatic distribution of a manually entered settlement amount

#Configure specific settings for condition contract conditions

Define Number Ranges
Define Condition Contract Categories: You assign condition contract categories to condition contract types
Define and Configure Field Status Groups for Header Fields
Define Text Determination Procedures
Define Check Groups
Specify Settings for Transfer Manager

#Configure Condition Contract Maintenance

#Configure Condition Contract Settlement

Purchasing Rebate Processing

Purchasing Rebates with Business Volume from Sales

Royalties Settlement

Sales Commission for External Sales Agent

Condition Contract Management by Settlement Management in SAP S/4HANA

Plant determination logic in Settlement Management/Agency Business

In Settlement Management / Agency Business the need for plant data can be set in the settlement document type/billing document type customizing (field TMFK-WERKM). If plant is required in a certain business scenario, TMFK-WERKM must be set. Below you can find the customizing paths for the above field:

S/4HANA: SPRO: Logistics - General -> Settlement Management -> Settlement Documents -> Settlement Document Types -> All Document Types

ERP: SPRO: Logistics - General -> Agency Business -> Billing -> Billing Document Types

In case the above field was set, plant data will be required on item level for the creation of the settlement document.

If plant was not entered manually, or it could not be determined by the system from other data sources, the program will try to determine a plant from the following data sources, in the below sequence:

Transfer Manager
Plant data from the Customer material info record (CMIR)
Supplying plant of the customer (store)
Delivering plant from the customer master
Delivering plant from the material master
Plant, which is assigned to the company code in Settlement Management/AB customizing

In the "Plant determination logic" section you can find a detailed explanation how plant data can be determined in the corresponding transactions/customizing activities, which would be used by the system for plant determination.

Plant determination logic

Transfer Manager
You can use Transfer Manager to add custom logic for the plant determination and have the plant determined using KOMLFK and KOMLFP structures. For the plant determination, Transfer Event nr. 6F is being used and the plant value should be populated using target structure T001W_KEY.

You can find the customizing activity for Transfer Manager under the following paths in SPRO:
- S/4HANA: SPRO: Logistics - General -> Settlement Management -> Settlement Documents -> Specify Settings for Transfer Manager
- ERP: SPRO: Logistics - General -> Agency Business -> Billing -> Transfer Rules
Plant data from the Customer material info record (CMIR)
Required data: customer number, material number, sales org.
DB table and field name: KNMT-WERKS
TCodes: VD51/VD52/VD53

If purchasing org. data is also passed, then the plant number, which was derived from the CMIR can only be used, if the determined plant was assigned to the purch. org. as well (T024W-WERKS must be equal to KNMT-WERKS)
Supplying plant of the customer (store)
Required data: customer number, material number
DB table and field name: WRF3-LOCLB
TCodes: WB01/WB02/WB03
Depending on material group assignment, there are two options for supplying plant maintenance:
material group was NOT assigned to the material
material group was assigned to the material
if material group was NOT assigned to the material
click on supplying plants:

maintain a valid supplying plant for the store:
Please note, that if multiple valid supplying plants are available in the above transaction, than the system will take the plant information from the one with the highest priority.

if material group was assigned to the material

click on material groups:

select (or if necessary maintain) the relevant material group (the one, which is assigned to the corresponding material), then click on supplying plants:

maintain a valid supplying plant for the store:
Delivering plant from the customer master

Required data: customer number, sales organization
DB table and field name: KNVV-VWERK
TCodes: XD01/XD02/XD03
Sales area data – Shipping tab:
Delivering plant from the material master
Required data: material number, sales organization
DB table and field name: MVKE-DWERK
TCodes: MM01/MM02/MM03
Sales: sales org 1 view:
Plant, which is assigned to the company code in Settlement Management/AB customizing
Required data: company code
DB table and field name: TMZWK-WERKS

Customizing path:
S/4HANA: SPRO: Logistics - General -> Settlement Management -> Basic Settings -> Assign Company Code to Plant
ERP: SPRO: Logistics - General -> Agency Business -> Basic Settings -> Assign Company Code to Plant

Relevant program parts

Plant data is being checked in function module WLF_REGU_CHECK_WERKS.

If plant was entered manually, could not be determined by the program previously, nor it was populated thorugh Transfer Manager, the above described plant determination logic takes place in function module WLF_GET_DEFAULT_PLANT.

Partner determination in Settlement Management in SAP S/4HANA

Customizing settings for Partner Determination

In Settlement Management, partners are determined from the relevant partner determination procedure. In the partner determination procedure partner roles can be maintained. This partner determination procedure has to be assigned to the corresponding settlement document type (TMFK-PARGK).

The above customizing activities can be maintained under the following path:

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. For more information on item level partners, please refer to FAQ Note 550073 (question 2).

Partner Determination logic overview

The logic of partner determination in 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

Please refer to one of the below sections (Partner Determination with DET_PARTNER being initial or Partner Determination with DET_PARTNER being 1) for a description of the program logic which is relevant for your scenario.

Partner Determination with DET_PARTNER being initial

If DET_PARTNER is initial, partners are not determined from Master Data. This means that the system only checks those partners, which were maintained in the partner determination procedure assigned to the settlement document type.

In this case, as per standard design, from the partner determination’s maintained partner functions only the following partner functions are determined by the program from the following KOMLFK fields:

Partner function name	Partner function technical name (PARVW)	KOMLFK field name
Invoicing party	RS	LIFRE
Payer	RG	KUNRG
Bill-to-party	RE	KUNRE
A.payment recipient	AZ	LNRZB

Partner Determination with DET_PARTNER being 1

In case DET_PARTNER is set as „1 - Are Determined from Master Data”, on top of the logic described above, partners are also checked and determined from the relevant master data.

This means that the system first detemines those partners, which were maintained in the partner determination procedure assigned to the settlement document type.

As mentioned above,as per standard design, from the partner determination’s maintained partner functions only the following partner functions are determined by the program from the following KOMLFK fields:

Partner function name	Partner function technical name (PARVW)	KOMLFK field name
Invoicing party	RS	LIFRE
Payer	RG	KUNRG
Bill-to-party	RE	KUNRE
A.payment recipient	AZ	LNRZB

Then, the program additionally checks and determines those partners which might be relevant for the settlement document from master data. For this step the following logic applies:

On the sales side:

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).
The customer account group can be assigned to the customer in BP/XD02 transaction.
then based on the customer account group, the system checks the partner determination procedure (TKUPA-PARGR), which was maintained in the relevant customer master group.
You can maintain this data in the following customizing activity:

SPRO: Sales and Distribution -> Basic Functions -> Partner Determination -> Set Up Partner Determination -> Set Up Partner Determination for Customer Master → Partner Determination Procedure Assignment
finally, the relevant partner functions are read from the determined partner determination procedure which was assigned to the customer master group (TPAER-PARGR).
You can define the partner roles of the partner determination procedure, which was assigned to the relevant customer account group in the following customizing activity:

SPRO: Sales and Distribution -> Basic Functions -> Partner Determination -> Set Up Partner Determination -> Set Up Partner Determination for Customer Master → Partner Determination Procedures → Partner Functions in Procedure

On the purchase side:

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)

The supplier account group can be assigned to the supplier in BP/XK02 transaction.
then based on supplier account group, the system checks the partner determination procedure (T077K-PARGE), which was maintained in the relevant supplier account group
You can maintain this data in the following customizing activity:

SPRO: Materials Management -> Purchasing -> Partner Determination -> Partner Settings in Supplier Master Record -> Assign Partner Schemas to Account Groups
finally, the relevant partner functions are read from the determined partner determination procedure (TPAER-PARGR).

You can define the partner roles of the partner determination procedure, which was assigned to the relevant supplier account group in the following customizing activity:

SPRO: Materials Management -> Purchasing -> Partner Determination -> Partner Settings in Supplier Master Record -> Define Partner Schemas

Please note that in this step, as per standard logic, the system will not check and redetermine the below partner functions from master data:

Invoicing party
Payer
Bill-to-party
A.payment recipient

This means, that with DET_PARTNER being set to 1, the above partner functions are determined from the partner determination procedure which is assigned to the settlement document type, and only additional partner functions (which are different from the partner functions listed above, and which are determined from the partner determination procedure linked to the relevant customer and/or supplier account group) will be determined in this step. The intention of this logic is to ensure that the above listed partner functions are in sync with the relevant WBRK fields, and not redetermined from additional master data.

Relevant program parts and BAdI

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

Useful information from SAP notes

2818448 - How to use Withholding tax in Settlement Management?

In Settlement Management scenarios, the withholding tax code is not entered manually but determined using standard condition technique. For this automatic determination, the Pricing program tries to search for a withholding tax code for the withholding tax condition type from the calculation schema of the settlement document.

Depending on whether you have a customer/supplier-sided Settlement document/process, it has to be ensured that the Pricing program can find a valid condition record for the withholding tax condition type, and is able to determine a withholding tax code from it. Below you can find an overview of the relevant customizing and configuration prerequisites.

Customizing prerequisites in FI

First of all the extended withholding tax needs to be activated for the relevant company code in the Customizing¹
Then a withholding tax type has to be created in the Customizing²:

Please make sure to select the highlighted fields in the above customizing activity.
The withholding tax code needs to be created in the Customizing³
The withholding tax type has to be assigned to the relevant company code in the Customizing⁴
The already created Withholding tax type&code needs to be maintained for the relevant customer(s) / supplier(s).
1. Customer side:
  Please select the relevant Business Partner role for FI Customer (in standard FLCU00) in the ’Company code’ data on the ’Customer: Withholding tax’ tab and ensure that the following data is entered:
  - Withholding tax type, which was created based on the section Step 2.
  - Withholding tax code, which was created based on the section Step 3.
  - Withholding tax agent indicator needs to be flagged
2. Supplier side:
  Please select the relevant Business Partner role for FI Vendor (in standard FLVN00) in the ’Company code’ data on the ’Vendor: Withholding tax’ tab and ensure that the following data is entered:
  - Withholding tax type, which was created based on the section Step 2.
  - Withholding tax code, which was created based on the section Step 3.
  - Subject to Withholding Tax indicator needs to be flagged
The relevant accounts for the extended withholding tax type&code combinations need to be customized⁵
Assignment of withholding tax condition type from Pricing to the withholding tax type in the Customizing⁶

Customizing prerequisites in Pricing

Withholding tax condition type
Due to some differences in the requirements, the Purchasing side (Application M) and the Sales side (Application V) will be explained separately.
1. In a Sales sided scenario (Application V) a withholding tax condition type has to be defined in transaction V/06.
2. In a Purchasing sided scenario (Application M) a withholding tax condition type has to be defined in transaction M/06.
  In purchasing sided scenario, it is first required to create a sales sided withholding tax condition type (see step 1/a) and assign it as a reference condition type to the purchasing sided withholding tax condition type in transaction M/06.
  
  The SD and MM sided condition types must have at least one common access in their access sequences, where the same condition table is used and a valid condition record is maintained (See Step 4 below).
The access sequences for the withholding tax condition type needs to be created in transaction V/07 and/or M/07 (in a purchase sided scenario two access sequences are required:
one in V/07 and another one in M/07), in order to ensure that the relevant condition record can be maintained and found by the Pricing application.
Pricing procedure to include withholding tax condition type – Transactions V/08 or M/08
The withholding tax condition type needs to be added to the bottom of the pricing procedure as a statistical condition.
Maintain withholding tax condition record for SD condition type – Transaction VK11. Here the percentage and the withholding tax code has to be maintained.
Please note that in case of a purchasing sided scenario (application M), the withholding tax condition record has to be maintained for the reference condition type, on the SD side, in transaction VK11.

Customizing paths

#1 - Activate extended withholding tax for company code:
SPRO -> Financial Accounting -> Financial Accounting Global Settings -> Withholding Tax  Extended Withholding Tax -> Company Code -> Activate Extended Withholding Tax

#2 - Creating Withholding tax type:
SPRO -> Financial Accounting -> Financial Accounting Global Settings -> Withholding Tax -> Extended Withholding Tax -> Calculation -> Withholding Tax Type -> Define Withholding Tax Type for Invoice Posting / Define Withholding Tax Type for Payment Posting

#3 - Creating Withholding tax code:
SPRO -> Financial Accounting -> Financial Accounting Global Settings -> Withholding Tax -> Extended Withholding Tax -> Calculation -> Withholding Tax Code -> Define Withholding Tax Codes

#4 - Assigning Withholding tax type to Company code:
SPRO -> Financial Accounting -> Financial Accounting Global Settings -> Withholding Tax -> Extended Withholding Tax -> Company Code -> Assign Withholding Tax Types to Company Codes

#5 - Configuration of relevant accounts:
SPRO -> Financial Accounting -> Financial Accounting Global Settings -> Withholding Tax -> Extended Withholding Tax -> Posting -> Accounts for Withholding Tax -> Define Accounts for Withholding Tax to be Paid Over

#6 - Assign Condition Type to Withholding Tax Type:
SPRO -> Financial Accounting -> Financial Accounting Global Settings -> Withholding Tax -> Extended Withholding Tax -> Calculation -> Withholding Tax Type -> Assign Condition Type to Withholding Tax Type

Most important program parts and debugging hints

Method: FILL_ACC_DATA_SINGLE_DOC (CL_WLF_ACC_DOC_CREATE)

-Together with all the other conditions, the withholding tax is also processed here to create ACCIT lines from them.
- Withholding tax condition: KOMV_TYPE 7

Method: CREATE_WITHHOLDING_TAX_LINE (CL_WLF_ACCOUNTING_LINE_SERVICE)

- Only the active condition types are processed (KOMV- KINAK)
- The Application needs to be V (in case of Purchasing side coming from the reference condition)
- Company code (BUKRS) is determined based on the Price Determination sides (WKOPAR)
- Withholding tax type will be proposed from the country key of BURKS and the condition type.
- The withholding tax code is taken over from the condition record (KOMV-MWSK2)
- Condition Base Value (KOMV-KAWRT) and Condition value (KOMV-KWERT) must not be initial

Function Module: AC_DOCUMENT_CREATE
- ACCWT table will contain the withholding tax data

2474855 - Output Management for Settlement Management Documents

Limitations

Output for settlement management documents is only issued by Output Management for the output medium type PRINT. The output medium types EMAIL, XML, and IDOC are currently not supported.
Output for settlement management documents issued by Output Management can only be maintained or previewed through the Output Management window opened from within the settlement management document (refer to the Settlement management menu option More → Extras → Messages → Edit).
Output for settlement management documents issued by Output Management can only be previewed through the Output Management window opened from within the settlement management document (refer to the Settlement management menu option More → Extras → Messages → Output).
Output for settlement management documents is only issued by Output Management at the settlement management document header level.
Output for settlement management documents is only available for Dynpro programs with SAP GUI support for Windows and/or HTML.
Output for settlement management documents by Output Management is only supported for the default customizing settings described below.

2781231 - Differences in Settlement Management and SD/MM sided pricing procedures

Please use different pricing procedures on SD/MM and Settlement Management side. In case you wish to modify or use your own pricing procedures, please consider that SD/MM pricing procedures can contain the condition records for accruals (e.g. REA1). The use settlement related condition records like rebate (e.g. RES1) on SD/MM side is not recommended and not foreseen.

2487531 - Posting Agency Business/Settlement Mangement documents to COPA scenarios

If this behavior doesn't fit your requirement you can always influence it differently by setting or clearing the fields using transfer manager or BAdI implementation. The proper event in transfer manager to set KSCHL in ACCIT structure to skip the standard behavior is event '39' and the BAdI method to impement is WLF_ACC_ENHANCEMENT_EXT~CHANGE_MATERIAL_LINE.

2763943 - Rebate relevant flag is not considered in Settlement Management

You are using Settlement Management in S/4HANA and you set the customer and/or the sales organization as rebate relevant. You expect that this is considered during the settlement process.

In the classic SD rebate process the 'Rebate relevant' flag was necessary to create agreements, however, in the standard Condition Contract Management (CCM) it is not used. In CCM the only rebate relevancy, which is considered from SD side is regarding the SD billing document type.

In CCM the system defines the relevancy based on the business volume selection criteria, therefore there is no need to set a specific customer or sales organization as rebate relevant.

If other indicators from the classic SD rebate agreement are required in your special business process, you have the option to add them as business volume selection criteria. Please refer to the following KBA for further information: 2481934.

2481934 - Extending the field catalog for bus.vol.sel. field combinations

If the fields, which are available in the standard system (in WB2_S_BVB_FIELDCAT) does not fulfill your requirement and you wish to add new fields to the catalog of the business volume selection criteria, you have to extend the structure WB2_S_BVB_FIELDCAT.

If you add a search help or check table to a new field in WB2_S_BVB_FIELDCAT, this information is taken into account when the fields are being displayed in ALV. In case a check table is defined, the value check is done in a generic way. Moreover; it is also possible to define check classes; which are called upon saving the condition contract. When an error is issued by the program, a protocol will be displayed. If a description of the field has to be displayed, the BAdI WB2_BUSVOLBASE_TEXTS must be implemented.

Please note that the business volume selection criteria is used during the selection of the business volume in the settlement program (WB2R_SC or WB2R_SV) or in WB2R_BUSVOL. Therefore, only such fields should be added to the field catalogue and used in a field combination, which are also present in the used business volume table, otherwise the program will not be able to execute the business volume selection and will dump.

2815535 - FAQ: Condition Contract Management by Settlement Management in SAP S/4HANA

2595338 - Partner determination in Settlement Management/Agency business

2685781 - Deletion and Blocking of Customer and Vendor in Agency Business/Settlement Management

EDI

2781126 - Raising EDI / IDoc message from Agency Business / Settlement Management

You would like to raise an EDI / IDoc message during processing a document from Agency Business / Settlement Management and you are looking for an enhancement point.

If you wish to raise an EDI / IDoc message during processing documents from Agency Business / Settlement Management, you may consider using the Function Module WLF_INVOICE01_REGU. This Function Module calls the BAdI WLF_INVOICE01_REGU with default implementation. It can be used to fill different segments based on agency business / settlement documents. In case this BAdI or implementations do not fulfill your requirements, you may consider having an own BAdI implementation with your own code.

708348 - Structure of IDoc segments in Settlement Management

You can change the standard segments structure by using the BAdI implementation WLF_INVOICE01_REGU to introduce levels creating a hierarchy, if desired. In the BAdI there are several methods, which can be used to implement your own logic.

Account determination enhancements

SAPLWLFB/ACCOUNT_DETERM_SD
Function WLF_INVOICE_ACCOUNT_DETERM
LWLF1F0R/REGU_ENDE_BEARBEITUNG

Pricing enhancement

WLF_FILL_PRICING_HEADER
WLF_FILL_PRICING_POSITION