BD14 — Send Vendor Master Data via ALE
BD14 triggers outbound ALE distribution of vendor master data, generating IDocs of message type CREMAS for one or more vendor numbers based on the distribution model maintained in BD64. It performs a full send, not a delta send; delta replication after this initial load runs through change pointers via BD21, not BD14.
BD14 is the manual ALE send transaction for vendor master records, used mainly for initial loads and re-syncs rather than ongoing delta replication. This page covers the entry sequence, the tables the send writes to, and the recurring failure categories: missing distribution model entries, missing partner profiles, filtered-out organizational data, and confusion with the change-pointer path.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,066 words
Purpose
BD14 is the transaction used to manually trigger outbound distribution of vendor master data through classic ALE. Running it generates one CREMAS IDoc per selected vendor, addressed to whichever logical system is defined as a receiver for that message type in the distribution model. The structural fact that causes most confusion is that BD14 always performs a full send of the current vendor record state, regardless of whether anything actually changed. It is not the transaction that reacts to master data changes automatically; that job belongs to change pointers, activated per message type in BD61 and collected by BD21. Consultants who expect BD14 to behave like a trigger for ongoing synchronization are conflating the manual bulk-send tool with the delta-replication mechanism, which is a different code path entirely.
When it is used
BD14 is reached for for two situations: an initial load of vendor master data into a newly connected system (a new plant, a subsidiary company code going live, or a non-SAP system being onboarded via IDoc), and a targeted re-send after an interface failure has left one or a handful of vendors out of sync downstream. It sits upstream of any middleware or PI/PO scenario that consumes CREMAS IDocs, and it has no Fiori equivalent because it is a batch-style ALE utility, not a UI-driven business process. For ongoing delta replication after go-live, the correct tool is the change pointer mechanism (BD61 plus BD21), not repeated runs of BD14.
How to use it in practice
- Confirm the distribution model in BD64 already contains an entry for the sending logical system, message type CREMAS, and the intended receiver.
- Confirm a partner profile exists for that receiver with an outbound parameter for CREMAS (WE20).
- Call BD14, enter the vendor number or number range to send, restricting by company code or purchasing organization if only a subset should go out.
- Execute; the system reads the distribution model, builds the IDoc per vendor, and writes it to EDIDC/EDID4.
- Check the resulting IDocs in WE05 or WE02 for status; a status of 03 means dispatched to the port, not necessarily received.
Key data objects
- EDIDC - the IDoc control record: message type CREMAS, sender and receiver logical system, direction, and current status.
- EDID4 - the IDoc data segments, including the E1LFA1M and related segments carrying the actual vendor field values sent.
- EDIDS - the status history record for each IDoc, one row per status change from generation through dispatch.
- LFA1, LFB1, LFM1 - the general, company-code, and purchasing-org vendor master tables read to build the outbound segments; nothing here is written, only read.
How to prove it in the data
Run SE16 on EDIDC filtering MESTYP equal to CREMAS, DIRECT equal to 2 for outbound, and the relevant date and time range around when BD14 was executed. Note the DOCNUM values returned, then check EDIDS for those DOCNUM entries to see the sequence of status codes reached; a stall at 30 points to port or RFC destination issues, a stall at 51 points to application errors on the receiving side. Cross-check the vendor number inside EDID4 (segment E1LFA1M) against LFA1 to confirm the sent data matches current master data.
ECC vs S/4HANA
BD14 still exists on S/4HANA and still generates CREMAS IDocs the same way. The underlying complication is that vendor master data on S/4HANA is modeled through business partners, so the classic vendor tables read by BD14 are kept in sync with business partner data by the system, and any mismatch between the two representations can surface as incomplete or stale segments in the outbound IDoc. There is no Fiori app replacing BD14; it remains a backend ALE transaction.
Common pitfalls and how to diagnose them
- Distribution model gap: BD14 runs without error but no IDoc reaches the target because BD64 has no filter or message type entry linking sender to receiver for CREMAS. Check BD64 first, before touching partner profiles.
- Missing or misconfigured partner profile: an IDoc is created in EDIDC but sits at an early status because WE20 has no outbound parameter for the receiving logical system, or the port referenced in WE21 is wrong or inactive.
- Filtered segments: the IDoc is delivered but the receiving system rejects or ignores it because organizational filtering in the distribution model excluded the company code or purchasing org the vendor belongs to, so required segments never populate.
- Confusing full send with delta replication: someone runs BD14 repeatedly expecting it to pick up only changed vendors; it sends the full current record every time. If the goal is ongoing sync, the fix is enabling change pointers for CREMAS (BD61) and scheduling BD21, not re-running BD14.
- Duplicate or conflicting sends: running BD14 for the same vendor range from two different sessions or batch jobs creates duplicate IDocs, which downstream systems may process as redundant updates or, worse, out-of-order updates if timestamps are close.
- Authorization and extension gaps: a vendor not yet extended to the company code or purchasing org selected produces an incomplete IDoc rather than an error, which looks like a successful send until the receiving side complains about missing data.
Whose problem this is
Functional MDM or FI/MM master data ownership covers the distribution model content and message type scope; Basis owns ports, RFC destinations, and partner profile technical settings; ABAP gets involved only if a user exit or IDoc segment enhancement is filtering or transforming data unexpectedly. A good handover includes the vendor number range affected, the IDoc numbers from EDIDC, and the status history from EDIDS.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/bd14ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.