EDIFCT table — EDI Process Code to Function Module Assignment
EDIFCT holds the assignment between an EDI process code and the ABAP function module that gets executed when an IDoc carrying that process code is processed inbound or outbound. It is maintained through the process code transactions (WE41 for outbound, WE42 for inbound) and is read at runtime by the IDoc dispatcher, not edited directly in production.
This page covers what a row in EDIFCT represents, how it sits between partner profile configuration and the actual function module call during IDoc processing, and the diagnostic traps consultants fall into when they mistake a process code problem for a function module bug or vice versa. It also covers how the table behaves in S/4HANA and who should own changes to it.
Published 15 Sept 2026· 1,152 words
What it stores
One row in EDIFCT represents the link between a single EDI process code and the ABAP function module that SAP invokes to handle an IDoc assigned to that process code, along with an indicator of the processing direction or type the entry applies to. Process codes are not tied to a single message type; the same process code can be reused by many partner profiles across many message types, all of which end up calling the same function module through this table. Partner profiles maintained through WE20 do not point to a function module directly, they point to a process code, and it is EDIFCT that resolves that process code to executable logic at runtime. Because of this indirection, the table is the actual switchboard for classic IDoc inbound posting and outbound generation, even though most consultants never open it directly and only ever touch WE41 or WE42.
Key fields
- MANDT - the client the entry belongs to, standard first key field on virtually every configuration table including this one
- Process code - the identifier shown on the WE41/WE42 screens and referenced from partner profile line items; the exact technical field name is not asserted here with certainty and should be confirmed in the ABAP dictionary before writing a query against it directly
- Function module name - the ABAP function module that gets called when an IDoc arrives with the associated process code; field name likewise not asserted with certainty
- Direction or processing type indicator - distinguishes whether the entry is for inbound or outbound handling, since process code numbering ranges overlap between the two
How it joins the data model
- EDIFCT process code = EDP13 outbound partner profile line process code, resolving which function module fires when that partner/message combination sends an IDoc
- EDIFCT process code = EDP12 inbound partner profile line process code, resolving which function module fires when that partner/message combination receives an IDoc
- EDIDC-MESTYP and EDIDC-RCVPRN/SNDPRN feed into EDP12/EDP13 lookups that in turn resolve through EDIFCT, so EDIDC is joined indirectly, never directly, to EDIFCT
- EDIDS status records reflect the outcome of whatever function module EDIFCT pointed the dispatcher to, so a status 51 or 64 entry is evidence to check back against the EDIFCT assignment for that process code
How to read it safely
EDIFCT is small, typically a few hundred rows per client covering the whole EDI process code catalogue, so selectivity is not a performance concern the way it is on IDoc data tables. Restrict by client first as always, then by process code once known. The normal reading direction is backwards from a symptom: start from the message type and partner in the failing IDoc, look up the process code in EDP12 or EDP13, then use that process code to find the function module registered in EDIFCT. Reading the table forward, scanning all rows to see what exists, is harmless here because of its size, unlike most tables in the IDoc landscape.
How to prove it in the data
Symptom: inbound IDocs for a given message type are stuck in an error status and the suspicion is that the wrong posting logic is running. Confirm the partner profile for that sender and message type in EDP12 to read off the process code assigned to that line. Then select EDIFCT for that client and process code to see which function module is actually registered. Compare that function module name against the one visible in the IDoc's processing log or the debugger call stack at the point of failure.
ECC vs S/4HANA
EDIFCT belongs to the classic IDoc and ALE framework and continues to exist unchanged in S/4HANA; being a configuration table rather than a business data table, there is no CDS compatibility view sitting on top of it. WE41 and WE42 remain the maintenance transactions in S/4HANA exactly as in ECC. Where an organisation has moved integration scenarios onto event-based or API-based patterns through the Integration Suite or event mesh, the classic process code framework and this table become less relevant for those specific flows, but any interface still running on IDocs continues to depend on it exactly as before.
Common pitfalls
- Assuming the function module registered in EDIFCT for a process code is wrong, when it is correct and the module itself is failing on the incoming data content or master data; the fix belongs in the module logic or upstream data, not in this table
- Editing EDIFCT directly through table maintenance instead of through WE41/WE42, which bypasses consistency checks and can be silently reset by a later support package or upgrade that reintroduces the SAP-delivered entry
- Forgetting that one process code is shared by every partner profile line that references it; changing the function module for a process code to fix one message type's problem silently changes behaviour for every other message type routed through the same process code
- Replacing a standard SAP process code entry with a customer-written function module without treating it as a modification, then being surprised the custom logic disappears or reverts after an upgrade
- Jumping straight into EDIFCT to explain an ALE failure before confirming, in EDP12 or EDP13, that the partner profile is even pointing at the process code the consultant thinks it is; the actual misconfiguration is often one layer up, in the partner profile assignment
- Treating the presence of an entry in EDIFCT as proof the function module is being called at all; authorization failures, release/version flags, or a wrong partner profile entirely can prevent the dispatcher from ever reaching that lookup
Whose problem this is
Configuration in EDIFCT is cross-application, so it typically sits with the Basis or interface/ALE team rather than a single functional module team. Application consultants (SD, MM, FI) can identify which process code a scenario needs but should not change the function module assignment unilaterally, since one process code often serves multiple applications and a change ripples beyond the immediate incident.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/edifctERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.