SAPFree referencePDF, Excel, Word exportSAP ECC / S/4HANA

SAP IDoc Control Record (EDIDC) Fields Reference

The IDoc control record is the header that tells SAP who sent the document, who receives it, what business message it carries and which structure it uses. This table lists the fields you meet most often when debugging or coding IDoc interfaces.

Download:

Field	Meaning	Data type	Notes
MANDT	Client	CLNT 3	Only in table EDIDC, not in the EDI_DC40 file structure
DOCNUM	IDoc number	NUMC 16	Unique number per client, assigned when the IDoc is created
STATUS	Current status of the IDoc	CHAR 2	Latest status is copied here from table EDIDS
DIRECT	Direction	CHAR 1	1 = outbound, 2 = inbound
IDOCTP	Basic IDoc type	CHAR 30	Structure definition, for example ORDERS05
CIMTYP	Extension (customer IDoc type)	CHAR 30	Only filled when a basic type is extended
MESTYP	Logical message type	CHAR 30	Business meaning, for example ORDERS; drives partner profile lookup
MESCOD	Logical message variant	CHAR 3	Optional, refines the message type in the partner profile
MESFCT	Logical message function	CHAR 3	Optional, further refines the message type
STD	EDI standard	CHAR 1	For example X for ANSI X12, E for EDIFACT
STDVRS	Version of the EDI standard	CHAR 6	Used with subsystem EDI conversion
STDMES	EDI message type	CHAR 6	For example 850 for X12 or ORDERS for EDIFACT
SNDPOR	Sender port	CHAR 10	Port defined in WE21
SNDPRT	Sender partner type	CHAR 2	LS = logical system, KU = customer, LI = vendor
SNDPFC	Sender partner function	CHAR 2	For example SP, SH, BP when the partner type needs one
SNDPRN	Sender partner number	CHAR 10	Logical system name, customer number or vendor number
RCVPOR	Receiver port	CHAR 10	Port defined in WE21
RCVPRT	Receiver partner type	CHAR 2	LS = logical system, KU = customer, LI = vendor
RCVPFC	Receiver partner function	CHAR 2	Same value set as the sender partner function
RCVPRN	Receiver partner number	CHAR 10	Key part of partner profile WE20
CREDAT	Creation date	DATS 8	Date the IDoc was created
CRETIM	Creation time	TIMS 6	Time the IDoc was created
UPDDAT	Date of last change	DATS 8	Updated on each status change
UPDTIM	Time of last change	TIMS 6	Updated on each status change
SERIAL	EDI serialization field	CHAR 20	Used to detect out-of-order delivery of related IDocs
REFINT	Reference to transmission file	CHAR 14	Interchange reference from a file or EDI subsystem
REFGRP	Reference to message group	CHAR 14	Group reference from the EDI subsystem
REFMES	Reference to message	CHAR 14	Message reference from the EDI subsystem
ARCKEY	Archive key for external archive	CHAR 70	Set when the IDoc is archived with an external system
TEST	Test flag	CHAR 1	X marks a test IDoc
OUTMOD	Output mode	CHAR 1	Outbound only; 2 = transfer immediately, 4 = collect IDocs
TABNAM	Name of the control record structure	CHAR 10	Holds EDI_DC40 in the file or tRFC representation

Field names and lengths are as delivered in standard SAP. Lengths of rarely used fields can differ by release, so confirm in SE11 for table EDIDC and structure EDI_DC40 on your system.

Want IDoc errors explained automatically?

Optional: a short call on how a private, read-only assistant could read your IDoc tables and summarise failures for your support team.

Optional. The tool and every export work without this. No spam.

How to use this reference

Type a field name or a keyword such as partner or port into the search box to narrow the table. Use the Notes column to see typical values. Export the result to Excel or CSV if you want to paste field lists into an interface specification or a mapping document for the integration team.

Search by field name to confirm length before building a file interface
Search by direction or partner to find the fields used by partner profile lookup
Export the table into your interface specification

EDIDC versus EDI_DC40

Table EDIDC stores the control record in the database. Structure EDI_DC40 is the representation used when IDocs travel through tRFC calls, files and middleware such as SAP PI/PO or Integration Suite. The two carry almost the same fields, but EDI_DC40 adds TABNAM and lacks the client field in file transfers. In ABAP, function modules such as IDOC_INBOUND_ASYNCHRONOUS take the older EDIDC format while newer interfaces use EDI_DC40.

Message type versus IDoc type

MESTYP says what the document means, for example ORDERS for a purchase order or sales order. IDOCTP says which segment structure carries it, for example ORDERS05. One message type can use several IDoc types over releases, and one IDoc type can serve several message types. Partner profiles in WE20 are keyed by message type, not IDoc type, so a wrong MESTYP is a classic reason for status 56 or 64 errors.

Common mistakes

Developers often fill sender and receiver partner numbers with system IDs instead of logical system names, forget the partner type, or leave the port blank. Another trap is confusing DIRECT values: outbound is 1 and inbound is 2, and the same partner can have a different profile entry per direction.

Use the logical system name from BD54 when the partner type is LS
Check the port exists in WE21 before sending
Set DIRECT correctly before calling inbound function modules

Frequently Asked Questions

What is the difference between EDIDC and EDID4?

EDIDC holds one control record per IDoc, which is the header. EDID4 holds the data records, which are the segments with their field content stored as a string. EDIDS holds the status history. Together these three tables are what you query to analyse IDoc traffic directly in the database.

What does DIRECT mean in an IDoc?

DIRECT is a one-character field that tells you the direction as seen from the system you are in. A value of 1 means outbound, so the IDoc was created here and sent out. A value of 2 means inbound, so it arrived here to be posted into an application.

Which field links an IDoc to its partner profile?

For outbound IDocs, SAP looks up the partner profile using the receiver partner number, partner type and message type, optionally with function, code and variant. For inbound IDocs it uses the sender partner details. The profile then decides the port, output mode and process code.

Can I add my own fields to the control record?

No. The control record structure is fixed by SAP. If you need extra data, carry it in a custom segment through an IDoc extension, or use the reference fields such as REFINT and REFMES only for what they are meant for, which is tracking external transmission references.

If your team spends time chasing IDoc errors across systems, Netray can build a private assistant that reads IDoc tables and explains failures in plain language, with read-only access by default.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

Back to All Tools