Showing results for 
Search instead for 
Did you mean: 

How to tarnsfer salesorder from crm to r/3.......

Former Member
0 Kudos


Any body can tell me how to transfer sales oreder from crm to r/3 and vice versa in detail..or send any related document to

Points will be awrded surely for better reply...



Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Venu,

Go to tcode R3AC1 and find business adapter object SALESDOCUMENT.

Inside here, you can define which transaction type need to be transported

between CRM - R/3. Please also remember to Start initial load (tcode R3AS)

for that adapter object.

Please also note that for document CRM need to be transported, you may need to

prepare the same transaction type (order type) and number range in R/3.

Hope this could helps,


Former Member
0 Kudos

Reward points if it helps


Former Member
0 Kudos


Definetly it will help me..

i have given points to u..

Thank u...



Former Member
0 Kudos


I have a similar requirement, but the initial flow context in the adapter object "SALESDOCUMENT" is from source OLTP or R/3 system to CRM as the destination. However, I wanna send the Sales Orders from CRM to R/3. How do I manage that. R3AC1 does not allow me to change the Initial Flow Context of an adapter object



Answers (2)

Answers (2)

Former Member
0 Kudos

You need to turn on the Reciprocal Order scenario. Try these two notes



Former Member
0 Kudos

The data exchange of sales transactions can be dealt better with the note below


the following sales document items are transferred to the R/3 System:

Sales items

Customer return items

Substitute delivery item

Credit memo request items

Debit memo request items

As a leading system for the order entry, CRM only transfers data to the R/3 System if it is relevant for the logistical subsequent processing (delivery, billing). For this reason, requests for quotations and quotations themselves are not transferred to the R/3 back-end system with the standard delivery. With SAP note 455678, you can use a modification solution to also transfer quotations entered in CRM to the R/3 back-end system.

Restrictions of note 455678:

If you are using this solution, you cannot create any sales orders with reference to customer quotations in CRM.

Mixed document processing (partially customer quotation items and partially sales order items) is not supported in the R/3 System and is therefore not possible during the quotation upload. The solution specified here only performs the upload for documents that consist of quotation items only.

The quotation items must be defined in the Customizing for copying. This solution does not cover scenarios where the order is generated from the quotation as a result of a status change. Therefore, quotations entered in SAP Internet Sales (in particular) cannot be transferred to the R/3 System.

Only completion rule 'A' ('Completed with one-time reference') is supported in the R/3 System.

Sales transaction-specific settings for the data exchange

1. Basic administrative settings for the replication of sales transactions

a) The BDoc relevant for the distribution of all transaction types is called BUS_TRANSACTION_MESSAGE. In transaction SMOEAC, the relevant R/3 site must be subscribed to the corresponding publication 'All Business Transactions (MESG)' so that sales documents can be distributed to the R/3 back-end system. (To create a subscription, select the 'Subscription' object type in the 'Object type' selection list in transaction SMOEAC and then select the 'Object -> Create' function from the application menu or the corresponding symbol from the application function bar. The Subscription Wizard, which supports you during the creation of a new subscription, is started as a result.)

b) Check to see whether the current CRM release has been maintained in the R/3 back-end system in the CRMPAROLTP table. This has to be taken into account in particular after an upgrade. You can maintain the CRMPAROLTP table in transaction SM30 in the R/3 back-end system:

Parameter name "CRM_RELEASE"

Param. value "30A"

c) Event 00501014 must be activated in the R/3 back-end system so that the delta download of sales transactions from the R/3 back-end system to CRM works. The event must also be active for the upload of sales transactions from CRM to R/3.

d) The event is activated automatically after a successful initial download. Call transaction R3AC4 ('Object Class Activation') in CRM and check whether the following entries exist:

Object class "BUSPROCESSND"

RFC destination <R/3 destination>

Select your entry and then choose 'Events by Object Class' (branch to the TBE31 table in the R/3 back-end system). The following entries must exist:

Event "00501014"



If you do not see these entries, your initial download was not completed successfully.

e) In transaction BD97 of your CRM system, the R/3 back-end system must have been maintained as the standard BAPI destination. Check the V_TBDLS view to see whether your R/3 back-end system has been defined as a logical system. A termination message in the SAPLCRM_ DISTRIBUTED_LOCKING program when you call a transaction in CRM indicates the missing destination assignment.

