TBDLS table — ALE Distribution Model Table Behind BD64

TBDLS stores the ALE distribution model that is built and maintained through transaction BD64. Each row is one authorized relationship: a named model, a sending logical system, a receiving logical system, and the message type that is allowed to flow between them, optionally restricted further by a filter object (for example a specific sales organization or plant) so that only a subset of master data changes for that message type gets distributed to that receiver. The table answers the question of whether a receiver is entitled to a message type at all, before any technical dispatch mechanics are considered. It is the source consulted by change pointer evaluation programs to determine the list of receiving logical systems for a changed master data object, and it is also the object that BD64 replicates (sends) to other systems in a distributed landscape.

TBDLS is a customizing table, small in nearly every landscape, from a few dozen to a few thousand rows, so it can be browsed safely in SE16N without lock or performance concerns. Always restrict on MANDT first, then on MODEL if the landscape has more than one distribution model defined, then on MESTYP and RCVPRN for the specific case under investigation. Do not try to reconstruct the full model logic by eyeballing the raw table; BD64 renders the same data as a hierarchical tree and is the correct place to confirm what a set of rows actually means, especially once filter objects are involved.

Symptom: a master data change on the sending system is not arriving as an IDoc on a specific target system, and change pointers appear to be active. Select TBDLS with MANDT equal to the client, MESTYP equal to the message type in question, and RCVPRN equal to the target logical system name. No row returned means the distribution model does not authorize that receiver for that message type, so no change pointer will ever be evaluated for it; this is a configuration gap in BD64, not a port, partner profile, or RFC connection issue.

TBDLS is unchanged on S/4HANA and BD64 remains the transaction that maintains it. It has not been replaced by a CDS compatibility view or restructured, since it belongs to classic ALE customizing rather than to the transactional data volume that S/4HANA's data model simplification targeted. Where a landscape has moved outbound integration to event-based or API-based patterns through an integration platform, the classic distribution model in TBDLS may simply go unused for those flows, but it continues to govern any change-pointer-driven ALE distribution that is still in place.

Distribution model content is owned by whoever administers ALE and interface configuration for the landscape, typically a Basis or integration architecture role, not the functional module team. A functional consultant who finds a missing TBDLS entry should raise it as a distribution model change request through BD64 rather than requesting a direct table edit.

BD64 creates and changes TBDLS content and also handles sending the model view to other systems in the landscape. BDLS is used to mass-rename logical system values, which touches the SNDPRN and RCVPRN values stored here along with many other tables. EDIDC and EDIDD hold the actual IDoc control record and data segments produced once a change pointer clears the TBDLS check and a partner profile in EDP13 completes the technical dispatch. RFCDES holds the RFC destination typically named after the logical system referenced in SNDPRN and RCVPRN.