BDCP table — Change Pointer Table for ALE Distribution

A row in BDCP represents a single field change, on a single change document, that is relevant to a single ALE message type. When a change document object is configured for change-pointer-based distribution and a field flagged as relevant to that object changes, the standard change document logic writes one BDCP entry for each combination of changed field and active message type. The row carries the change document number, the changed table and key, the field name, and the message type it is relevant for. It sits between the change document tables (CDHDR and CDPOS) and the outbound IDoc. The periodic change pointer processing job reads unprocessed BDCP rows for a given message type, groups them by object, and triggers IDoc creation, then marks the rows processed. A row existing does not guarantee an IDoc was ever generated correctly downstream.

Always filter on MANDT and on MESTYP before touching this table in a productive system; an unrestricted select can return millions of rows in a system with heavy master data churn and no active reorganization job. STATUS is the next filter to add, since most investigations only care about unprocessed rows waiting for the change pointer report, or a specific window of already-processed rows around an incident time. UDATE combined with UTIME lets a narrow time window replace a full table scan when chasing a single incident. TABNAME plus a partial match on TABKEY is the fastest way to find every pointer generated for one specific business object without decoding CHANGENR first.

Symptom: a customer master change made this morning has not appeared as an outbound IDoc to the receiving system. Select BDCP where MANDT equals the client, TABNAME equals the master table, TABKEY contains the customer number, and MESTYP equals the expected message type. If no row exists, the field that was changed is not configured as relevant for change pointers on that message type, or the change document object itself was never triggered. If a row exists with STATUS still unprocessed, the change pointer report has not run for that message type since the change was made.

BDCP is unchanged in shape and still actively written and read in S/4HANA wherever classic ALE change-pointer-based distribution is still configured for a given master data object. There is no compatibility view replacing it because it is not a classic dictionary-only ECC artifact being retired; the underlying mechanism is still supported. What has shifted is architectural preference: many new integration scenarios on S/4HANA favor event-based outbound triggers or API-based replication instead of configuring new change pointer objects, so BDCP activity is increasingly limited to legacy master data distribution flows carried forward from ECC rather than newly designed interfaces.

The functional team responsible for master data distribution, usually whoever owns the ALE or IDoc configuration for that master data object, owns whether change pointers are activated correctly for a given message type and field. The integration or interface team owns diagnosing why a processed pointer did not become a successful IDoc downstream. Basis owns the scheduling and health of the change pointer processing and reorganization jobs, since an unrun reorg job is a basis-side scheduling gap, not a configuration gap.

CDHDR and CDPOS record the change document that generates a BDCP row and are the first place to confirm a change was actually captured. BDCPS carries per-message-type or per-receiver status for a pointer where processing needs to be tracked independently. EDIDC and EDIDD hold the outbound IDoc control record and segment data produced once a change pointer is processed. Configuration for which fields and message types generate change pointers is maintained through the standard ALE customizing transactions for activating change pointers globally, per message type, and per field.