This is the start of another series on this blog: A complete introduction to IDocs in SAP. We start in this post by explaining the IDoc basics and the usage of IDocs in SAP ERP environments.
This bundle contains Amazon Fire TV Stick Lite and Mission USB Power Cable. The USB power cable eliminates the need to find an AC outlet near your TV by powering Amazon Fire TV directly from your TV's USB port. Includes special power management circuitry that enhances the peak power capability of the USB port by storing excess energy and then releasing it as needed.
Check it out on amazon.com →This definition for SAP IDocs should cover all use cases. And by the way, the correct capitalization is IDoc - not IDOC or Idoc.
IDocs are used to exchange data between two places that need it. Both systems must be able to understand the semantics and syntax of the IDoc. You can think of IDocs simply as a standardized interface format, just like a REST API response that is consumed by a frontend. IDocs are created when an outbound ALE or EDI Process is executed.
IDocs are identified by an IDoc ID or Number that is unique within a client. This is important - the IDoc number on one system does not uniquely identify the same IDoc on another system! Some other important facts about IDocs:
Idocs come in two flavors. Traditionally, they are a fixed length format (1000 bytes), but in newer releases there is also an XML based format available. This has the advantage of being more flexible in use, being based on the W3C XML standard. Using SAP transaction WE60, the documentation for all IDocs can be seen.
Example Structure of an SAP IDoc
In SAP systems, IDocs always consist of the following three parts.
This structure can be seen in SAP systems as well of course, using transactions WE02 or WE05.
Structure of the same IDoc, seen in SAP transaction WE02 (Display IDoc)
An IDoc type defines what kind of data is contained in the IDoc. You can imagine an IDoc as an instance of an IDoc type, just like an object is an instance of a class in object-oriented programming. The IDoc type controls, among other things:
IDoc types can be defined using SAP transaction WE30 (IDoc Type Development).
Let's check out some more detailed information about the records present in each IDoc.
Control records are stored in the table EDIDC with the IDoc number as the primary key. Some of the most important information stored in the IDoc control record is:
The data record contains application data - such as invoice, order or delivery data. The data records for each IDoc are stored in SAP Tables EDID2, EDID3 and EDID4. The actual payload is stored as a plain text string in the field SDATA, which is a 1000 char long field (hence the fixed-length for IDocs). Data records are further structured into segments. Segments are reusable data structures that define the format of data records in IDocs. For each segment, there is a segment type, a segment definition, and segment documentation that can be viewed with transaction WE31. The last three characters in a segment name are the version that is incremented with each change in a new SAP ERP release.
In every step in the IDoc processing, a status reord is attached to an IDoc. This happens both when the processing was successful as well as if an error occurs. Status records are stored in table EDIDS. The statuses 1-42 are for outbound processing, whereas statuses 50-75 apply for inbound processing.
IDocs are stored in the database, just like any other SAP object. These are the relevant tables for IDocs in SAP:
Like (almost) everything in SAP ERP, IDocs can be extended. The instrument for this are extension segments. For every IDoc type, you can not modify the basic structure of the segments as this would break the standards which IDocs are based on and therefore compatibility with other systems. But what you can do is add extension segments, adding custom data to the end of the IDoc.
I will do another blogpost describing how to do this in more detail.
Each IDoc type has a very detailed documentation that can be viewed directly in SAP ERP, using transaction WE60. An example:
To understand the context IDocs operate in, it is useful to have a couple terms explained before we take a closer look at actually working with IDocs.
Message Types represent specific types of business documents in EDI - such as orders, order confirmations, invoices. IDoc Types can be mapped to Message Types in a many-to-many relationship using transaction WE81.
Since IDocs can be used for multiple message types, they often contain more fields than necessary for a particular message. Therefore, IDoc views can be used to create projections of IDoc types that use only some of the IDoc type's available segments. They apply only to outbound processing, as in inbound processing this overhead is not problematic. IDoc views can be maintained using transaction WE32.
Partner Profiles in the context of EDI/ALE/IDoc are business partners with which an SAP system can exchange documents. Using transaction WE20, you can maintain the parameters necessary for the data exchange.
Ports are the place where the technical properties of a connection between an SAP system and a connected system ("subsystem") are maintained. They define what happens with IDocs after they are sent. Some of the most common ports are the HTTP port for direct IDoc exchange in XML format, the File port used by EDI or the TRFC port used by ALE.
The file port is great for debugging, as it will dump the created IDoc in a file within a file system. It is also the most basic way to build interfaces reading data from SAP, since pretty much every other system can be configured to read files in certain formats.
Here's a high-level example of the steps involved in processing an IDoc. Let's assume we want to send a purchase order to a vendor connected to us via EDI. Let's assume the vendor has SAP ERP as well.
Sending data out of your own SAP system is called Outbound Processing, and receiving data from other systems is called Inbound Processing. SAP developers or consultants are frequently tasked to set up these communication routes. Here are the steps required:
These are the high-level steps needed to setup outbound IDoc processing.
These are the high-level steps needed to setup inbound IDoc processing.
This helpful list contains a selection of IDoc transactions that are useful when developing or working with IDocs.
Happy IDoc development!!