0000656823

7/17/2019 0000656823

http://slidepdf.com/reader/full/0000656823 1/5

SAP Note

Header Data

Symptom

This note contains a list of the most frequent problems / questions during the analysis of transferproblems with sales documents.Emphasis is placed on debugging.

1. How does the debugging of a document from CRM to R/3 work?

2. How does the debugging MSA -> CRM -> R/3 work?

3. How does the reply from R/3 to CRM work?

4. How does the initial download work?

5. How does the request download work?

6. How does the delta download work?

7. How does the reply to CRM work with a delivery / rush order / billing document?

Other Terms

FAQ, upload, Mobiles Sales, sales documents

Reason and Prerequisites

Help for troubleshooting.

IMPORTANT!On account of many requests, SAP decided to release this note (which was intended originally forinternal use) for customers. However, SAP would like to point out that this note was created on thebasis on CRM 3.0. Therefore, there may be (slight) differences in other releases.

Solution

1. Question: How does the debugging of a document from CRM to R/3 work?

Answer:

a) Switching on the debugger:Before saving the document, you should switch on the debugger by entering the command /h. =>Save the document.

b) Stopping the process in the CRM queue SMQ1 or SMQ2:A breakpoint should be set on function module CRM_UPLOAD_BTMBDOC_START_FLOW. When a CRMdocument is transferred normally, you can set field LV_IN_UPDATETASK to SPACE before methodPROCESS_OUTBOUND is called. In addition, you have to select indicator "In background task:Do not process" in the debugger settings. Then continue with F8.Usually, this should cause that the BDoc stops in the Middleware queue and can be foundagain using Transaction SMQ1 or SMQ2.

c) Process does not stop in CRM queue SMQ1 or SMQ2:If this method does not work, you should open a parallel mode and go to Transaction SMQRwhile you stop in the debugger in function CRM_UPLOAD_BTMBDOC_START_FLOW. Now deregister the

queue with the queue name. Go back to the debugger and continue with F8.Remark: After starting the process from the queue, you must register the queue name again -this is necessary, on the one hand, to keep the number of entries in Transaction SMQR low,and, on the other hand, to avoid inadvertently holding up other documents.

d) Determination of the queue name:In order to find again the process in SMQ1 or SMQ2 and in particular to deregister thequeue, you have to know the name of the queue. For this purpose, you can use the following'80% method':Using F6, debug over the position READ TABLE lt_orderadm_h INTO ls_orderadm_h INDEX 1. Nowdisplay field ls_orderadm_h-object_id = <obj.id>. The queue name is then CSA_ORDER_<obj.id>.

656823 - FAQ: Tips and tricks for transfer debugging

Version 24 Validity: 19.02.2004 - active Language English

Released On 19.02.2004 14:28:22

Release Status Released for Customer

Component CRM-BTX-BF-IF R/3 Interface for Business Transactions

Priority Recommendations / Additional InfoCategory Help for error analysis

7/17/2019 0000656823


If the '80% method' is not successful, you can find out the name of the queue if you debuginto method call PROCESS_OUTBOUND. Here you have to debug into method PROCESS_NOTIFICATIONfor the "Single Case" (see comment '* Single Case' in the source code). Field LV_HEADER-QNAME is determined there. This field contains the queue name.

e) Starting the process from queue SMQ1 or SMQ2:The document should have stopped now in the queue, that is, call Transaction SMQ1 and searchfor the name of the queue. If you cannot find the queue, check in Transaction SMQ2. If youdo not find the name here either, you might have to vary the above-mentioned method.If the queue was found, it can be debugged. Double-click twice the name of the queue, thenselect the line and choose 'Debug LUW'. Breakpoint on function moduleCRM_R3_SALESDOCUMENT_UPLOAD. Continue with F8.In this module, the filtering and mapping and the call to the R/3 system(BAPI_SALESDOCU_PROXY_UPLOAD) occurs.

f) Filter:If the document still contains errors, module CRM_SALESDOCUMENT_FILTER returns a SY-SUBRCnot equal to zero and the document is not transferred to the R/3 system. Thus, if you do notreach the R/3 system, you can check what the filter returns here.In addition, errors in the CRM documen, which would usually prevent the transfer can beavoided by setting SY-SUBRC to zero after the call of module CRM_SALESDOCUMENT_FILTER.

