IDOC processing in MM-IM

Last modification: 15.11.2000 (jkr)

1 Introduction
An IDOC is a means for electronic interchange of business process data between systems. It can be created by a system and sent via direct communications lines or file exchange to a target system. There it may trigger an event causing a creation of a document (e.g. material document).

2 Application in Inventory Management

IDOCs creating material documents generally make use of the function module MB_CREATE_GOODS_MOVEMENT. An incoming IDOC belongs to a message type, which identifies the action to be done by the ALE-layer. Currently, we know these message types: WMMBXY: Created by our colleagues from Warehouse Management to post goods movements from non SAP systems. Meanwhile abused for all kinds of goods movements and therefore in some cases not able to satisfy the customers needs. The interface structure originally was quite narrow and has been altered a couple of times. MBGMCR: As of release 4.5A, the new created BAPI_GOODSMVT_CREATE was used to generate an IDOC structure. As the BAPI is documented, this IDOC should be recommended to customers when planning a system setup.

Each message type can be used to process IDOC structures. These can be viewed in transaction WE30 and are the carrier of the application data. Prominent structures are: WMMBID01, WMMBID02,...: IDOCs of message type WMMBXY. The number specifies the version. These contain the DDIC-structures E1MBXYH (header) and E1MBXYI (item), additionally E1MBXYJ (additional item data as subnode). MBGMCR01: Message type MBGMCR with the structures E1BP2017_GM_HEAD_01, E1BP2017_GM_CODE, E1BP2017_GM_ITEM_CREATE and E1BP2017_GM_SERIALNUMBER. WPUBON01, WPUWBW01, ...: These are IDOC structures created by our colleagues from SAP-Retail to satisfy special needs (handling of structured material, tied empties, ...). They use their own processing function modules before calling MB_CREATE_GOODS_MOVEMENT. Errors that obviously are not caused by MB_CREATE_GOODS_MOVEMENT should be send to component IS-R at first for analysis.

3 Documentation in the R/3 library

A detailed documentation for the message type WMMBXY can be found in the R/3 library in the section from Logistics Execution/Warehouse Management/External Interfaces/MM-MM-MOB Interface .

4 Prerequisites to create and post an IDOC

Despite of the message type, an IDOC contains information about the sender and the receiver. These are represented in form of partner numbers which control what to do with the IDOC when it arrives. In SAPsystems usually a partner number WM_SUB_001 (logical system) is available. If not, any other logical system as partner will do. In transaction WE20, you should check that the partner you have chosen is active (status A). In the section Inbound parameters, you can see the possible message types receivable from this partner. If necessary, append WMMBXY or MBGMCR to the list. In the detail view of the message type, you have to specify a Process code. The process code controls the execution of the posting from application side. The correct setting for WMMBXY is code WMMB and for MBGMCR it is BAPI. The flags Syntax check and Trigger by background program should be set. The background trigger enables processing the IDOC via manual start with debugging possibility.

Transaction WE42 assigns the process codes to the function modules which are called to process the IDOC. For WMMB, the function module L_IDOC_INPUT_WMMBXY is entered, for BAPI is it BAPI_IDOC_INPUT1. Further settings are Process with ALE and Process by function module.

5 View and edit IDOCs

To view an IDOC with a given number, use transaction WE02. The prefilled Date created has to be deleted to select IDOCs not created today. From the resulting list, you can branch into the single IDOC display (if only one IDOC selected, done automatically). Here you can see the Control Record which contains the organizational data, the data records and the status records. The data records contain the structures containing the application data to be posted. For our IDOCs, you will find header data and item data. The status area gives a chronological view of the IDOC history. Possible status numbers are: 64 (ready to be posted), 51 (tried to post but resulted in application error), 53 (document successfully posted), 56 (IDOC faulty), 69 (IDOC was edited) and 70 (original of an edited IDOC). By double clicking a data segment, you see the data in the proper fields. By the menu function Data record/Change is it possible to open all fields for input to edit the existing IDOC. When saving, the changed data still reside in the original IDOC which is assigned a new status 69 and the original data are copied to a new IDOC with status 70. If you do not know the IDOC number, you can use transaction WE05 to search IDOCs by message type.

