EDP21 table — EDP21 - Partner Profile Inbound Parameters
EDP21 holds the inbound side of ALE partner profile configuration maintained through the partner profiles transaction. Each row ties a partner (by partner number and partner type) and an inbound message type, optionally qualified by message code and function, to the inbound processing rule that decides how a received IDoc is posted once it clears the control record checks.
EDP21 is the classic ALE/IDoc customizing table that stores inbound partner profile entries: which partner, which message type, and how the resulting IDoc should be processed. The page covers the fields worth trusting, the joins to the IDoc control record and logical system directory, and the mistakes consultants make reading this table directly instead of through the partner profile transaction.
Published 15 Sept 2026· 1,099 words
What it stores
One row in EDP21 represents one inbound processing rule configured for a trading partner in the partner profile transaction. The row is identified by the partner number and partner type of the sender, plus the message type expected from that partner, and optionally a message code and message function that narrow the rule to a specific variant of the message. The row tells the ALE/IDoc inbound layer which process is responsible for taking a posted IDoc and turning it into a business document, and whether the entry is a live configuration or a test profile. Without a matching row for the combination present on an incoming IDoc's control record, the inbound layer cannot determine how to process the IDoc and the IDoc stalls in an error status waiting for manual intervention.
Key fields
- MANDT - client, always restrict on this first
- PARNUM - partner number, the business identifier of the sending partner (logical system name, customer number, vendor number, depending on partner type)
- PARTYP - partner type, e.g. LS for logical system, KU for customer, LI for vendor
- MESTYP - message type expected inbound from this partner, e.g. ORDERS, INVOIC, DEBMAS
- MESCOD - message code, used when the same message type needs different handling for different business variants
- MESFCT - message function, further narrows the message code variant
- a process indicator field that names the inbound process (function module or workflow) responsible for posting the IDoc, maintained on the same screen as the test flag - exact column name not restated here to avoid guessing
- a test flag indicating the entry is marked for test processing rather than live posting
How it joins the data model
- EDP21-PARNUM = TBDLS-LOGSYS, when EDP21-PARTYP = 'LS', to resolve the partner to a logical system definition
- EDP21-MESTYP = EDIDC-MESTYP, to match an arrived IDoc's control record to the inbound rule that should process it
- EDP21-PARNUM = EDIDC-SNDPRN and EDP21-PARTYP = EDIDC-SNDPRT, matching the sender identified on the IDoc to the partner profile entry
- EDP12 mirrors EDP21 for the outbound direction, keyed the same way but describing how outbound IDocs of a given message type are generated for a partner rather than how inbound ones are consumed
How to read it safely
EDP21 is client-dependent and small, a configuration table rather than a transactional one, so performance is rarely the concern. The risk is reading it in isolation. Always restrict by client, then by partner type and partner number, then by message type, because the same partner can have several rows differing only by message code or message function, and the runtime picks the most specific match rather than the first row found. Do not try to reconstruct the matching logic by eye from a flat table dump without also checking whether a generic entry with blank message code exists alongside a specific one, since precedence rules decide which applies.
How to prove it in the data
Symptom: an inbound IDoc is stuck with a status indicating no matching inbound partner profile entry could be found. Take the sender partner number, sender partner type, and message type from the IDoc's control record and select against EDP21 on the same client, partner number, partner type, and message type. No row returned confirms the missing profile entry is the root cause; a row returned but with a message code or message function that does not match the IDoc's own values points to a variant mismatch instead.
ECC vs S/4HANA
EDP21 and the partner profile transaction behind it carry into S/4HANA unchanged as core ALE/IDoc plumbing. There is no CDS compatibility view replacing it, because it is customizing configuration rather than a business data table, and IDoc-based integration remains fully supported alongside newer BTP-based integration approaches. Any integration scenario that lands IDocs on an S/4HANA system, including those originating from BTP integration flows using the IDoc adapter, still depends on this table having a correct entry for the sender and message type involved.
Common pitfalls
- Assuming one row per partner: a partner routinely has several rows for the same message type distinguished by message code and message function, and reading only the first row found gives a wrong picture of how that partner is actually configured
- Editing EDP21 directly through a generic table tool instead of through the partner profile transaction: this can create an entry with no corresponding inbound process configuration behind it, so the row exists but nothing actually processes IDocs against it
- Confusing inbound and outbound tables: chasing an outbound IDoc failure in EDP21 when the outbound rule lives in EDP12 and EDP13, or the reverse
- Treating absence of a row as proof the partner does not exist: the partner master itself, whether a logical system entry, a customer, or a vendor, is separate from the ALE inbound configuration, and a valid partner can simply lack an inbound profile for a given message type
- Missing the test flag: an entry marked for test processing will still show up in a lookup and look like a live configuration, leading to a wrong conclusion that inbound processing is correctly configured for production traffic
- Ignoring precedence between a specific message code/function entry and a generic blank entry for the same message type: the runtime resolves to the most specific match, and a manual read that stops at the first hit can misdiagnose which rule actually fired
Whose problem this is
Configuration in EDP21 belongs to whoever owns ALE/IDoc interface setup on the project, typically a Basis or integration/technical consultant, not the functional module owner or the business data steward. Questions about why an inbound IDoc has no matching profile go to that person, since the fix is a partner profile maintenance transaction, not a master data correction.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/edp21ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.