EDP12 table — Segment Filtering for Reduced IDoc Message Types

One row in EDP12 represents a segment type that is permitted to appear in a reduced variant of an outbound message type under the ALE distribution model's message reduction technique. When a message type is reduced (typically configured through the distribution model maintenance transaction rather than typed in directly), the system needs to know which of the message type's standard segments should still be built into the IDoc and which should be suppressed for that particular receiving partner or scenario. EDP12 is that list. It is a configuration table, not a transactional log: it does not record individual IDocs, it records the structural rule that the IDoc generation logic consults when it assembles a reduced message type for a given recipient.

EDP12 is small, configuration-sized, not transactional volume, so performance is rarely the concern. Always restrict on MANDT first. After that, restrict on MESTYP, because the table is only meaningful per message type; scanning it without a message type filter produces a list that mixes unrelated reduction configurations and tells a reader nothing about a specific interface. There is no date or time field to filter on since this is not a log; if the question is 'what changed and when', this table cannot answer it and the change history has to come from the transport or customizing change log instead.

Symptom: a partner reports that IDocs of message type ORDERS reduced variant Z arrive without a segment the functional team expects, for example pricing conditions. Select EDP12 with MANDT = current client and MESTYP = the reduced message type name, and check whether the pricing segment type appears in the SEGTYP list. If it is absent, the segment is intentionally excluded by the reduction configuration and the IDoc is behaving as designed, not failing.

EDP12 still exists in S/4HANA and the ALE message reduction technique it supports remains functional, since classic IDoc distribution continues to run alongside newer integration approaches. There is no known CDS compatibility view replacing it, because it is a customizing table rather than a business data table. In practice, message type reduction is used less on new S/4HANA builds where API-based or event-based integration through the platform is preferred, but existing ALE scenarios carried forward from ECC continue to rely on it unchanged.

A question about entries in EDP12 belongs to whoever owns the ALE distribution model and partner profile configuration, typically an interfaces or basis-adjacent integration consultant, not the functional module consultant who only sees the missing segment downstream. Functional teams should raise the specific message type and segment with that owner rather than requesting a direct table change.

EDP13 carries the companion field-value filtering for the same reduction technique, and EDP21 holds the actual filter values referenced by that field filtering. TBDLS is part of the distribution model definition that determines which reduced message type a given logical system receives. EDIDC and EDIDD (or EDID4) are where the effect of the reduction is actually visible, since that is where the generated IDoc's segments live. The distribution model reduction maintenance transaction is where EDP12 should be changed, never through direct table maintenance.