BD12 — Send Customer Master via ALE

BD12 reads the customer master tables for a selected set of customers and generates outbound DEBMAS IDocs, sending them to whichever logical systems are configured as receivers in the ALE distribution model (BD64). It builds the general data segment, company code segment and sales area segment for each customer and hands the resulting IDocs to the ALE layer for dispatch. The structural fact that causes most confusion: BD12 is a one-shot, selective send. It does not set up an ongoing subscription. If a customer is created or changed after the BD12 run, that change is not picked up automatically unless change pointers are active for DEBMAS and a separate job or BD21 run processes them. Consultants who run BD12 once and expect future updates to flow are the most common source of downstream data drift tickets.

BD12 is reached for during initial system connection, when a new logical system, subsystem or non-SAP downstream application needs the existing customer base loaded before any ongoing sync starts. It is also used to resend a specific customer or a small range after an IDoc failed, after a mapping fix, or after a customer was extended to a new sales area and the receiver needs the updated segment. It is not the tool for real-time single-customer creation triggered by a transaction save, and it is not a substitute for setting up change pointers when the business requirement is continuous synchronization. Interface teams sometimes reach for BD12 as a quick manual override when a scheduled distribution job has stalled, which is legitimate for catching up a backlog but should not become the permanent replication mechanism.

Go to SE16 on EDIDC and filter on MESTYP = DEBMAS, CREDAT/CRETIM around the run time, and RCVPRN for the target logical system. Note the DOCNUM values returned, then look those up in EDID4 filtered by SEGNAM in E1KNA1M, E1KNB1M or E1KNVVM to confirm the expected data actually made it into the segment. Cross-check the STATUS field on EDIDC: 03 means dispatched successfully from this side, 51 or 56 means the receiver rejected it, and those status values point to where the real problem sits.

BD12 remains available on S/4HANA and behaves the same way for classic ALE customer master distribution. SAP has increasingly moved newer master data integration scenarios, particularly business partner synchronization, toward other replication mechanisms, but where a landscape still relies on customer master ALE, BD12 is unchanged. There is no Fiori app equivalent; this is a backend integration transaction typically run by an interface or basis resource rather than through the Fiori launchpad.

Ownership splits between SD/MM functional, who is responsible for the correctness of the customer master data and its extension to the right sales areas, and basis or integration, who owns the partner profile, port, and distribution model configuration. A clean handover states the message type DEBMAS, the customer number involved, the receiving logical system, the IDoc number and status code, and whether the issue reproduces on a fresh manual BD12 run or only through the scheduled job.

BD64 is the first stop to confirm the distribution model actually routes DEBMAS to the intended receiver. BD10 and BD14 are the equivalent manual send transactions for material master and vendor master respectively, and understanding one makes the other two familiar quickly. BD21 is the counterpart for processing change pointers, which is what turns a one-off BD12 send into an ongoing replication pattern. WE05 is the standard place to watch the IDocs BD12 generates and to see where in the pipeline a failed record actually stopped.