g) Mapper:If certain fields are not transferred from the CRM server to the R/3 system, you should takea closer look at the mapping of the BDoc structures in the BAPI structures. This is done infunction module CRM_SALESDOC_MAP_MBDOC2BAPI.

h) Call to the R/3 system:The call to the R/3 system is performed via module BAPI_SALESDOCU_PROXY_UPLOAD. You can callthis module in two different modes: Asynchronous (that is, in the background, which isdisadvantageous for debugging), or synchronous (that is, directly). The second method isappropriate for debugging directly to the R/3 system (without a queue). For this purpose,

parameter GV_SYNCHRONOUS_CALL must be set to 'X' (preferably immediately before the call ofBAPI_SALESDOCU_PROXY_UPLOAD).If you use the synchronous method, you can select setting 'In background task: Do notprocess' in the debugger. In this case, the document should stop in the queue.

i) Debugger does not stop in the R/3 system:If it is not possible to debug into the R/3 system, the reason for this is often that theRFC user that is used in the R/3 system is not a dialog user. To check this, SAP recommendsthat you search for the user in Transaction SM59 in the corresponding R/3 connection (seebelow) ('Logon/Security' tab, User). You can check the settings for this user in the R/3system in Transaction SU01. On the 'Logon data' tab, 'Dialog' should be set as the usertype.

j) Determination of the connected R/3 system:To determine the user (for example, in Transaction SM59), you have to know the connected R/3system. For this purpose, you can display the contents of table SMOF_ERPSH in TransactionSE16. It should contain an entry with SITETYPEID = SMOF_ERPSITE. Field RFC_DEST contains the

ID of the connected R/3 system.

2. Question: How does the debugging MSA -> CRM -> R/3 work?

Answer:First of all, you should ask the customer to create a document on the client and place it in theinbound queue of the CRM server. This document should have BDOC type SALESDOCGEN_O_W. As ofRelease 3.0, an MSA sales document is also created in CRM. That is, module CRM_ORDER_MAINTAIN isalways called and then module CRM_ORDER_SAVE. Thus, module CRM_UPLOAD_BTMBDOC_START_FLOW is alsocalled in the further course of processing. The f urther process is the same as described underQuestion 1.

3. Question: How does the reply from R/3 to CRM work?

Answer:

a) Determining the data that is to be retransferred to CRM:In the R/3 system, FORM routine MV45AF0B_BAPIDATEN_ERMITTELN is called inMV45AF0B_BELEG_SICHERN. If a CRM server is connected, this FORM routine determines the datathat is supposed to be returned to the CRM Server. This is done by means of moduleSD_SALES_DOCUMENT_PREFETCH and depends on the scenario set in Customizing (see Note 541113).In the standard scenario, for example, no order data is returned to CRM; The data determinedfor the reply is transferred in global tables (for example, GT_VBAK in function moduleCRS_SALES_COLLECT_DATA).

b) Flow logic within the R/3 system:You should stop in function module CRS_SALES_COLLECT_DATA by means of a breakpoint. Here,variables GV_SEND_TOGETHER and GV_KEYS_AVAILABLE must be set to 'X'.The subsequent flow logic starts with module CRS_SALES_SEND_TO_SERVER which calls moduleCRS_SEND_TO_SERVER. Afterwards, module CRS_SALES_COLLECT_KEYS is called.

c) Determining the queue name for the reply:To deregister the queue in the CRM server (see below), you require the queue name. Thisqueue name is determined in module CRS_SEND_TO_SERVER for the reply. The actual task isperformed by module CRM_FIRST_CALL_OPERATIONS which is called there. Table GT_RFCDEST isfilled afterwards. Field RFC_QUEUE contains the queue name.

d) Filtering the data to be returned:The filtering of the data to be returned is also performed in module CRS_SEND_TO_SERVER,with the aid of module CRM_FILTER_DOWNLOAD_DATA. The data to be filtered is contained intable T_BAPISTRUCTURES which contains fewer entries if data has been filtered out.

7/17/2019 0000656823


e) Deregistering the queue in the CRM server and restarting the document:At this point you should deregister the reply queue in the CRM server in Transaction SMQR.Afterwards, you can exit the debugging mode in the R/3 system using F8. Back in the CRMserver you can find the stopped BDoc in the inbound queue (Transaction SMQ2) under the queuename that was deregistered before. You can start this queue by choosing 'Debug LUW'. Do notforget to reregister the queue name in Transaction SMQR!

