SAP IDoc
Also: IDoc · Intermediate Document · ALE · IDoc interface
An IDoc (Intermediate Document) is the format in which SAP systems exchange business data with other systems. It carries orders, deliveries or invoices, for example, into and out of an SAP system in structured form.
What it is
IDoc stands for "Intermediate Document". An IDoc typically consists of three parts: a header or control record holding sender, recipient and message type; the data records themselves in hierarchically structured segments; and status records documenting the state of processing.
Two terms matter when agreeing an interface. The basic type describes the structure — which segments and fields exist — for example ORDERS05 or INVOIC02. The message type describes the business meaning, such as ORDERS for purchase orders or INVOIC for invoices. Customer-specific fields are added through extensions.
IDoc is SAP’s own format, but it is not confined to SAP systems. Between SAP systems it is transmitted using SAP\'s own mechanisms; with external systems and trading partners it is exchanged just as readily, as a file, over RFC or as IDoc XML, depending on what was agreed. In classic EDI the route often runs through middleware or a converter that turns the IDoc into EDIFACT, XML or another agreed partner format — but that step is not a requirement.
The partner profiles in the SAP system define which partner receives which message type over which outbound or inbound route.
In practice
When troubleshooting IDocs it pays to separate two levels: was the IDoc transmitted technically, and was it processed on its merits? The status values of an IDoc show where a transaction stands. A frequent case is an IDoc that arrived without technical fault but fails at posting because master data is missing or a match cannot be made.
Typical causes are missing or incomplete partner profiles, unmaintained customer, supplier or material master data, mandatory segments left empty, and diverging number ranges and references.
For mid-sized companies without SAP of their own, one constellation matters above all: the trading partner runs SAP, and the EDIFACT messages exchanged are generated from IDocs. Peculiarities in field population are then often a consequence of the underlying basic type. Our job in those cases is the translation between the partner\'s requirements and the fields of your own system.
When it affects you
IDoc concerns you in two situations. Either you run SAP yourself and want to connect upstream systems, portals or partners. Or your trading partner runs SAP and derives their data-handover requirements from it.
Three details help with a dependable assessment: the required message and basic type, a description of the expected field population, and one real sample IDoc or a message generated from it. Together they separate what is pure mapping work from where business rules or master data have to be added.