The term IDoc comes from “Intermediate Document”. It is the SAP word for EDI
(Electronic Data Interchange) and defines the data transfer (data interchange) between different systems.
It allows us to generate or to receive a standard SAP format with business information. This is, it allows us to build a standard SAP Material Document with data from the business process as material, plant, movement type, etc.
The IDoc Interface consists of the definition of a data structure and a processing logic for this data.
The data structure is the IDoc. It is the exchange format that unites the communicating systems (the sending system must be able to build this data and the receiving system must be able to “understand” and process this data).
To access to the IDocs – related transactions it can be more convenient to use the area menu via transaction WEDI.
Some special concepts to take into account:
2.1. Outbound processing: In outbound processing, document data is written to the IDoc and sent to the receiving system from our SAP System.
2.2. Inbound processing: In inbound processing, IDocs are transferred to our SAP System from a different system.
2.3. Message type: Identifies the action to be done by the ALE-layer.
The ALE-layer is the “Application Link Enabling” layer and it has three levels:
Application -> What am I transferring? Application data, master data,…
Distribution -> To which system am I sending the information or from which system am I receiving the information?
Communication -> How am I sending the data? File, RFC,…
The message type defines the business significance (for example: create a material document; create a purchase order).
In the Inventory Management area, currently, we have two different message types:
； WMMBXY: Created by the Warehouse Management area 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.
The different message types can be displayed with the transaction WE81. (Note: Within the standard MM-IM area there is not any IDoc for outbound processing. The two standard message types WMMBXY and MBGMCR are only for inbound processing. Some customers who desire to have IDocs for outbound processing in the MM-IM area have chosen a message type from the Inventory Controlling (MM-IS) area, INVCON, but, of, course, they do not handle exactly the same information).
2.4. IDoc type: Once we have defined the business significance with the message type, we must choose a basic type or IDoc type which will tell us the exact structure of the Idoc we must complete with data.
The IDoc types are, therefore, the carrier of the application data.
； 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_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 sent to component IS-R at first for
The different IDoc types can be displayed with WE30.
We can see the assignment of an IDoc type to a Message type in WE82.
2.5. Segments: The data we must complete in the IDoc is divided by segments. We can have segments for the header data, item data…
The segments can be displayed in WE31 (for example,
2.6. Extensions: When customer defines his own data and he wants to transfer it using IDocs, then he has to enter this data in this specific segments.
2.7. Partner numbers: these represent the sender and the receiver of the IDoc.
The documentation can be seen in WE60 per basic type (IDoc type) or segment.
3. Prerequisites to create and post an IDOC.
Besides 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 our internal test systems we will normally use a partner type LS (Logical System). For the message type WMMBXY, the partner number WM_SUB_001 works.
In transaction WE20 first check that the partner you have chosen is active (status A under the Classification tab; first section).
In the section Inbound parameters, you can see the possible message types that we will receive from this partner.
If necessary, add the message types 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”.
The final assignment between the message type and the application object can be seen with WE57. (Note: Here the “position” button does not return any result; in order to select an entry go to the menu path „Selection criteria‟ -> „By contents…‟ and work from
4. View and Edit IDocs.
To view an IDoc with a given number, use transaction WE02.
The Date created field will always be defaulted with the current date, so it will need to be deleted if the IDoc to be selected has not been created today.
From the resulting list, you can branch into the single IDoc display (if only one IDoc is selected, this will be done automatically).
There are three types of records:
The Control Record which contains the organizational data (message type, basic type, partner data,…)
The data records, which contain the structures with the application data to be posted. In Inventory Management IDocs, there is header data and item data.
The status records, which give 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).
All the different status can be displayed with transaction WE47.
The statuses for outbound IDocs are between '01' and '49', while the statuses for inbound IDocs start from '50'.
By double clicking a data segment, you see the data in the proper fields. You can modify the data in a segment by using WE19.
If you do not know the IDoc number, you can use transaction WE05 to search IDocs by message type.
5. How to create an IDOC.
5.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 (the system in which you are working) should become filled. As partner number of the sender, enter the partner number from chapter 3 (WM_SUB_001) 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 in WE19. 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
5.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/02) 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 (EDIDC), you have to fill at least these data: ； Recipient port: SAP+
； Recipient partner number: Our logical system, the one in which we are currently
working and the one in which the material document will be posted. For example:
U9CCLNT800 when working in U9C client 800.
； Recipient partner type: LS (for logical system).
； Sender partner port: Use F4 and choose any entry. It is important that the field is
filled, but not the value.
； Sender partner number: as chosen in 3 (WM_SUB_001) or try another one which in
WE20 has the message type MBGMCR assigned as inbound parameter
； Sender partner type: LS.
； 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. This is done by the icons copy and paste. When pasting, paste at the same level to create a new item. (Note: check table T158G for the Goods Movement Code; Account Data fields need to be completed with leading zeroes).
Press Standard inbound.
If there are errors in the partners and ports definitions they will be displayed now. The idoc is transferred to the application.
6. Posting an IDOC.
Transaction BD87 initiates the application processing of IDocs.
It is necessary to start this transaction and process the IDoc manually when in WE20 the message type has been set to be processed as “Trigger by background program”. In this case the IDoc remains in status 64 till it is finally processed manually. When the processing of the message is set to “Trigger immediately” the application document is posted (material document is created) and the status is set to 53.
First of all, you specify which types of IDocs you want to post. In the following selection screen, specify the number or numbers of the 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.
6.1. Processing WMMBXY:
This message type is processed by the function module L_IDOC_INPUT_WMMBXY. Its task are:
； Convert the unstructured data from the IDOC into the correct DDIC-structures
； 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. 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".
6.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).
7. Usual problems with IDOCs.
7.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.
7.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.
7.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
7.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.
8. Tips and Tricks.
8.1. IDOCs Made Easy:
In most IDOC messages, the description about how the document is posted is quite frightening. However, in most cases, the symptom is not only appearing when the IDOC is used but also when much easier methods are used. To make it easier and to enable debugging (checking interfaces!), the following methods are usually successful:
; Have a look at the data of the IDOC in WE02. Do you expect an online transaction to post
the document when exactly those fields are filled? If it wasn't obvious, use the online
documentation of BAPI_GOODSMVT_CREATE to find out which fields have to be filled
; IDOC MBGMCR is calling BAPI_GOODSMVT_CREATE. Use SE37, press button
'Single Test' (F8) and enter the data you can see in WE02. Execute the program and look
what's happening. If it was the same, the issue can at least be reduced to a BAPI issue,
which is much easier to analyze.
; If the same was happening in the BAPI, the next step is to check the same in MIGO or
MBxx to see if it was a general issue.
; If the result of the previous steps was that that the symptom is really appearing for an
IDOC only, there are two chances for an easy solution remaining: You could do a code
review in the customer exits in function group LMDE or tell the customer to check the
RFC settings (480089 and related notes).
; If all this didn't help, it was really an IDOC issue. Further information about this can be
found in SAPNet (Info-Pool).
8.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,
； Select SWW_CONTOB with the found WI_ID (workitem ID).
； In the line with ELEMENT = INBOUND_IDOC, you can find the IDOC number in
8.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).
8.4. 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.