f) Flow logic within the CRM server:The function module that starts the inbound processing in CRM is BAPI_CRM_SAVE.The process sequence is roughly as follows:First, the data is mapped from the BAPI to the CRM structures. This is done by moduleCRM_SALESDOC_MAP_BAPI2MBDOC. Afterwards, the validation occurs by means of moduleCRM_DOWNLOAD_BTMBDOC_VAL. This module calls module CRM_DOWNLOAD_BTMBDOC which in turn callsmodule CRM_DOWNLOAD_BTMBDOC_FILTER which resets status 'To Be Distributed' and sets status'Distributed' instead.

g) Document processing in CRM:Document processing is also called in CRM from module CRM_DOWNLOAD_BTMBDOC if data wasreturned to the CRM server and not only the status was reset. Document processing is carriedout via module CRM_ORDER_MAINTAIN. Finally, the call to save the document is called frommodule CRM_DOWNLOAD_BTMBDOC. The document is saved by means of module CRM_ORDER_SAVE.

4. Question: How does the initial download work?

Answer:

a) Basic Note 490932:If problems occur during the initial download, Note 490932 can be of further assistance inmany cases.

b) Maintaining the filter settings:

First of all, the customer has to maintain the filters for object 'Salesdocument' inTransaction R3AC1. You can reach the filter settings by choosing the filter symbol. Then goto the 'Tables/Structures Within Object' tab. In addition, you must select the correspondingsource site (that is, the R/3 system). Now the filter conditions should be displayed. Thefilter can be set according to different criteria, for example according to a documentnumber interval. In this case, only the documents contained in this interval are sent to theCRM server. It is important that you fill up the document number to 10 characters withleading zeros.If you encounter problems with the filter settings, Note 497327 might be of furtherassistance.

c) Starting the initial download with Transaction R3AS:If the filter settings are correct, the initial download is started with Transaction R3ASfor the corresponding object.IMPORTANT! The initial download should only be carried out once for each document becauseproblems can occur if you start the initial download for documents that already exist in theCRM Server. In this context, also refer to Note 617598. After the initial download has been

carried out once successfully, another initial download is no longer required becausechanges to the documents are automatically sent by delta download from the R/3 system to theCRM server.

d) Starting the debugging of the initial download:The sequence of the initial download is as follows:Call Transaction R3AS, select the object by means of the input help and go to the debuggerby using /h.First, module SMOF_START_DOWNLOAD_OR_REQUEST is called. This module calls moduleSMOF0_INIT_DNL_START. In this module the call to the R/3 system is started. Thecorresponding module in R/3 is CRS_FIRST_DOWNLOAD_TRIGGER.

e) Synchronous or asynchronous call of the R/3 system:Like with the upload, you also have the option here of calling directly to the R/3 system(synchronous call) or via a queue (asynchronous call). During the asynchronous call, thequeue must be deregistered again in Transaction SMQR. You can determine the queue name ifyou set a breakpoint on the line 'IF lv_do_not_use_standard IS INITIAL.' which is located

just above the call of function module TRFC_SET_QUEUE_NAME in module SMOF0_INIT_DNL_START.At this time, the local variable LV_QNAME should contain the queue name. If, on the otherhand, you want to debugger synchronously (that is, directly) into the R/3 system, you haveto set variable DA_SMOFPARSFA-PARVAL1 to 'X' at the above-mentioned breakpoint.

f) Selecting the R/3 documents that are to be sent to CRM:In the R/3 system, the documents that are supposed to be sent to the CRM server are selectedwith the help of the filter settings from table VBAK. This is done in moduleORDER_SELECT_NEXT_ID. This module returns table T_OUT_ID_LIST which contains all documentsthat were found using the filter settings. If a customer experiences problems that somedocuments are not loaded into the CRM server, you can check here whether the documents areactually selected with the valid filter settings.

g) Sending the R/3 documents and processing in CRM:Module SD_SALES_DOCUMENT_PREFETCH which provides the document data is called withT_OUT_ID_LIST. Afterwards, module CRS_SALES_SEND_TO_SERVER is called as in the reply (seePoint 3). The further process is the same. The data is filtered, the queue is determined.

However, during the download in CRM, document processing is always carried out with modulesCRM_ORDER_MAINTAIN and CRM_ORDER_SAVE. It should be noted here that the initial download canbe a BDoc with more than one sales document.