Refer to notes 597812 and 674487. According to note 597812, the cross-system lock is processed using the RFC destination of the CRM middleware (SMOF_ERPSH table). However, the aforementioned entry in transaction BD97 for the Standard BAPI destination is still used to branch via the document flow to the R/3 system.

f) In Release 3.1I, you can only have one entry for the RFCDEST field (RFC destination) in the CRMRFCPAR R/3 table.

2. Definition of sales transaction-related Middleware parameters

a) If you do not want a BOM explosion to occur for document items in CRM during the transfer to the R/3 back-end system, make the following settings in transaction R3AC6:



value "X"

This would make sense, for example, if you have already carried out a BOM explosion on the mobile client and if you do not want a new BOM explosion in the R/3 back-end system.

Make sure that the assigned item numbers in the sales transaction/sales document are set differently for main items and subitems so that no item numbers are assigned twice after the transfer and the BOM explosion in the R/3 System. The item numbers of the main items must be set identically in CRM and R/3. For more information, see note 496906.


CRM sales transaction

Pos.Nr. Item No. Product

100 MAT1

200 MAT2

R/3 order

Pos.Nr. Item No. Material

100 MAT1

101 Subitem1

102 Subitem2

103 Subitem3

104 ...

200 MAT2

You can maintain the item number assignment for the transaction types (CRM) or for the sales document types (R/3) in the Customizing.

b) If a document is created in CRM and transferred to the R/3 back-end system, the warning messages of the transferred R/3 back-end document can also be displayed in the CRM document. In this way, you can recognize, for example, in the CRM document whether the transferred R/3 back-end document is incomplete and has to be postprocessed so that it can be further processed logistically. For this purpose, make the following settings in transaction R3AC6:



value "X"

c) When you transfer a CRM document to R/3, you have the following control options with regard to pricing:




'B' = new pricing


'C' = copy manual pricecomponents,

redetermine others


'G' = Copy price components unchanged,

redetermine taxes (this value is

delivered as a default setting)

3. Definition of the R/3 dummy division in CRM

Note that no division exists in CRM in transactions at header level. In the R/3 order, however, the header division is a mandatory field. Thus, the R/3 dummy division must be maintained in CRM Customizing so that it can be determined during the transfer of a document. Otherwise, the order cannot be transferred to the R/3 back-end system.

Customizing path: 'Customer Relationship Management -> Master Data -> Organizational Management -> Division Settings -> Define Use of Division and Dummy Division'.

The use of several dummy divisions can be programmed in the CRM_DATAEXCH_AFTER_BAPI_FILL BAdI in the CRM_R3_SALESDOCUMENT_UPLOAD function module.

Hints for the initial download

Filter settings

In transaction R3AC1, you set the filters for the initial/delta download of business objects. In the SALESDOCUMENT business object, you can set the filters for the order download from R/3 to CRM. For successful execution of the initial download, you have to set at least the VBAK-ERDAT filter criterion (document entry date) for the SALESDOCUMENT business object. This filter setting is required for the successful completion of order downloads.

After you have completed these filter settings, you have to transfer these settings to the R/3 System. Select 'Filter sync.(R/3)'.

Choose your R/3 System as a source site and check whether you are using the VBAK-ERDAT filter criterion:


Table/Structure Field OP Low

VBAK ERDAT Greater than <Date>, for example, 20020128

The date must be entered in the same form as it is stored on the database (YYYYMMDD)!

The following filter criteria are also available:

VBAK-AUART Sales document type


VBAK-VBTYP Sales document category

VBAK-VKORG Sales organization

VBAK-VTWEG Distribution channel

We recommend that you also use sales document numbers (VBAK-VBELN) as a further filter criterion. With this criterion, you can carry out an initial download according to sales document number intervals. The advantage of this filter criterion is that if your initial download terminates due to an error, you can restart the download after correcting the error as of the sales document number for which the error occurred. In this way you avoid having to restart a download for sales documents that have already been replicated.


Table/Structure Field OP Low High

VBAK VBELN zwisch. 0005000000 0005099999

Enter the field contents in the same way as it is stored on the R/3 database (leading zeros).

