Purpose

This page was created to clarify the application logic that creates ECC Contract during SRM Contract distribution.

Overview

When an SRM Contract is distributed, ECC receives the XML PurchasingContractSRMReplicationRequest_In. System processes this XML and creates an ECC Contract. If it runs successfully, system sends the confirmation XML (PurchasingContractSRMReplicationConfirmation_Out) to SRM.

For the application logic that creates XML PurchasingContractSRMReplicationRequest_In on SRM side, refer to Wiki page Contract distribution - Starting the Trouble Shooting.
For the application logic that processes the XML PurchasingContractSRMReplicationConfirmation_Out on SRM side, refer to Wiki page Contract Distribution - Confirmation XML processing.

Debugging Guide

To debug the XML process, you need to reprocess the XML.

Do not reprocess the XML in production environment. Document used with this procedure can become inconsistent.

To know how you can do this, please refer to the following Wiki page: Debugging guide for XML processing .

According to the above Wiki page, you have loaded the XML in SPROXY. At this point, check if the XML has Action Code 01 (meaning it should create a new contract). If yes, it is necessary to verify, if the ECC Contract has been already created, when the XML was initially processed by the system. You can do this, by searching in table BBP_CTR_ITEM_MAP with OBJECT_ID = the SRM Contract number that you can find in the XML. If you can find an entry, you will need to overwrite the Contract number in XML tag <ID> to a number that doesn't exist in the table. (This is necessary, because system checks if the Contract has been already created and if yes, it will call different logic).

If you overwrote the Contract number or the Contract hasn't been yet created, set a breakpoint in Method PROCESS_IN of class CL_SE_PUR_PCSRMRPLCTNRQ.

When you execute the XML processing, the breakpoint will stop.

First system maps the data from XML into structure PC_BAPI_HEADER and PC_BAPI_ITEM. Here verify, if the correct values are mapped into these structures.

After the standard mapping logic there is a possibility to overwrite the mapped data using BAdI PUR_SE_PCSRMRPLCTNRQ_ASYN (Method INBOUND_PROCESSING).

Then system calls Method SET_DATA, which maps the previously filled item and header values into the BAPI structures MY_HEADER and MY_ITEMS.

Afterwards system calls Method PROCESS.

In this Method, system calls Method PROCESS. Go into that and you can find the main processing routine, which transfers the XML mapped values (condition, accounting, service) into BAPI structure ME->MY* (e.g.: MY_ESLL, MY_COND).

Then system calls Method PROCESS_OUT (L2014I02).

In this Method, system calls Method PROCESS, which performs the rule-based validation of the data at header and item level. For example: system checks if all mandatory fields are filled, or if the values are valid.

Afterwards (still in Method PROCESS_OUT), system checks, if there were any error message during validation using Method GET_BAPI_STATE. If this CHECK fails, it means that at least one error message was raised. To see the error, you can jump back to this line and press F5. There you will see a logic that populates table LT_MESS.

If the CHECK doesn't fail (meaning no error occurred during validation), system calls Method POST. This Method calls PREPARE_POST (LMEOUTP01). It is responsible to map the data into DB structures (e.g.: LT_UEKPO, LT_XCCM_IT, LT_UEKKN_IT) and set them into the update queue (MY_UPDATE_QUEUE), which will be the basis for the actual post that saves the document into DB.

This prepares the data too that is stored in table BBP_CTR_ITEM_MAP using Method PREPARE_UPD_CCM (LMEOUTP02).

Then system calls Method COMMIT, which calls the final POST Method (LMEOUTP14) to update the data in DB. In this POST Method, system loops at the previously filled update queue (MY_UPDATE_QUEUE) and stores the data into DB tables.