6 How to create an IDOC

6.1 From an existing material document
To copy the data from an existing material document into an IDOC of type WMMBXY and create it, use the report RLMBXY00. In the selection screen, fill in the material document number and year and press enter. Now the logical system name of your client should become filled. As partner number of the sender, enter the partner number from chapter 4 and mark task in background. The report creates the IDOC and sends it to the ALE input layer. In transaction WE05, you should be able to locate the IDOC looking for message type WMMBXY in status 64 (ready). You can modify the data if necessary be editing the IDOC data segments as described above. In most cases this is necessary as the report fills all available fields from the material document (e.g. DMBTR, BSTMG, MENGE). In normal IDOCs, these data are usually not filled but calculated by MB_CREATE_GOODS_MOVEMENT.

6.2

Manual creation

Transaction WE19 allows to create an IDOC as a copy of another IDOC or from scratch. Here you have to specify the BasicType (WMMBID01/02, MBGMCR01) or the message type (WMMBXY, MBGMCR). The tool shows you the control record and the initial data segments which you can edit and fill with data. In the control record, you have to fill at least these data: Recipient partner number: Your logical system, e.g. P99CLNT000 when working in P99 client 000. Recipient partner type: LS (for logical system). Recipient port: SAP+<name of your system>, e.g. SAPU4B. Sender partner number: as chosen in 4. Sender partner type: LS. Sender partner port: Use F4 and choose any entry. Important is only that the field is filled. Message: WMMBXY or MBGMCR, depending on your IDOC type.

The data records have to be filled with your application data. It is possible to append new lines if you want to post more than one item with the IDOC. By pressing Test inbound processing, you will receive a dialog box asking where to send the IDOC to. Choose Standard IDOC input and confirm. An info box will present the number of the IDOC created.

7 Posting an IDOC
Transaction BD87 initiates the application processing of IDOCs. First of all, you specify which types of IDOCs you want to post. In the following selection screen, specify the number or numbers of your IDOCs you want to post. When executing, the ALE layer analyses the sender information and finds out what to do with the IDOC. Depending on the message type, a function module is called which handles the application data.

7.1

Processing WMMBXY
Convert the unstructured data from the IDOC into the correct DDIC-structures (FORM wmmbid01_segment_uebernehmen). Call a User-Exit to manipulate the data. This one is used e.g. to set the flag XRERE or other data that are not present in the IDOC communication structure. Call MB_CREATE_GOODS_MOVEMENT. Call another User-Exit. Extract error information and hand them over to the ALE status controller.

This message type is processed by the function module L_IDOC_INPUT_WMMBXY. Its task are:

The COMMIT WORK always occurs in the ALE layer. ROLLBACK WORK is triggered within this function module if MB_CREATE returns errors. The customer exits can be found in the SAP-enhancements MWMIDO07 and MWMIDO08 together with their documentation. Problems with this function module (see note list) have been handled by our colleagues from WM who are responsible for the code. The function module is not "mass data capable".

7.2

Processing MBGMCR

The function modules operating with this message type have been generated by the transaction BDBG which is maintained by component BC-MID-ALE (programmer: Eryi Zhang). The function modules reside in the function group MB_BUS2017. The most important one is IDOC_INPUT_MBGMCR which is the caller of BAPI_GOODSMVT_CREATE. It moves the raw IDOC data to the DDIC-structures and handles the error messages issued by the BAPI. The BAPI itself calls a couple of function modules generated by transaction BDBS which map an internal structure as IMSEG to an external structure as GOODSMVT_ITEM. This mapping includes: Field names (MATERIAL --> MATNR). Unit fields (ISO-code --> SAP internal representation, e.g. EA --> ST). SAP specials (e.g. NPLNR/VORNR --> APLZL/AUFPL).

8 Usual problems with IDOCs

8.1 Incomplete refresh
Most errors in the posting of IDOCs result in the fact that the function module MB_CREATE_GOODS_MOVEMENT is called several times within a single internal mode. The implicit refresh in the dialog transaction, caused by LEAVE TO TRANSACTION ... does not occur here, so all internal data have to be cleared explicitly. Sometimes, the error is not in our function module, but in external applications. A prominent example are the modules from purchasing. A couple of errors were caused because their internal buffers have not been refreshed between the calls, resulting in wrong data delivered with the second and more calls.

