BD64 — ALE Distribution Model Maintenance
BD64 maintains the ALE distribution model, the definition of which logical system sends which IDoc message type to which logical system, with optional filters. It does not itself move data or configure the runtime path. The model must be generated into partner profiles (WE20) before any IDoc actually flows; a correct BD64 entry with no generated partner profile produces no traffic at all.
This page covers BD64, the transaction for maintaining ALE distribution model views that describe permitted message-type flows between logical systems. It focuses on the gap between defining a model entry and having it actually generate working partner profiles, and on the diagnostic sequence for tracing a missing or duplicate IDoc flow back to a model or filter problem.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,341 words
Purpose
BD64 maintains the ALE distribution model: named model views that state, for a pair of logical systems, which message types may flow from sender to receiver, and optionally under which filter conditions. The model is a design-time statement of intended traffic, not a runtime object. The one fact that explains most confusion: saving a model entry changes nothing about actual message dispatch. The model still has to be generated into partner profiles, which is what WE20 reads at runtime. A distribution model can be perfectly correct and an IDoc will still never leave the system if the generation step was skipped or run against the wrong client, because the partner profile, not the model, is what the outbound processing logic actually consults.
When it is used
BD64 sits in classical ALE/IDoc landscape design, used when setting up or extending distribution between SAP systems on message-type-based interfaces, for example material master, customer master, or cost center distribution between ECC, CRM, or APO-style satellite systems. A consultant opens BD64 when a new message type needs to travel between two logical systems, when an existing flow needs a filter narrowed to specific plants or sales organizations, or when diagnosing why change-pointer-driven output never produced an IDoc. In a modern BTP or SAP Integration Suite landscape this transaction is not the tool of choice; proxies, OData, or event mesh replace it for new development. BD64 remains relevant only where a legacy ALE scenario is still in production or where a new interface deliberately reuses the classic change-pointer/IDoc mechanism.
How to use it in practice
- Open BD64 and either select an existing model view or create a new one with a technical name and short description.
- Add a line specifying sender logical system, receiver logical system, and message type for the flow being defined.
- If the flow needs to be restricted (only certain plants, sales orgs, etc.), attach a filter object and enter the filter values on that line.
- Save the model view; the system typically prompts for a transport request separate from ordinary customizing requests.
- From the model view, run the generate partner profiles function so the entries are translated into WE20 partner agreements for sender and receiver.
- If the message type is meant to fire from a database change rather than an explicit send program, confirm the message type is active for change pointers in BD61.
Key data objects
- TBDLS - list of defined logical systems, maintained via BD54; BD64 validates sender and receiver entries against it rather than writing to it directly.
- Distribution model header and detail lines - the model view name, its message-type entries and any attached filter values are held in dedicated ALE model tables that SAP does not expect to be edited outside BD64; treat any table name for this as unverified and read the model only through the transaction.
- Partner profile outbound and inbound parameter tables - populated only when partner profiles are generated from the model; this is what WE20 displays, and it is a separate write from the model save itself.
- BDCP - change pointer entries written when a change document is created for an object linked to a message type active in BD61; not written by BD64, but the field that ties a data change to a message type flow defined in BD64.
How to prove it in the data
Confirm the model line exists by opening the relevant view in BD64 and reading sender, receiver, message type, and any filter values directly - this is the authoritative source, not SE16 on an underlying table. Then open WE20 for the receiver logical system and check the outbound parameter list for the same message type with a valid port and IDoc type; a model entry with no matching WE20 line means generation was never run or was run in the wrong client. If the flow is change-pointer driven, browse BDCP filtered by message type and change document object to see whether pointers were ever written for the change in question, independent of what BD64 shows.
ECC vs S/4HANA
BD64 is unchanged on S/4HANA; the ALE distribution model concept, the generation step, and the transport behavior all work exactly as in ECC. There is no Fiori app replacing it, because it is a technical configuration transaction rather than a business process screen. New interface development on S/4HANA generally favors OData services, proxies, or SAP Integration Suite over classical ALE, but any existing IDoc-based distribution scenario carried forward from ECC still depends on BD64 for its model definition.
Common pitfalls and how to diagnose them
- Partner profile never generated - the model view is correct but no outbound parameter line exists in WE20 for the message type. Rerun the generate partner profiles function from BD64 rather than creating the WE20 entry by hand; a hand-created entry drifts from the model and gets silently overwritten or contradicted the next time someone regenerates.
- Filter too restrictive - sender, receiver, and message type all match, but the attached filter object excludes the actual data being distributed, so nothing goes out despite an apparently correct setup. Diagnose by checking the filter values against the real attribute of the failing record (plant, sales org, material type) rather than assuming the filter is disabled just because a line exists.
- Model view not transported to the target system - transport of a model view is a deliberate manual action from the model editing menu, separate from normal customizing transport capture, and it is routinely forgotten. Confirm by opening BD64 directly in the target system; do not trust a transport log that shows the request as released.
- Logical system name mismatch - the logical system referenced in the model does not match what is actually configured behind the RFC destination or IDoc port, so the model and generated profile look fine but delivery fails at the communication layer. Cross-check the logical system name in TBDLS against what WE21 and the underlying RFC destination actually use.
- Duplicate or overlapping model views - two views define the same sender, receiver, and message type with different filters, producing ambiguous or duplicated generation results. Browse all model views in BD64 for the message type in question, not only the one expected to be relevant.
- Reflex fix that makes it worse - patching WE20 directly to unblock a stuck interface instead of correcting the BD64 model and regenerating. The manual patch reappears as a problem the next time anyone regenerates partner profiles from the model, because generation overwrites it without warning.
Whose problem this is
This belongs to whoever owns ALE/IDoc interface configuration, typically an integration or technical functional consultant rather than a pure ABAP developer, with Basis support only for transport and RFC destination issues. A good handover states the model view name, the exact message type, the sender and receiver logical system names, any filter object and values applied, confirmation that partner profiles were regenerated afterward, and the transport request number carrying the change.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/bd64ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.