From transaction set to IDoc

Every EDI document has an SAP twin. Learning the pairs is the fastest way to become useful on an SAP EDI project, because the X12 number, the EDIFACT message name and the SAP message type are used interchangeably in meetings, tickets and specifications. Someone says "the 856 for Great Lakes failed" and means the outbound DESADV IDoc built from delivery 80001234.

Message type, basic type, process code

Three SAP terms carry the mapping, and they are easy to mix up:

• Message type: the business meaning, such as ORDERS (purchase order or sales order), ORDRSP (order response), DESADV (despatch advice) or INVOIC (invoice). SAP took most names from EDIFACT. Message types are listed in transaction WE81.
• Basic type (IDoc type): the technical structure and version of segments, such as ORDERS05, DELVRY07 or INVOIC02. One message type can use several basic types; WE82 shows which basic types belong to which message type.
• Process code: the pointer from a partner profile to the program that builds or posts the IDoc, such as ORDE for inbound sales orders or DELV for outbound deliveries. Course sap-edi-201 covers them in detail.

Three details in that table catch people out. First, the order acknowledgment ORDRSP uses the same basic type as the order, ORDERS05: SAP's order IDoc structure serves orders, changes and responses. Second, the forecast is not called DELFOR in SAP: the 830 and EDIFACT DELFOR arrive as SAP message type DELINS with basic type DELFOR01 or DELFOR02, and just-in-time schedules (X12 862, EDIFACT DELJIT) use message type DELJIT. Third, the same message type can go in either direction: Contoso receives ORDERS from Great Lakes and sends ORDERS to Lakeside Components.

What an IDoc looks like

An IDoc has three parts. The control record holds the envelope: IDoc number, direction (1 outbound, 2 inbound), message type, basic type, sender and receiver partner and port. The data records hold the content in segments named like E1EDK01 (header general data) or E1EDP01 (item general data). The status records log each processing step with a two-digit status code, such as 53 (application document posted) or 51 (application document not posted).

Following one 850 into SAP

When Great Lakes' 850 arrives, the translation is mostly a re-arrangement. The X12 envelopes are consumed by the middleware; the control record is built from the partner IDs instead. The business segments map to IDoc segments with SAP qualifiers:

Two qualifier facts from SAP's own mapping tables are worth memorizing because they show up in every EDI project: in E1EDP19, qualifier 001 carries the customer's material number and qualifier 002 the supplier's; and in E1EDKA1 the partner function is SAP's internal, German-derived code (AG, WE, RE, RG, LF) even when the user interface shows the English codes (SP, SH, BP, PY, VN).

Who owns which part of the mapping

An EDI flow crosses three owners, and a defect report is only useful if it reaches the right one. The partner owns its file and its guide. The middleware team owns the translation between the file and the IDoc: envelopes, qualifiers, code conversions such as the X12 unit of measure EA to the ISO unit code the IDoc expects, and field-by-field mapping. The SAP team owns what the IDoc does once it arrives or how it is built when it leaves: partner profiles, output determination, customer and material determination, and the application logic. When Maria finds a wrong ship-to on a sales order, the first question is where the value went wrong: in the file, in the map or in SAP's conversion tables.