Learn how a debugging session speeds up the time it takes to uncover the cause of an error when replicating mySAP CRM business partner data to mySAP ERP Central Component.
Key Concept
You use Business Documents for data exchange and data processing within mySAP CRM. They serve as data containers for processing business objects that logically belong together, for example, all data about one order or one customer.
Have you experienced trouble with your mySAP CRM business partner data not replicating to mySAP ERP Central Component (ECC)? Inconsistent settings for required fields often cause errors during this process. You could compare the customizing between mySAP CRM and ECC field by field, but this is a tedious, time-consuming task. Instead, a quick debugging session can pinpoint the problem more quickly and with less frustration.
Note
The screenprints for this article are from mySAP CRM 4.0, although this process also works with mySAP CRM 2005. The ABAP debugger has changed in mySAP CRM 2005, so the screen look and feel is different.
I will show you step-by-step how to isolate an error. First, you must locate the business document (BDoc) with the error in transaction SMW01 (queued Remote Function Call [qRFC] Monitor). Then you start the debugger and set a flag so that the system stops the BDoc in the outgoing queue. From the entry in the outgoing queue, you continue to debug the code. Next, set a breakpoint in the program so that you can change to online processing to view the screens and data entry in the ECC system. Once you step through the ECC screens, you can easily identify the mandatory fields and correct them as needed.
Step 1. Execute transaction SMW01 (Figure 1). Under the BDoc State tab, select Errors. In the Send Date and Time tab, select Today, then press F8 to display the results.

Figure 1
Select the parameters to view the BDoc errors click here to view a larger version of this image
In the screen that appears (Figure 2), you can see that the system found one error, indicated by the red traffic light in the State column and the description Partially send, receivers have errors. The BDoc type BUPA_MAIN indicates that the replication object is a CRM business partner. Select the item by clicking on it, then click on the show BDoc msg errors/receivers icon
. In the screen that appears (Figure 3), select the grid icon
under Errors, then click on the Longtext button in the following screen to display the error details (Figure 4).

Figure 2
The highlighted traffic light on the left in the State column indicates an error

Figure 3
Click on the grid icon to view the error

Figure 4
View the error details
Message number 00055 indicates that you have not maintained a field in mySAP CRM that was set to required in ECC customizing while creating the business partner. The following steps explain how to debug this particular error; other errors/message numbers may require other debugging techniques.
Step 2. Return to the Selection Result screen in Figure 2 by closing the pop-up boxes. To start debugging enter /h
(the standard SAP command for debug) in the command field next to the green check mark icon and press Enter. A success message, Debugging switched on, appears in the bottom left corner of the screen.
Select BUPA_MAIN again in Figure 2, then click on the reprocess BDoc message icon
. The BDoc transmission ended in an error, so the data is not yet in ECC. By reprocessing the BDoc, you resend the data from mySAP CRM to ECC.
In the screen that appears, click on the Settings button. Next, in the ABAP Debugger screen (Figure 5), in the Settings tab select In background task: Do not process. This stops the BDoc in the outbound queue. Without intervention, the BDoc would be in this queue for only an instant before it jumped from mySAP CRM to the ECC inbound queue.

Figure 5
Select In background task: Do not process to stop the BDoc in the outbound queue
Step 3. Click on the run (to cursor) icon
or press F8 to continue to execute the code. In the pop-up warning that appears (Figure 6), click on the Yes button to proceed with reprocessing the BDoc. A message at the bottom left corner of the screen indicates that the system reprocessed the BDoc successfully (Figure 7).

Figure 6
Pop-up BDoc warning message

Figure 7
Success message indicates BDoc reprocessed
Step 4. Go to transaction SMQ1 (qRFC Monitor [Outbound Queue]). You do not need to enter anything in this screen (shown in Figure 8) so click on the execute icon or press F8. Because I opted to run this task in the background in step 2, I can catch the BDoc in this queue.

Figure 8
Enter the qRFC Monitor (Outbound Queue) via SMQ1
After clicking on the execute icon, you see the screen shown in Figure 9, which shows the BDoc that the system reprocessed in transaction SMW01. The system stopped the BDoc in the outbound queue because I selected In background task: Do not process in Figure 5.

Figure 9
The BUPA_MAIN upload queue always starts with R3AUBUPA. In this example 1000010234 is the customer number.
Double-click twice on the entry to drill down into the object to get to the function module. In the screen that appears (Figure 10), click on the debug logical unit of work (LUW) icon
or press F8 to view the debugger screen for the ABAP code shown in Figure 11. In the next step, I’ll show you how to set a breakpoint in the code so that the program stops at a particular point where you can change the mode of the transaction call.

Figure 10
Click on the LUW icon to view the code for the BDoc click here to view a larger version of this image

Figure 11
Select Breakpoints>Breakpoint at>Statement… to set when to stop the code from running
Step 5. In the debugger, select the menu path Breakpoints>Breakpoint at> Statement…. The Create Breakpoint pop-up screen appears (Figure 12). In the Breakpoint at statement field, enter call transaction
. Click on the green check mark icon or press Enter. A success message, Breakpoint set, appears in the lower left corner of the screen.

Figure 12
Stop the code at the call transaction line
Next, click on the run (to cursor) icon or press F8. The system continues to execute the code until it reaches the breakpoint set at the statement call transaction. The stop icon indicates when the system reaches the breakpoint (Figure 13).

Figure 13
The stop icon indicates the breakpoint in the code
Step 6. Double-click on the variable CALL_TRANSACTION_MODE in Figure 13. In the Field contents table that appears (Figure 14), change N to A
. The N stands for “do not show dynpros” and A stands for “show all dynpros.” Save the change by clicking on the pencil icon. The program would normally run in the background without running through the screen sequence, but changing the mode from N to A allows you to step through the screens as if you were creating the customer online in ECC with transaction XD01.

Figure 14
Change the N to A for CALL_TRANSACTION_MODE
Click on the run (to cursor) icon or press F8 to allow the system to continue running the code. As you view the Customer Create screens, the system indicates the mandatory field errors by a flagged check box, as shown in Figure 15.

Figure 15
The check boxes indicate errors in mandatory fields
Tip!
Make sure that the account group configuration is consistent in both ECC and mySAP CRM. One way to ensure that both systems are in sync is to make everything optional in ECC and let mySAP CRM control it.
If the field should be required then correct the configuration in CRM. Select Customer>Close to exit out of the debugging session. Then follow menu path Cross-Application Components>SAP Business Partner>Business Partner>Basic Settings>Field Groupings>Configure Field Attributes per Client or Configure Field Attributes per BP Role, etc.
If the field should not be required, correct this in ECC via IMG menu path Logistics – General>Business Partner>Customers>Control>Define Account Groups and Field Selection for Customers.
Karen Lindholm
Karen Lindholm is a senior consultant with PRAGMATEK Consulting Group in Minneapolis. She has been working with SAP products for more than eight years. As an SAP AG SD consultant, she implemented apparel and footwear (AFS) projects in Europe. Karen has also worked as a global support consultant for SAP America in SD and CRM , as well as a CRM consultant for SAP America’s Demo Development Group. Karen holds a bachelor of arts degree from Stanford University. Currently, she is the CRM consultant for a medical device company.
You may contact the author at Karen.Lindholm@pragmatek.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.