EDP13 table — IDoc Partner Profile: Outbound Parameters

EDP13 holds outbound partner-profile parameters used by the IDoc interface to determine how a message for a particular partner is processed. These settings are maintained conceptually through WE20 and can include message type and technical dispatch/process parameters depending on the scenario. EDP13 is configuration, not runtime IDoc status/history and not the ALE distribution model itself.

Read EDP13 through the partner-profile key shown in WE20 and confirm release-specific DDIC fields in SE11 when exact technical names are needed.

EDP13 is one layer of WE20 configuration. At runtime, partner/message determination leads to an IDoc control record in EDIDC, data segments in EDID4/EDIDD, and statuses in EDIDS. Port information is maintained through WE21 and outbound process-code logic through WE41. BD64 distribution-model settings are a separate ALE decision layer.

Start from the exact WE20 partner profile and message type. Confirm the client, partner type, and outbound parameter entry before comparing technical dispatch settings. Do not use EDP13 to explain why a BD64 filter suppresses a receiver; prove distribution-model selection separately. Never directly edit partner-profile tables to fix production routing.

For an outbound IDoc routed incorrectly or not dispatched, compare the WE20 outbound entry with EDP13 for the same partner and message type, then verify port/process code and the resulting EDIDC receiver/sender data. If the partner profile is correct but no IDoc is created, move upstream to the application trigger or BD64/change-pointer selection rather than changing EDP13 blindly.

Capture the partner type/number, logical receiver, outbound message and any extension used by the actual IDoc. Compare WE20 parameters with the relevant EDP13 entry and test whether EDIDC was created with the intended partner and port. Then check the port, RFC/file dispatch and status records, instead of concluding that every missing outbound IDoc is an EDP13 error. Use application logs before repeating business output.

EDP13 remains part of classic IDoc partner-profile configuration in S/4HANA. API/event-based integration may avoid partner profiles for new scenarios, but any retained IDoc interface still uses the same conceptual WE20 outbound-parameter layer. The table's role should therefore be described as partner-profile configuration, not as an obsolete ALE filter table.

Production incident: a WE20 partner has a valid outbound message type, but IDocs remain in dispatch status or are routed to an unintended receiver. Separate profile determination from IDoc creation and subsequent transmission. EDP13 configures outbound processing, while ports, partner roles, message types and communication destinations have their own checks. The same business partner may be configured differently by message type or partner type.

Primary ownership is ALE/IDoc integration. Application functional teams own business-message triggering; integration/ABAP owns partner profile, process code, and mapping; Basis owns RFC/port connectivity and communication-layer failures.

WE20 is the primary maintenance UI. EDP12 covers Message Control-related outbound profile data, EDP21 inbound parameters, WE21 ports, WE41 outbound process codes, and EDIDC/EDID4/EDIDS runtime IDoc data. BD64 is the separate ALE distribution-model configuration.