You are on page 1of 9

Error "Document is being distributed, changes are not possible.

" is issued on changing a sales


document.
The error is issued because system status I1054 is activated in the order. System status I1054 is set when the data
exchange is started. It is deactivated when the data exchange is successfully completed. When there is the error,
please check:
T-cd: SMW01 IIs the BDoc successfully processed?
T-cd: SMQ2/SMQ1 Is there any inbound/outbound queue failed in CRM/ECC system?
T-cd: ST22 Is there any short dump in CRM/ECC system?
If there is no queue/BDoc error, try to unlock the order with the report CRM_CHECK_DISTRIBUTION_STATUS.
Error "Inconsistent update flags" is returned to the sales document
The document was replicated into ECC system, but during the processing of the response a problem occurred. As a
consequence, the replication record and/or the Distributed' status is missing in the CRM document. It can be
corrected by executing the reports in SAP Note 1056966.


Problem: you cannot modify document in CRM. System says it is locked to to distribution. This
situation persists for a longer time.
Solution: what has probably happened is that the replication process has failed at some point
and system hasnt been able to unblock the document. You can unblock it yourself in
transaction SMQ2.
However, if this does not help there is a report
called CRM_CHECK_DISTRIBUTION_STATUS which will allow you to list all documents
currently blocked. It will also allow you to unblock all documents that are blocked but not being
used.


Debug queue
Goto the Tcode SMQS.. select the RFC destination of the CRM System deregister it (Check it & click the
Deregister button in the tool bar)..

Now Sync.. the Material Master.. The documents will sit the Q's... goto SMQ1 select the Queue name
Double Click 2 times.. then select the Tool bar (Debug LUW)..

1) Deregister the Queue in CRM - tcode SMQR. The queue usually starts with R3AD*
2) Make the change in ECC
3) In SMQ2, you should now see a waiting transaction under the Queue name you Deregistered
4) Execute the LUW, in debug mode - this should start executing the FM-BAPI_CRM_SAVE
SAP - Debugging middleware - OSS Note 847964
Just for my note and quick reference :)

UPDATE: Quick note on ABAP to recreate BDOCis
called CRM_START_REQUEST_FROM_CRM.
FM: CRM_SRV_R3_LOGISTIC_UPLOAD is called to update PREQ etc.

Symptom

You want to debug the data exchange between CRM and R3 for service documents.

Reason and Prerequisites

Data is sent to the R3 system via the CRM Middleware. The data is sent asynchronously

Solution

Before you save the service document, enter /h and set a breakpoint in
the function module CRM_UPLOAD_BTMBDOC_START_FLOW
Go into the first method, CALL METHOD cl_smw_mflow=>process_outbound (line 33), and
set ls_header-dbg_mode to X (line 37). With F8, you'll return to the service order.
Now click on the Doc_flow. You'll see an outbund BDOC with the date BUS_TRANS_MSG
and D01.
(If you can't see the BDOC, set the user parameter CRM_USER_LEVEL to 9 in your user
parameters).
Double click the BDOC.

Enter /h and set a breakpoint at one of the following function modules:
CRM_R3_ACCOUNTING_UPLOAD passes Controlling information for service contracts
and service orders
CRM_R3_SERVICECONF_UPLOAD passes Controlling information for service
confirmations
CRM_R3_SRV_RESERVATION_UPLOAD is called for material reservations
CRM_R3_SALESDOCUMENT_UPLOAD is called for sales relevant information (for
example, if you have sales items in a service document)
CRM_R3_SERVICE_BILLING_UPLOAD for billing of service orders in R3 (only available
with the SIE add-on).
Reprocess the BDOC.
Set a breakpoint at the line IF lv_synchronous_call IS INITIAL or IF gv_synchronous_call IS
INITIAL. F8 brings you to this breakpoint.
Set lv_synchronous_call/gv_synchronous_call to X and with F5 you'll enter R3 debugging.
Make sure that the RFC user used for communicating between the systems is defined as a
dialog user.