5. Question: How does the request download work?

Answer:

a) Difference to initial download:

7/17/2019 0000656823


Basically, the way the request download works is similar to the initial download. However,it is possible at any time and can also be started for individual documents that alreadyexist in the CRM server. However, to avoid errors it is always better to delete the documentbefore using program CRM_ORDER_DELETE.

b) Creating the request in Transaction R3AR2:A new request is created in Transaction R3AR2. You can choose any request name you like. SAPrecommends that you select the object name via the input help because the remaining data isthen also filled. The sales document object is the 'SALESDOCUMENT'.Next, you have to create the request details (by double-clicking the 'Request detail' folderto the left of the tree and choosing 'New entries'). As in the initial download, you canenter selection criteria. The most simple thing to do is to work with the document number.For document number 21922, that would look as follows:

Table Name = VBAK

Field Name = VBELNIncl/Excl = I Inclusive defined set/arrayOption = EQ Equality (= Low)Low = 0000021922

c) Starting the request download:You start the request download using Transaction R3AR4. Again, SAP recommends that youselect the request name using the input help. The further steps are the same as with theinitial download.

6. Question: How does the delta download work?

Answer:

a) Delta download characteristics:The delta download is started from the R/3 system. It is started whenever a document that is

relevant for the download according to the filter condition (see initial download) iscreated or changed.

b) Flow logic within the R/3 system:As in replies, the data to be sent is determined in FORM routineMV45AF0B_BAPIDATEN_ERMITTELN by means of module SD_SALES_DOCUMENT_PREFETCH. Afterwards,module CRS_SALES_COLLECT_DATA is called. Unlike in replies, the data is then transferreddirectly to module CRS_SALES_SEND_TO_SERVER.

c) Problems when debugging module CRS_SALES_SEND_TO_SERVER:Module CRS_SALES_SEND_TO_SERVER is usually called 'In Update Task'. However, because the'Update Task' cannot be debugged, you have the option here of setting a breakpoint on theline 'IF gv_send_together IS INITIAL.' just above the call of CRS_SALES_SEND_TO_SERVER inmodule CRS_SALES_COLLECT_DATA and setting local variable LV_IN_UPDATE_TASK to 'SPACE'. Youcan now debug to module CRS_SALES_SEND_TO_SERVER directly. This module calls moduleCRS_SEND_TO_SERVER.

d) Further process of delta download:The further process is exactly as described for the reply (under Question 3).

7. Question: How does the reply to CRM work with a delivery / rush order / billing document?

Answer:

a) Delivery:Before saving the delivery, switch on the debugger by entering /h.Then set a breakpoint in subroutine SAPMV50A / SD_MOB_CLIENT_UPDATE. Set variable V50AGL-SYNCHRON to 'X'. (FORM routine SD_MOB_CLIENT_UPDATE is contained in IncludeFV50XF0B_BELEG_SICHERN.) Then debug module SD_CRM_ORDERDATA_FROM_DLV_INV. The statuses aredetermined here. The remaining process is as described for the delta download (Question 4).

b) Rush order:The rush order is a special case in which module SD_CRM_RUSHORDER_DATA_READ is called inroutine MV45AF0B_BAPIDATEN_ERMITTELN directly from the sales order. The remaining process isalso as described for the delta download (Question 4).

c) Billing document:Before saving the billing document, switch on the debugger by entering /h. Then set abreakpoint in subroutine SAPLV60A / CRM_UPDATE. Set variable LV_SYNCHRON to 'X' here. (FORMroutine CRM_UPDATE" is contained in Include LV60AD26.) Afterwards, also debug moduleSD_CRM_ORDERDATA_FROM_DLV_INV. For the remaining process, see the delta download (Question4).

d) Cumulative quantities and document flow:In CRM, structure CUMULATED_I is interesting both for the delivery and for the billingdocument because the quantities are updated here, in addition the document flow is updatedin table DOC_FLOW.

Validity

Software Component From Rel. To Rel. And Subsequent

BBPCRM 300 300

310 310

400 400

7/17/2019 0000656823


References

This document refers to:

SAP Notes

This document is referenced by:

SAP Notes (2)

683342 Prerequisites for editing transfer problems

683342 Prerequisites for editing transfer problems

1912380 Dummy documents in CRM history

0000656823

Documents