IDOC PROCESSING
1. Definition.
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 nding 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 u the area menu via transaction WEDI.
2. Terms.
Some special concepts to take into account:
2.1. Outbound processing: In outbound processing, document data is written to the IDoc and nt 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 nding the information or from which system am I receiving the information?
Communication -> How am I nding the data? File, RFC,…
The message type defines the business significance (for example: create a material document; create a purcha order).
In the Inventory Management area, currently, we have two different message types:
∙ WMMBXY: Created by the Warehou Management area to post goods movements from non SAP systems. Meanwhile abud for all kinds of goods movements and therefore in some cas 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 relea 4.5A, the new created BAPI_GOODSMVT_CREATE was ud to generate an IDOC structure. As the BAPI is documented, this IDOC should be recommended to customers when planning a system tup.
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 chon a message type from the Inventory Controlling (MM-IS) area, INVCON, but, of, cour, 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 choo 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. The 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, ...: The are IDOC structures created by our colleagues from SAP-Retail to satisfy special needs (handling of structured material, tied empties, ...). They u their own processing function modules before calling MB_CREATE_GOODS_MOVEMENT. Errors that obviously are not caud by MB_CREATE_GOODS_MOVEMENT should be nt to component IS-R at first for analysis.
The different IDoc types can be displayed with WE30.
We can e 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 gments. We can have gments for the header data, item data…
The gments can be displayed in WE31 (for example, E1BP2017_GM_ITEM_CREATE).
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 gments.
2.7. Partner numbers: the reprent the nder and the receiver of the IDoc.
The documentation can be en in WE60 per basic type (IDoc type) or gment.
3. Prerequisites to create and post an IDOC.
Besides the message type, an IDOC contains information about the nder and the receiver. The are reprented in form of partner numbers which control what to do with the IDOC when it arrives.
