Lesson 4 of 6
Mapping inbound EDI to IDocs
9 min
Listen to this lesson
Inbound EDI reverses the pattern and adds a responsibility: you now build the IDoc that S/4HANA will turn into a business document. Contoso's busiest inbound interface is the X12 850 from Great Lakes Fleet Services, which creates sales orders such as 1000457 for 50 × CMC-ALT-100. The second is Lakeside's advance ship notice, which creates inbound deliveries.
Splitting, validating and acknowledging
A partner file can contain several transactions. The EDI Splitter splits a bulk EDI message, can validate the parts, and can send a functional acknowledgment (997 for X12, CONTRL for EDIFACT) after processing. The converters have structural limits you must respect: for X12, SAP's EDI elements support one functional group (GS) per interchange and one transaction set (ST) per group. Split first, then convert each transaction with the EDI to XML Converter, which needs the same kind of schemas as the outbound converter. The EDI Extractor can read header values, such as the sender ID, into headers before conversion.
850 to ORDERS05
| X12 850 | ORDERS05 | Rule |
|---|---|---|
| ISA06 / GS02 sender | EDI_DC40 SNDPRT KU, SNDPRN customer number | From Partner Directory alternative partner, not a table in the mapping |
| BEG03 PO number | E1EDK02 with QUALF 001, BELNR | Customer's PO number, later echoed in the 810's BIG04 |
| N1 loop with N101 = ST | E1EDKA1 with PARVW WE | Ship-to; N101 = BY becomes PARVW AG (sold-to) |
| PO1 per line | E1EDP01 per item | PO101 to POSEX, PO102 to MENGE |
| PO103 unit | E1EDP01-MENEE | Value mapping EA → PCE |
| PO106/PO107 product ID | E1EDP19 with QUALF 001 or 002 | BP → 001 (customer material), VP → 002 (Contoso material) |
| DTM requested date | E1EDP20-EDATU | Schedule line date per item, in the item context |
Core of the Great Lakes 850-to-ORDERS05 mapping. Use Great Lakes' implementation guide for qualifiers and the S/4HANA inbound function for required segments.
Two details cause most defects. First, item context: E1EDP20 sits under each E1EDP01, so the requested date must be mapped in the item context, or every item gets the first line's date. Second, the control record: every field from lesson 2 must be filled, with the partner number exactly as maintained in the inbound partner profile. Contoso fills partner-independent values (IDOCTYP ORDERS05, MESTYP ORDERS, RCVPRT LS) in the mapping and tenant-dependent ones (RCVPRN, RCVPOR) from externalized parameters passed in as properties.
- Mon 08:02850 receivedGreat Lakes' file arrives over AS2; EDI Splitter validates it
- 08:02997 sentFunctional acknowledgment goes back to Great Lakes
- 08:03IDoc postedORDERS05 reaches CMQ; status 64, then 53
- 08:03Sales orderSales order 1000457 created for 50 × CMC-ALT-100
- Later855 or 810Confirmation or invoice 90001877 echoes the customer's PO number
DESADV to DELVRY07
Lakeside's advance ship notice (X12 856) becomes an inbound delivery in S/4HANA through message type DESADV with basic type DELVRY07. The structure is hierarchical: a delivery header (E1EDL20) with items (E1EDL24) carrying material and quantity, and the PO reference that links the delivery to PO 4500002210. X12 856 is itself built from nested HL loops (shipment, order, item), so this mapping is mostly about contexts: map each 856 item HL to one E1EDL24 under the right header, and check the queues before trusting the output.
Supplier invoices: 810 to INVOIC02
The same pattern serves Lakeside's invoices. An inbound X12 810 becomes an INVOIC IDoc (basic type INVOIC02) that logistics invoice verification posts against PO 4500002210. Ana, the accounts payable clerk, cares about three things the mapping must get right: the supplier's invoice number and date, the PO reference on every line so the invoice can be matched, and amounts that reconcile, including the implied decimals of TDS01 in the other direction. The unit goes back from EA to PCE through the same value mapping as the outbound order, so a quantity of 500 matches the 500 pieces received.
Acknowledgments and status
The 997 says the file was syntactically acceptable; it says nothing about whether S/4HANA created a sales order. Contoso tells customers this clearly and treats business responses (an 855 order acknowledgment or the invoice) as the business confirmation. When an inbound IDoc fails with 51, the fix happens in S/4HANA (master data, then reprocessing in BD87), not by asking Great Lakes to resend, which risks duplicates.
What would you do?
Great Lakes reports that three orders from yesterday's file were acknowledged with a positive 997 but never confirmed. Maria finds no sales orders. In Cloud Integration the messages completed. What is the most likely place to look?
- EDI Splitter validates, splits and acknowledges; for X12 the converters support one GS per ISA and one ST per GS.
- Map the 850 to ORDERS05 with a complete EDI_DC40; partner values come from the Partner Directory.
- Item-level data such as E1EDP20 dates must be mapped in the item context.
- A 997 confirms syntax, not business processing; check the inbound IDoc status for that.
Check your understanding · not graded
Lesson check
1. For X12 messages, which structure do Cloud Integration's EDI elements support per interchange?
2. Which IDoc segment receives the ship-to party from an 850 N1 loop with N101 = ST?
3. Every item of an inbound order gets the first line's requested date. What is wrong?
4. What does a positive X12 997 from Contoso tell Great Lakes?