You may find so many resources in the Internet if you search for SAP IDOC’s. But for a Functional consultants certainly need IDoc concepts along with the business processes in SAP. This blog-post will only covers basic knowledge of IDoc and it’s use in a regular day business processes in view of a Functional consultants everyday’s work.
I saw clients using IDoc’s for two purposes. A) Communicate to partners about their business/shipping details through IDoc. B) Communication between Legacy and SAP systems through IDoc.
IDoc refers to a document that is stored in an SAP database table for the purpose of further processing.
Most business operations (Warehouses) are having Legacy systems which will not completely replaced by SAP but should have a communication method between both systems. In that scenarios SAP uses it’s own standard to standardize this communication with the subsystems, through Intermediate document (IDoc) Interface.
Outbound IDoc Outputs-
Indirect Way via Output control
SAP application(delivery processing)—->Document—>NAST output processing—>NAST entry—>IDoc Interface—>IDoc–> External successor System.
Direct Way from the application to the system
SAP application(delivery processing)—->IDoc—>IDoc Interface—>IDoc–> External successor System.
Inbound IDoc Outputs-
Indirect Way via SAP business Workflow
SAP application(delivery processing)<—-Document<—Workflow<—-IDoc<—IDoc Interface<—IDoc<— External successor System.
Direct Way via Functional Modules into the document
SAP application(delivery processing)<—-Document<—IDoc Interface<—IDoc<— External successor System.
Structure of an IDoc
The SAP system has standardized this document and also given specific task. The task is refered as IDoc type, reporting a shipment to the forwarding agent, for example IDoc type SHPMNT. Once the forwarding agent has accepted the shipment order, he can confirms this using the IDoc type SHPCON.
Segments in the IDoc
As Indicated, IDoc have a specific structure. Related data such as data on address, packing, and dangerous goods, is grouped in the IDoc itself. These groups of related data are called segments. These segments have specific name segment type. They have fixed order with in an Idoc type and can be nested. The same segment can occur multiple times; ecample, the segment type “Packing data” could have multiple sub ordinate segment types called “ Packaging data per handling unit”.
In order to view an IDoc type use Tcode WE30
To view structure of individual segments use Tcode WE31
How is this IDoc type processed? The first thing we need to do is create a parnet profile for our EDI and IDoc partners to specify a process code. This can be done through TCode WE20. On the message control tab, link the output type to the process code for each individual IDoc type that we are using.
There are four types of partner profiles: KU for Customer, LI for Vendor, B for Bank, and LS for Logical System. KU, LI, and B are used for EDI partners, while LS is used for ALE communications.
To view error IDoc report use Tcode WE05
To search for field content when you don’t know the IDoc number with Tcode : WE46
To view and search IDoc’s Tcode : WE02 or WE09
To modify segment content through Tcode WE19
How to check the status of IDOC? through WE05
In the Outbound- Status
03, 12, 38 – IDoc successfully transferred
02, 04, 05, 25,26, 29 - Processing error
In the Inbound -Status
53 – IDoc successfully updated
64- Waiting status (still processing…)
63,65- Inbound error
Some useful external resources: