There has been many documents and blogs in the forum discussing about condition upload/replication and its debugging from ECC to CRM system. However in most of the cases condition records are created and maintained in ECC, there are few situations where the records are created and maintained in CRM and later replicated to ECC. One of such scenario is condition maintenance for Trade Promotion Management (TPM) which includes conditions for Campaign Determination, Rebates, Pricing and Free Goods. In this blog I like share my experience on how to debug the data flow and the points you should look for.
Pre-requisites: I like to assume that the reader is aware of concepts of Business objects, initial load and queue monitoring.
Transaction to view adapter object is R3AC5. Conditions upload objects usually have name UPL* or ZUPL* with required description containing the table name. SAP has provided few upload objects that can be used as reference for creating our own objects.
![Picture_1.png]()
The mapping modules CND_MAP_MAST_EXCHANGE_MAIN_MBD and CND_MAP_MAST_UPLOAD_R3A play an important role.
Step 1> Start initial load for the object using transaction R3AS. Before running initial load start the debugger by entering /h in command box.
![Picture_2.png]()
Step 2> Upon starting the load and debugging starts, keep a break point for function module SMOF_START_DOWNLOAD_OR_REQUEST. This is the place where the load will start. The FM calls SMOF0_INIT_DNL_START which will in turn triggers further processes.
Step 3> Function Module SMOF0_INIT_DNL_START calls FM CRS_FIRST_DOWNLOAD_TRIGGER from where data fetching and sending process starts. By default, this FM is called in background task that cannot be debugged. However during debugging we have an option avoid running in background and debug the flow. Variable da_smofparsfa-parval1 should be set to 'X' so that program flow takes the ELSE part of the condition so that FM CRS_FIRST_DOWNLOAD_TRIGGER is called as an RFC to the same system.
![Picture_3.PNG]()
Step 4> Function Module CRS_FIRST_DOWNLOAD_TRIGGER is called as an RFC in the same CRM system. This FM calls the extractor module CND_MAST_EXTRACT_GUIDS_MAIN that fetches the condition record GUIDs (field VARNUMH in condition table) by calling FM CND_MAST_GET_GUIDS and prepares to send the data. Note that at this step, only the key field for the records (GUIDs) are fetched and not the entire data of the records.
Step 5> Once the key values of condition records is available, sub-routine CRS_SEND_TO_SERVER is called. The sub-routine calls FM CRS_SEND_TO_SERVER where filtering of data. This FM in turn calls the FM CRM_MAP_XML_AND_SEND_TO_SERVER that will convert the values to XML format and prepares to send the data. The execution reaches a point when FM BAPI_CRM_SAVE is called in background task as a RFC to the same CRM system further, which we can not debug.
Step 6> Though further debugging is not possible because BAPI_CRM_SAVE is executed in background task, we have other ways to achieve the same. It creates an inbound queue with the name CRI_<object name>_R3AI (queue name can depend on the configuration that has been set up) which can be stopped using transaction SMQR. So, before you execute the background task de-register the queue in SMQR, which will stop processing of the queue that can be viewed in transaction SMQ2.
Step 7> Go to transaction SMQ2 -> Double click on the queue entry with name CRI_<object name>_* -> select the first entry and click on 'Debug LUW' button which takes you to a debugger screen with call to BAPI_CRM_SAVE. The FM does not have code logic of its own but it directly calls CRM_GENERIC_CRM_IN function module.
Step 8> The next step in debugging is call to MAP_BAPIMTCS_AND_PROCESS. This is the entry point for preparing and processing of data before send. It calls the mapping module (R3 to CRM that is maintained for the object) CND_MAP_MAST_EXCHANGE_MAIN_MBD that will prepare the global internal tables before calling CND_MAP_MAST_INIT_CDB_MAIN.
Step 9> Function Module CND_MAP_MAST_INIT_CDB_MAIN checks for any on going loads on the same table. So far the flow has only list of GUIDs of the condition records and nothing else. The list of GUIDs is passed to FM CND_MAST_DATA_EXTRACT which extracts the condition records and populates the data to a working set. A working set contains data for every condition record in it which will later be used for further processing. The next step in process is to call CND_MAP_MAST_CONV_SAVE.
Step 10> Function module CND_MAP_MAST_CONV_SAVE handles updating of conversion tables like CND_MAPM_CNV_REC, CND_MAPM_CNV_AGM etc. It further calls FM CND_MAST_INT_DEEP_FILL which will create the BDOC segments and fill data in it. Further processing involves middleware aspects which we do not need at this point.
Step 11> As the last point in process chain, function module CND_MAP_MAST_UPLOAD_R3A is called which inturn calls FM CND_MAP_MAST_EXT_FRAME for mapping the data to BAPI structures and send the data to ERP system.
