Lesson 2 of 6
The EDI_DC40 control record
9 min
Listen to this lesson
Every IDoc carries one control record, EDI_DC40, before its data segments. It says what the IDoc is, who sent it and who should receive it. For outbound IDocs you read it; for inbound IDocs you build it, and S/4HANA decides what to do with the IDoc almost entirely from it. A wrong control record is the most common reason an inbound IDoc from Cloud Integration never becomes a document.
| Field | Meaning | Inbound example (Great Lakes order to CMQ) |
|---|---|---|
| TABNAM | Name of the control record structure | EDI_DC40 |
| MANDT | Client | 100 |
| DOCNUM | IDoc number | Assigned by the receiving system |
| DIRECT | Direction: 1 outbound, 2 inbound | 2 |
| IDOCTYP / CIMTYP | Basic type / extension | ORDERS05 / empty (or Contoso's extension) |
| MESTYP, MESCOD, MESFCT | Message type, message code, message function | ORDERS |
| SNDPOR, SNDPRT, SNDPRN | Sender port, partner type, partner number | Agreed port, KU, Great Lakes' customer number 17100001 |
| RCVPOR, RCVPRT, RCVPRN | Receiver port, partner type, partner number | SAPCMQ, LS, CMQCLNT100 |
| TEST | Test indicator | Empty in production |
| ARCKEY, SERIAL | Message key and serialization | Used for in-order delivery |
EDI_DC40 fields that matter for mapping, with Contoso's inbound values. Partner and port values must match the receiving system's configuration.
How S/4HANA uses the control record
When an inbound IDoc arrives, S/4HANA looks for an inbound partner profile (WE20) that matches the sender partner number, partner type and partner function together with the message type, message code, message function and test indicator. If it finds one, the profile's process code decides which function processes the IDoc, for example process code ORDE creates a sales order from an ORDERS IDoc. If it doesn't find one, the IDoc is saved with status 56 (IDoc with errors added) and nothing else happens.
The statuses are your first diagnostic. 56 points to the control record or the partner profile, not the data. 51 means the application tried and failed, for example an unknown material; the reason is in the status record. 53 means a document was created, which still needs checking against the source (sap-int-201 covers this in depth).
Cloud Integration builds what PI's adapter filled
This is the biggest surprise for PI developers. PI's IDoc adapter filled much of the control record itself: SAP documents that, unless Apply Control Record Values from Payload is set, it takes sender and receiver partners from the Integration Directory, uses constant LS partner types and generates DOCNUM. In Cloud Integration the IDoc receiver sends the control record you put in the XML. Your mapping, or a Content Modifier before it, has to fill every field the receiving system needs.
| PI/PO IDoc adapter (AAE) | Cloud Integration IDoc receiver | |
|---|---|---|
| SNDPRN, RCVPRN | From Integration Directory configuration, unless payload values are applied | From your payload: map them |
| SNDPRT, RCVPRT | Constant LS unless configured otherwise | From your payload: KU, LI or LS as the profile needs |
| DOCNUM | Generated from a number range | Assigned by the receiving system |
| Where to set values | Communication channel and Integration Directory | Message mapping or Content Modifier |
Two more fields deserve attention. The partner function (SNDPFC) is part of the profile key for partner types that use it, so leave it empty unless the profile has one. The test indicator (TEST) is also part of the key: if a partner profile is maintained for test messages only, a flow that sends production IDocs without the flag won't find it. Contoso keeps the test indicator empty in every tenant and separates test from production by system, not by flag.
Reading the outbound control record
Outbound, the control record tells the flow who the IDoc is for. Contoso's PO IDoc for Lakeside carries RCVPRT = LI and RCVPRN = Lakeside's supplier number in S/4HANA, 17300001. The flow reads those two values (with XPath in a Content Modifier, for example /ORDERS05/IDOC/EDI_DC40/RCVPRN) and uses them to find the partner's settings in the Partner Directory (lesson 5). That is how one flow can serve many suppliers without a hard-coded partner.
- Set
SNDPRTandSNDPRNto exactly what the inbound partner profile uses, including leading zeros in partner numbers. - Set
RCVPRNto the receiving client's logical system, for exampleCMQCLNT100in test and the production value in CMP; take both from configuration, never hard-code them. - Agree the sender port value with Sam's Basis team, so it is consistent with the receiving system's port definitions.
- Leave
DOCNUMto the receiving system; don't invent numbers. - Externalize tenant-dependent values so the same flow version runs in CMC_TEST and CMC_PROD.
What would you do?
The first inbound order from the migrated Great Lakes flow lands in CMQ with status 56. The mapping test passed and the sales data looks right. What should Theo's developer check first?
- EDI_DC40 identifies the IDoc type, sender, receiver and message; S/4HANA finds the inbound partner profile from it.
- No matching partner profile → status 56; application failure → 51; document created → 53.
- PI's IDoc adapter filled control record values; in Cloud Integration the flow must map them.
- Read RCVPRT and RCVPRN outbound to find the partner; externalize tenant-dependent values inbound.
Check your understanding · not graded
Lesson check
1. Which status does S/4HANA give an inbound IDoc when no matching partner profile is found?
2. Who assigns DOCNUM for an IDoc that Cloud Integration sends to S/4HANA?
3. Which value does Contoso's outbound flow read to find Lakeside's partner settings?
4. Why do migrated PI interfaces often fail with status 56 at first?