BD54 — Maintain Logical Systems for ALE and IDoc Distribution
BD54 maintains the customizing table of logical system names used across ALE, IDoc and hybrid BTP integration landscapes to uniquely label systems and clients. It only creates or renames the name and description in table TBDLS. It does not assign that name to a client - that binding happens separately in SCC4, and confusing the two is the most common mistake made with this transaction.
BD54 is the maintenance view for logical system names, the short identifiers ALE, IDoc, partner profiles and distribution models use to address systems and clients. This page covers how the definition step in BD54 differs from the client assignment step in SCC4, and the specific failures that show up in client copies, transports, and renamed logical systems.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,093 words
What it does
BD54 is a simple maintenance transaction over customizing table TBDLS, which stores logical system names and their short descriptions. A logical system name is the label ALE, IDoc distribution, and partner profile configuration use instead of a physical system ID and client number. The structural fact that causes most confusion: BD54 only creates or edits the name and description entry. It does not bind that name to a specific client. The binding lives in a client-level setting maintained through SCC4. Consultants routinely expect deleting or editing an entry in BD54 to change which client uses that logical system, and it does not; the client keeps pointing at whatever name is stored against it until SCC4 is changed directly.
When it is used
BD54 is reached during initial ALE or IDoc setup, before partner profiles, ports, or a distribution model exist, because those objects all reference a logical system name that must already be defined. It is also reached when a new client is stood up for testing, QA, or a production refresh and needs its own distinct logical system name to avoid collisions with the source client it was copied from. It gets touched again whenever a new external or partner system is being connected via IDoc. On the BTP side, where integration increasingly runs through proxies, OData or event mesh rather than classic IDoc, BD54 is still relevant wherever the integration flow terminates in an IDoc adapter talking to a legacy or third-party system.
How to use it
- Call BD54 in the client where the logical system needs to be defined or documented.
- Choose New Entries to add a name, or select an existing row to change its description.
- Enter the logical system name, up to ten characters, following the landscape naming convention (commonly system ID plus client), and a meaningful short text.
- Save; because TBDLS is a cross-client table, a transport request is normally required.
- Go to SCC4 to assign this logical system name to the actual client, since BD54 alone does not create that link.
- Continue configuration in WE20 for partner profiles and BD64 for the distribution model, both of which reference the name just created.
Key fields
- TBDLS - the customizing table holding the logical system name and its description; this is what BD54 actually maintains.
- T000 - the client table, where field LOGSYS records which logical system name is assigned to the client; maintained via SCC4, not BD54.
- EDIPO / partner profile tables - reference the logical system name as the partner number when partner type is set to logical system.
How to prove it in the data
Run SE16 on TBDLS to list every logical system name defined in the system along with its description; this shows what exists, not what is used. Run SE16 on T000 and check field LOGSYS for each client to see which logical system name is actually assigned to which client at runtime. A name present in TBDLS with no client referencing it via LOGSYS is defined but unused. A client whose LOGSYS value has no matching row in TBDLS is an inconsistency that will surface as errors when creating partner profiles or activating the distribution model.
ECC vs S/4HANA
BD54, table TBDLS, and the SCC4 client assignment work identically on S/4HANA; there is no structural change and no dedicated Fiori app replacing this transaction. It remains relevant on S/4HANA landscapes that still exchange IDocs with legacy or third-party systems, including cases where an integration flow built in SAP Integration Suite maps into an IDoc adapter and needs the correct logical system name on the sender or receiver side.
Common pitfalls
- Definition versus assignment confusion - editing or deleting an entry in BD54 changes only the TBDLS row, not which client actually uses that name. Always check SCC4 for the real client-to-logical-system binding before assuming a BD54 change took effect.
- Duplicate logical system after client copy - a client copy or system copy also copies the T000-LOGSYS value, so the source and target clients can end up sharing the same logical system name. This causes IDoc routing conflicts and duplicate document number ranges. Check T000-LOGSYS on both clients immediately after any copy and correct the target via SCC4.
- Renaming breaks downstream config silently - once a logical system name is referenced in the distribution model, partner profiles, ports, and output determination, renaming it in BD54 does not update any of those objects. Every dependent configuration keeps pointing at the old name and starts failing without an obvious error at the point of rename.
- Accidental transport of the client assignment - TBDLS itself transports cleanly as customizing, but the SCC4 assignment is client-specific and must never travel in a transport. If it does, the target client's logical system changes on import and every IDoc exchange for that client stops working until it is corrected manually.
- Missing entry blocking partner profile creation - WE20 looks up the logical system name against TBDLS when partner type is set to logical system. If the name is missing, profile creation fails with an error that looks unrelated but traces straight back to a missing BD54 entry.
Whose problem this is
Ownership sits with Basis or a techno-functional integration consultant, because TBDLS is cross-client customizing and the SCC4 assignment is client-specific system landscape configuration, not a single module's concern. A good handover states the logical system name, the client it belongs to, which other systems already reference it in their own distribution model, and the transport request number if it was created through a change request.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/bd54ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.