If you want to use this filter criterion, go to transaction SM30 and make the following entry in the SMOFFILFLD table:

Object name Table/Structure name Field name


Note 497327 deals with possible filter-specific problems during the delta download that can occur due to missing R/3 back-end entries.

Block size

In this context, the block size specifies how many documents are selected in a transaction and transferred to CRM as a BDoc. The block size is defined on the system. The default value may have to be set to a lower value if problems occur (for example, memory overflow during the selection in the R/3 System). If the initial download terminates, check the dump log in the R/3 System (transaction ST22). The TIME_OUT or STORAGE_FREE_FAILED runtime errors indicate that the block size is too large. In this case, reduce the block size and restart the download. In addition, you can clarify with your Basis Administration whether the rdisp/max_wprun_time kernel parameter is large enough (this avoids a TIME_OUT error).

Basically, you should only download a few documents during the first download to check whether the system settings are correct. In this way, you can identify possible Customizing errors and correct them before the large load.

Queue processing during the initial download

In the case of very large transfer data sets, it may make sense to process the initial download in parallel within one object (object-internal parallel initial download) to complete the initial data transfer faster. Note 350176 describes the corresponding procedure.

Queue processing during the upload/delta download

Queues in CRM are defined in the SMOFQFIND table (for example, from CRM to CDB or from CRM to R/3).

For the BUS_TRANS_MSG BDoc type, the default setting of the queue processing is that all orders for a customer are processed in one queue.

As an alternative, you can set the queue processing in such a way that each order is processed in a separate queue. As a result, an individual order can no longer block the processing of other orders if an upload problem has occurred.

If you prefer this queue processing, go to transaction SM30 and make the following change in the SMOFQFIND table:

Select the BUS_TRANS_MSG BDoc type and change the segment field name from QUEUE_NAME to OBJECT_ID.

In the same way, you can also set the queues for the delta download in the R/3 back-end system in such a way that each order is processed in a separate queue. If you prefer this queue processing, go to transaction SE16 in the R/3 back-end system and make the following change in the CRMQNAMES table:

Select the entry for the SALESDOCUMENT object and change the BAPIFLD field from SOLD_TO to DOC_NUMBER (with BAPIOFFSET=3 and BAPIFLDLEN=10). Leave the second entry for the SALESDOCUMENT object (with QOBJPART=SAL_ERR) unchanged.

In transaction SMQR, check to see whether the queues have been registered or check transaction SMQS to see whether the destinations have been registered because otherwise, the queues are not processed automatically, and this can lead to queue overloads.

Check the queues regularly.

Composite SAP Note 504090 covers all notes that solve known problems in the transfer as of Support Package 06 (SP06).

Document cannot be maintained in online mode

If you cannot maintain a document, this can have various reasons. Basically, a sales document entered in CRM is locked until the R/3 System has confirmed the update of the order successfully.

If message CRM_ORDER019 "Document will be distributed - changes are not possible" occurs in CRM, check the queues (transaction SMQ1 and SMQ2). To analyze the data exchange from CRM to R/3, refer to note 431345.

If message CRM_ORDER013 "Transaction &1 is being processed by user &2" occurs in CRM or if message V1042 "Sales document &1 is currently being processed (by user &2)" occurs in R/3, the document is processed in the other system respectively. To avoid inconsistencies, a cross-system lock is set during the processing of a replicated transaction so that the document cannot be processed simultaneously in two systems.

Other notes

Only error-free sales documents are distributed to the R/3 System. If, in R/3, you change a sales document that was originally created in CRM, these changes are not transferred to CRM. That is, you should always make the changes in the original CRM document to ensure the consistency of the document data in both systems. Sales documents entered in the R/3 System are transferred to CRM, but they are locked for processing there. Changes to a document created in R/3 are also transferred to CRM.

In your settings for the data exchange, also make sure that the document number ranges correspond in both systems. For the successful sales document exchange between the systems, the transaction types and item categories have to be created in exactly the same way in both systems. If these objects do not exist in one system, you have to create them manually.

In transaction CRMM_BUPA_MAP, you can determine into which R/3 customer number the CRM business partner is converted and vice versa. If you do not receive a conversion for the specified business partner here, this indicates that a transfer problem has not occurred in the sales document but during the business partner download.