BD21 — Create IDocs from Change Pointers
BD21 runs the report that reads open change pointer entries for a chosen ALE message type and converts them into outbound IDocs. It does not create change pointers itself; those are written earlier when a monitored field on a monitored table changes. If change pointers were never activated globally or for that message type, BD21 will run cleanly and produce nothing, which is the single most common source of confusion around this transaction.
BD21 is the selection and conversion step in SAP's ALE change pointer mechanism: it turns accumulated change pointer records into IDocs for a specific message type. This page covers the prerequisite activation chain that must be in place before BD21 can do anything, the tables it reads and writes, and the diagnostic order for when master data changes in SAP but no IDoc appears downstream.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,260 words
Purpose
BD21 executes the standard report that selects unprocessed change pointer entries for a given ALE message type and generates outbound IDocs from them. Change pointers are written automatically whenever a change document is created for a table field flagged as relevant, provided change pointer processing is switched on globally and for that message type. BD21 sits downstream of that writing step: it does the conversion, not the detection. The structural fact that causes most confusion is that BD21 only processes pointers that already exist in the change pointer table; if the activation chain upstream is incomplete, the transaction executes without error and simply finds zero records, which looks identical to a genuine 'no changes happened' situation from the user's side.
When it is used
BD21 is used in classic ALE distribution scenarios where master data changes made in one system need to propagate to another via IDoc, typically material master, customer master, vendor master or classification changes feeding a legacy or satellite system. It is reached for when a scheduled batch job that normally triggers this same report has failed or been skipped, and someone needs to force a manual catch-up run for a specific message type after confirming a change was made. In current landscapes with Fiori and API-based integration, this is not the tool of choice for new interfaces; it is maintained because legacy ALE flows built years ago still depend on it, and a consultant encounters it almost exclusively while triaging a broken existing distribution, not while designing a new one.
How to use it in practice
- Confirm change pointers are active globally (this is a system-wide switch, checked separately, not inside BD21 itself).
- Confirm the specific message type is activated for change pointer processing; if not, BD21 will find nothing regardless of how many master data changes occurred.
- Call BD21 and enter the message type in the selection field.
- Execute; the report selects all unprocessed change pointer entries for that message type and builds IDocs from them.
- Review the resulting IDoc numbers, either from the list the report returns or by checking the IDoc overview afterward.
- If nothing is generated, do not rerun BD21 repeatedly; instead check whether the underlying change document was ever created and whether the field changed is one flagged for pointer generation.
Key data objects
- BDCP - the change pointer table itself, one row per detected change per message type, holding the change document object, the changed table key, and a processed flag that BD21 flips once an IDoc has been generated from that entry.
- BDCPS - the per-message-type activation status, read to decide whether BD21 has anything eligible to process for that message type at all.
- CDHDR and CDPOS - the underlying change document header and item tables; a change pointer only gets written if a change document entry exists here for a monitored field.
- EDIDC and EDIDD - the IDoc control record and data segments created as the output of a successful BD21 run, one new IDoc per selected change pointer batch.
How to prove it in the data
Start in SE16 on BDCP filtered by the message type in question and the processed indicator unset; a nonzero result confirms pointers are waiting and BD21 should find them. If BDCP is empty for that message type despite a known master data change, check CDHDR and CDPOS for the same object key and change date to confirm a change document was even written, then check BDCPS to confirm the message type is flagged active. If BDCP shows entries but BD21 still produces no IDoc, check the partner profile and distribution model for that message type and receiver rather than assuming BD21 itself is broken.
ECC vs S/4HANA
BD21 and the underlying ALE change pointer mechanism are unchanged on S/4HANA; there is no functional redesign and no dedicated Fiori replacement, since this is infrastructure for classic IDoc-based distribution rather than a business process with its own user-facing app. Newer integration scenarios on S/4HANA favor event-based or API-based patterns over change pointers, so BD21 mainly appears in landscapes carrying forward legacy ALE distribution after a technical conversion, not in newly built S/4HANA interfaces.
Common pitfalls and how to diagnose them
- Change pointers never written: the most common category. Diagnosed by an empty BDCP for the message type and time window in question, usually traced back to change pointer processing not being active globally or for that specific message type, or the changed field simply not being one of the fields flagged as pointer-relevant for that message type.
- Change document exists but pointer does not: happens when the table field was changed but that particular field was never added to the pointer-relevant field list for the message type. Confirmed by finding the entry in CDPOS but not in BDCP. The fix is a configuration change to the relevant field list, not a BD21 rerun.
- Pointer exists but no IDoc generated: BD21 runs, finds the pointer, but produces nothing because the partner profile for that message type and receiver is missing or inactive, or the message type is not in the distribution model for that receiving system. Confirmed by checking the partner profile and distribution model entries directly rather than by rerunning BD21.
- Duplicate or repeated IDoc generation: caused by rerunning BD21 outside its scheduled job while a batch job for the same message type is also running, or by a failed run that generated IDocs but did not correctly flip the processed flag on the pointer, leaving it eligible for reselection. Confirmed by comparing IDoc creation timestamps against the processed flag update time on the pointer entries.
- Performance degradation on large pointer volumes: change pointer tables that are never reorganized accumulate processed entries indefinitely, slowing selection. This is a housekeeping issue, addressed by periodic deletion of processed pointer entries, not by anything within BD21's own selection logic.
Whose problem this is
Functional territory: activation of change pointers globally and per message type, and the field-relevance configuration, belong to whoever owns the ALE distribution setup, often a mix of the relevant functional module owner and a basis or interface team. A good handover states the message type, the object key expected to change, whether BDCP shows an entry, and whether the partner profile and distribution model for the receiver are confirmed active.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/bd21ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.