--
CRM_SRV_R3_LOGISTIC_UPLOAD
Y_E_CRM_R3_SRV_MVT_UPLOAD

Middleware debugging sap note 656823

Symptom

This note contains a list of the most frequent problems / questions during the analysis of transfer
problems 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 for internal
use) for customers. However, SAP would like to point out that this note was created on the basis 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 CRM document is transferred normally, you can set field LV_IN_UPDATETASK to
SPACE before method PROCESS_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 found
again 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 SMQR
while 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 the queue,
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. Now display field ls_orderadm_h-object_id = <obj.id>. The queue name is then
CSA_ORDER_<obj.id>.
If the '80% method' is not successful, you can find out the name of the queue if you debug into
method call PROCESS_OUTBOUND. Here you have to debug into method
PROCESS_NOTIFICATION for 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
search for the name of the queue. If you cannot find the queue, check in Transaction SMQ2. If
you do 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, then
select the line and choose 'Debug LUW'. Breakpoint on function module
CRM_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-
SUBRC not equal to zero and the document is not transferred to the R/3 system. Thus, if you
do not reach 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 be
avoided 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 take a
closer look at the mapping of the BDoc structures in the BAPI structures. This is done in
function 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 call this module in two different modes: Asynchronous (that is, in the background,
which is disadvantageous for debugging), or synchronous (that is, directly). The second
method is appropriate 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 of BAPI_SALESDOCU_PROXY_UPLOAD).
If you use the synchronous method, you can select setting 'In background task: Do not
process' 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 the RFC user
that is used in the R/3 system is not a dialog user. To check this, SAP recommends that you
search for the user in Transaction SM59 in the corresponding R/3 connection (see below)
('Logon/Security' tab, User). You can check the settings for this user in the R/3 system in
Transaction SU01. On the 'Logon data' tab, 'Dialog' should be set as the user type.
j) Determination of the connected R/3 system:
To determine the user (for example, in Transaction SM59), you have to know the connected
R/3 system. For this purpose, you can display the contents of table SMOF_ERPSH in
Transaction SE16. 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 the
inbound queue of the CRM server. This document should have BDOC type SALESDOCGEN_O_W.
As of Release 3.0, an MSA sales document is also created in CRM. That is, module
CRM_ORDER_MAINTAIN is always called and then module CRM_ORDER_SAVE. Thus, module
CRM_UPLOAD_BTMBDOC_START_FLOW is also called in the further course of processing. The f
urther process is the same as described under Question 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 in
MV45AF0B_BELEG_SICHERN. If a CRM server is connected, this FORM routine determines
the data that is supposed to be returned to the CRM Server. This is done by means of module
SD_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 determined for the reply is transferred in global tables (for example, GT_VBAK in function
module CRS_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
module CRS_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. This
queue name is determined in module CRS_SEND_TO_SERVER for the reply. The actual task
is performed by module CRM_FIRST_CALL_OPERATIONS which is called there. Table
GT_RFCDEST is filled 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 in table T_BAPISTRUCTURES which contains fewer entries if
data has been filtered out.
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 CRM
server you can find the stopped BDoc in the inbound queue (Transaction SMQ2) under the
queue name that was deregistered before. You can start this queue by choosing 'Debug
LUW'. Do not forget 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 module
CRM_SALESDOC_MAP_BAPI2MBDOC. Afterwards, the validation occurs by means of
module CRM_DOWNLOAD_BTMBDOC_VAL. This module calls module
CRM_DOWNLOAD_BTMBDOC which in turn calls module
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 was returned to the CRM server and not only the status was reset. Document processing
is carried out via module CRM_ORDER_MAINTAIN. Finally, the call to save the document is
called from module 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 in
many cases.
b) Maintaining the filter settings:
First of all, the customer has to maintain the filters for object 'Salesdocument' in Transaction
R3AC1. You can reach the filter settings by choosing the filter symbol. Then go to the
'Tables/Structures Within Object' tab. In addition, you must select the corresponding source
site (that is, the R/3 system). Now the filter conditions should be displayed. The filter can be
set according to different criteria, for example according to a document number interval. In this
case, only the documents contained in this interval are sent to the CRM server. It is important
that you fill up the document number to 10 characters with leading zeros.
If you encounter problems with the filter settings, Note 497327 might be of further assistance.
c) Starting the initial download with Transaction R3AS:
If the filter settings are correct, the initial download is started with Transaction R3AS for the
corresponding object.
IMPORTANT! The initial download should only be carried out once for each document
because problems can occur if you start the initial download for documents that already exist
in the CRM 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 because
changes to the documents are automatically sent by delta download from the R/3 system to
the CRM 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 debugger
by using /h.
First, module SMOF_START_DOWNLOAD_OR_REQUEST is called. This module calls
module SMOF0_INIT_DNL_START. In this module the call to the R/3 system is started. The
corresponding 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, the
queue must be deregistered again in Transaction SMQR. You can determine the queue name
if you 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 other hand, you want to debugger synchronously (that is, directly) into
the R/3 system, you have to 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
selected with the help of the filter settings from table VBAK. This is done in module
ORDER_SELECT_NEXT_ID. This module returns table T_OUT_ID_LIST which contains all
documents that were found using the filter settings. If a customer experiences problems that
some documents are not loaded into the CRM server, you can check here whether the
documents are actually 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
with T_OUT_ID_LIST. Afterwards, module CRS_SALES_SEND_TO_SERVER is called as in
the reply (see Point 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 modules CRM_ORDER_MAINTAIN and CRM_ORDER_SAVE. It should be noted
here that the initial download can be a BDoc with more than one sales document.

5. Question: How does the request download work?

Answer:
a) Difference to initial download:
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 already exist in the
CRM server. However, to avoid errors it is always better to delete the document before 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.
SAP recommends that you select the object name via the input help because the remaining
data is then also filled. The sales document object is the 'SALESDOCUMENT'.
Next, you have to create the request details (by double-clicking the 'Request detail' folder to
the left of the tree and choosing 'New entries'). As in the initial download, you can enter
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 = VBELN
Incl/Excl = I Inclusive defined set/array
Option = EQ Equality (= Low)
Low = 0000021922
c) Starting the request download:
You start the request download using Transaction R3AR4. Again, SAP recommends that you
select the request name using the input help. The further steps are the same as with the initial
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) is created or
changed.
b) Flow logic within the R/3 system:
As in replies, the data to be sent is determined in FORM routine
MV45AF0B_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 transferred directly 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 the line 'IF gv_send_together IS INITIAL.' just above the call of
CRS_SALES_SEND_TO_SERVER in module CRS_SALES_COLLECT_DATA and setting
local variable LV_IN_UPDATE_TASK to 'SPACE'. You can now debug to module
CRS_SALES_SEND_TO_SERVER directly. This module calls module
CRS_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
Include FV50XF0B_BELEG_SICHERN.) Then debug module
SD_CRM_ORDERDATA_FROM_DLV_INV. The statuses are determined 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 in routine MV45AF0B_BAPIDATEN_ERMITTELN directly from the sales order. The
remaining process is also 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 a
breakpoint in subroutine SAPLV60A / CRM_UPDATE. Set variable LV_SYNCHRON to 'X'
here. (FORM routine CRM_UPDATE" is contained in Include LV60AD26.) Afterwards, also
debug module SD_CRM_ORDERDATA_FROM_DLV_INV. For the remaining process, see
the delta download (Question 4).
d) Cumulative quantities and document flow:
In CRM, structure CUMULATED_I is interesting both for the delivery and for the billing
document because the quantities are updated here, in addition the document flow is updated
in table DOC_FLOW.