EDP12 table — IDoc Partner Profile: Outbound Message Control

EDP12 stores the Message Control-oriented portion of outbound IDoc partner profiles. It belongs to the partner-profile configuration maintained through WE20 and used when application output/message determination triggers outbound IDoc processing. Its role is to connect partner/message-control context to outbound EDI/IDoc behavior; it does not define which segments belong to a reduced IDoc type.

Field details can vary by release and partner-profile scenario, so interpret EDP12 through the partner-profile business key shown in WE20 rather than relying on guessed segment names.

EDP12 belongs to the WE20 partner-profile model. SAP documents EDPP1 as general partner profile, EDP12 as Message Control, EDP13 as outbound parameters, and EDP21 as inbound parameters. The runtime IDoc itself is then represented by EDIDC, EDID4/EDIDD, and EDIDS; those runtime tables should not be confused with partner-profile configuration.

Start in WE20 with the exact partner, partner type, message/application context, and client, then use EDP12 only to prove the Message Control configuration behind that profile. Avoid direct changes in SE16/SM30. If the issue is an ALE distribution rule or filter, move to BD64 and its model data instead of forcing an EDP12 explanation.

When an application output creates no outbound IDoc, first prove the Message Control/output record and partner/message combination. Compare the WE20 outbound Message Control configuration with the EDP12 row for the same partner context. Then follow the runtime chain into process code/port and EDIDC/EDIDS. If WE20 has no matching outbound configuration, the failure occurs before any IDoc data record exists.

Identify the actual application output type, partner function and message determination result. Inspect the matching WE20 Message Control entry, then the outbound EDP13 technical parameters and any created IDoc's EDIDC control record. If the application has not created an output record, troubleshoot determination before changing EDP12. Document the message type, partner profile and processing time for an auditable handoff.

EDP12 remains relevant in S/4HANA for classic IDoc scenarios that still use Message Control-based outbound processing. New Output Management, APIs, events, or Integration Suite patterns may replace the classic route for particular applications, but that does not change EDP12's meaning where WE20/IDoc processing is still active.

Production incident: an SD output condition exists, but processing produces no outbound ORDERS or DESADV IDoc. First distinguish message determination from the partner-profile Message Control mapping: output may be created for the application but not match the EDP12 entries for the configured partner and message. Correcting the technical port will not fix a mismatch earlier in the output determination chain.

Primary ownership is ALE/IDoc integration configuration, normally shared by the application functional team and the integration/ABAP team. Basis owns RFC/port connectivity where transport fails; the application team owns output determination or New Output Management when the IDoc trigger never fires.

WE20 maintains partner profiles, WE21 maintains ports, WE41/WE42 maintain process codes, EDIDC/EDID4/EDIDS hold runtime IDoc records, and BD64 defines ALE distribution models. EDP13 and EDP21 are sibling partner-profile tables for outbound and inbound parameters.