This page was created to clarify the application logic of condition processing in case of Contract and Scheduling Agreement BAPIs or XMLs. Similar logic occurs in case of Info Record condition processing too.
When an ECC contract is created or changed via BAPI or from SRM via XML, system calls a general condition processing logic to update the conditions of the document, if necessary. The most common error that can occur during this process is ME 816 - System error (error in method CL_API_MASTER_CONDITION_MM=>PROCESS). This is a general error, so to determine the root cause of it, it is necessary to check the BAPI or XML parameters based on KBA 2338551 and debug the logic.
Start the debugging in method IS_VALID of Include LMEOUTP5B.
Here system loops at items and processes the conditions by calling method PROCESS.
In method PROCESS, system calls method HANDLING_CONDITION.
In method HANDLING_CONDITION, the system reads the condition data from the buffer table MT_CONDITION_DATA (it is populated by method PUSH_DATA of class CL_API_MASTER_CONDITION_MM) and determines the relevant condition from the database table, where it needs to store the conditions (plant-independent contract condition A016, plant-dependent contract condition A068). Check if the data in tables, such as KONH and KONP are correct. KONH contains the validity period, KONP contains the condition data such as price, type, unit, etc.
In method PROCESS_CONDITION, the system gathers the relevant condition types into table LT_KSCHL and loops at them to process each type using method PROCESS_VAL_PERIODS.
In method PROCESS_VAL_PERIODS, the system processes the condition using COND_MNT* function modules. Each FM has a CATCH statement. If you receive error ME 816, it means that one of these FMs throws an exception. In that case, you need to go into that specific function module to find the cause. The first FM is COND_MNT_INIT, which initialize the conditioning process.
The system populates the search criteria into table LT_SELTAB to check if the condition type is already added into the document and to gather all validity period using FM COND_MNT_START.
You can find the gathered condition entries in table LT_COND_RECS_DB.
System checks, if it could find any entry to determine the next step.
The possible steps are the followings:
- If no entry was found in the database: the system needs to insert the condition, so it will return from method PROCESS_VAL_PERIODS to prepare the data.
Returning to PROCESS_CONDITION, the system builds the KONP and KONH tables and calls function module COND_MNT_RECORD_PUT.
This function checks the condition data and populates the XVAKE table that contains the validity periods and the relevant KNUMH values.
- If the system could find conditions in the database: it performs the necessary update (function COND_MNT_RECORD_DATACHANGE) or deletion (function COND_MNT_RECORD_DELETE).
Afterwards, the system calls function module COND_MNT_SAVE.
The system follows the calls KONDITION_SICHERN → KONDITION_SICHERN_DB.
In KONDITION_SICHERN_DB system loops at the XKONH and XKONP tables, which contains the new and old condition entries and deletes those entries, where the field UPDKZ is blank. In case of new records, UPDKZ should be 'I'; in case of a changed record, UPDKZ should be 'U'.
Afterward, the system updates the condition data into buffer tables or it calls the database update directly. In the first case, the system copies the condition data into database structures and calls function SET_DATA.
In method SET_DATA system appends the condition data into the buffer (ME->MR_SAVE).
Returning (F7) several calls in method PROCESS_CONDITION, the next DO step starts and system processes another condition type in the same way.
After the cycle ended, in method PROCESS of class CL_API_MASTER_CONDITION_MM, the system calculates the new net price of the item into field EV_NETPR (EKPO-NETPR), if necessary using method PROCESS_PRICING.
Finally, system calls function RV_KONDITION_SICHERN_V13A in update task to update the values into database tables.
Related SAP Notes/KBAs
KBA: 2338551 How to create a perfect SRM Performance incident