EDP13 table — ALE Distribution Model Filter Values

EDP13 stores the individual filter values used in the classic ALE distribution model's field-based filtering of message types. When a distribution model view, maintained through the model transaction, restricts which IDocs are actually generated and sent to a given receiver based on the content of a business field, such as a plant, sales organization, or material type, each value that is allowed to pass the filter is recorded as one row. The row links a message type, the receiving logical system, the identity of the field being filtered on, and the specific value permitted for it. Several rows accumulate when a filter allows more than one discrete value for the same object and receiver. The table is consulted at IDoc generation time, when the outbound processing logic decides whether the IDoc for a given receiver should actually be created, or dropped because the record's field content does not match any stored value.

Always restrict by MANDT first, this is a customizing table and cross-client noise makes any listing unreadable. After that, restrict by message type, then by the receiving logical system, since a full unrestricted browse mixes filter definitions for dozens of unrelated message types and interfaces. The table is small relative to application data, but it is not obviously ordered, so do not assume the first matching row found is the only relevant one; a filter can carry many value rows for the same object and receiver. Cross-check against the model view maintained in the distribution model transaction before trusting a raw table read, since the same filter can be defined at more than one level of the model hierarchy.

Given a report that a specific plant's material master changes are not reaching a receiving system while other plants' changes arrive normally, select EDP13 restricted to the client, the message type MATMAS, and the receiving logical system in question. If a filter object for plant exists and the affected plant's value is absent from the list of stored values, that confirms the filter is the cause. If no filter object row exists at all for that message type and receiver, the suppression is coming from somewhere else, such as the partner profile or the distribution model view itself, not from EDP13.

The table structure is unchanged going into S/4HANA and the underlying classic ALE filtering mechanism still functions, since the distribution model and its filter configuration are basis-layer objects independent of the application data model. What has changed is usage: many master data distribution scenarios that once relied on message type filtering in classic ALE have moved to newer replication frameworks, and IDoc-based interfaces that remain in place, particularly for legacy or non-SAP receivers, still rely on EDP13 exactly as before.

The integration or basis consultant responsible for the ALE distribution model owns changes to the filter definition itself. The business or master data team that decided a given plant, sales organization, or material type should or should not go to a particular receiver owns the decision about what values belong in the filter, and should be the one signing off before any value is added or removed.

EDP12 carries the companion segment or field reduction definition for the same message types, maintained in the same distribution model transaction. TBDLS holds the logical system master data referenced by the receiver in each filter row. EDIDC is the control record actually gated by the filter decision at IDoc creation time. The distribution model transaction is the only supported entry point for maintaining EDP13 content in a way that survives model redistribution.