Therefore, if the error description indicates that the error does not occur if single IDOCs are processed, try to set up an example where two or more IDOCs will be posted in a row. This can be simulated by BD87 when entering more than one IDOC number.

8.2

Incompletely filled IDOC structure

As already mentioned, WMMBXY is used for more movements than it was originally designed for. So the documentation to the customer is not concise with respect to the fields that have to be filled to obtain the desired result. You should check that the call to MB_CREATE is complete in the sense that we have all necessary data. A prominent example for "missing functionality" is the flag XRERE (read reservation), which is not contained in the IDOC structure. If the user wants to read the data from a reservation, the flag has to be set in the user exit explicitly.

8.3

Incorrectly filled IDOC structure

The data in the IDOC are untyped, meaning that an external application has no clue about R/3 data types as DATS and NUMC. This leads to errors if an external application fills the IDOC obviously correct from an external point of view, but faulty as soon as the data are casted into a DDIC structure. If for example an external application fills the field EXPIRYDATE of MBGMCR01 with a sensible initial value of <space> to indicate that no expirydate is given, this is moved to IMSEG-VFDAT, which is of data type DATS. The initial value for this field is 00000000, but <space> is accepted and does not create a conversion error. Every time we check for IMSEG-VFDAT IS INITIAL, this condition is false, as <space> is not the correct initial value. If we start performing arithmetical operations on this field, the result might be a short dump.

8.4

Timing and locking problems

It is possible for the ALE layer to distribute incoming IDOCs to parallel workprocesses for execution. This will cause locking errors if the same objetcs (purchase orders, production orders, ...) are to be posted. Another problem arises if the IDOCs are not sent in the proper timing order. Stock transfers for example will only be successful if the goods issue is posted before the goods receipt. There are possibilities to serialize the IDOC processing within the ALE layer. Problems of this kind should be routed to BC-MID-ALE for further investigation, as the sequence in which we are called is not in our hands.

9 Tips and Tricks

9.1 Equivalence of IDOC and direct function module call
The call to the function modules MB_CREATE_GOODS_MOVEMENT or BAPI_GOODSMVT_CREATE by IDOC is equivalent to calling these modules directly from an ABAP report. All effects that may arise during IDOC processing, especially refresh-problems, can be seen by a direct call, too. This makes debugging an error situation much easier, as none of the IDOC specific transactions is necessary to trigger the processing.

9.2

Finding the IDOC for a material document

In some cases (depending on the set up of SAP-workflow) it is possible to find out the IDOC which caused a given material document. These are the steps: In SE16 for table SWW_CONTOB, locate the entry with OBJTYPE = BUS2017, OBJKEY = <material document number> (with leading zeros). Select SWW_CONTOB with the found WI_ID (workitem ID). In the line with ELEMENT = INBOUND_IDOC, you can find the IDOC number in the OBJKEY.

9.3

Debugging with IDOCs

Set a breakpoint in L_IDOC_INPUT_WMMBXY or BAPI_GOODSMVT_CREATE. When posting the IDOC with BD87, you will reach the breakpoint and have access to the importing data of our modules. Check them for correctness. Execute our module. Are the return tables correctly filled? After you have edited an IDOC, it has status 69. Unfortunately, the selection screen of BD87 does not allow to enter more than a single IDOC number for this status, so it is not possible to simulate the refresh problem. Solution: Modify the status of the IDOC in table EDIDC by the proper means and change it to 51. To repost an IDOC that has already been posted, you have to modify the status history in table EDIDS to convince the system that it is allowed to post the IDOC. To check the error handling of the IDOC processor, execute the call to us and move a proper return code into our return structure to indicate an error (e.g. EMKPF-SUBRC > 5 for WMMBXY, Release 4.0A).

10 Sending an IDOC
The documentation of SAP-enhancement MB_CF001 (customer exit in MB_POST_DOCUMENT) contains a description of the function modules necessary to send an IDOC from within ABAP-code.

11 Test data
As IDOCs are deleted regularly, it is not useful to give examples of IDOC numbers here.