BDCPS table — Change Pointer Processing Status per Message Type

BDCPS stores the ALE change pointer processing status for a message type. When the change pointer collection report runs (typically scheduled as a batch job per message type), it reads pending entries from BDCP and needs to remember that a run is in progress so a second, overlapping execution for the same message type does not pick up and resend the same pointers. One row in BDCPS represents the current processing state for one message type: essentially whether collection is locked or free for that message type. It is a technical bookkeeping table, not a business data table - it carries no information about which object changed, which document was affected, or what the old and new values were. Those details live entirely in BDCP. BDCPS exists purely to serialize and track the collection runs.

Only two fields can be stated with confidence without checking the dictionary directly. Beyond client and message type, the table is understood to carry a processing lock or status indicator used internally by the change pointer collection logic, but the exact field name for that indicator should be confirmed in SE11 rather than assumed, since guessing it wrong is worse than leaving it undescribed.

The joins that matter in practice all run through the message type, since that is the only column shared with confidence across the change pointer landscape. BDCPS is never queried alone in a diagnostic - it is always cross-checked against BDCP to see whether pointers are actually piling up for the message type in question, and against the partner profile outbound parameters to see who is meant to consume the resulting IDoc.

The table is client-dependent and trivially small - one row per active message type, so at most a few dozen or a few hundred rows in a typical system. There is no selectivity problem here; the issue is never performance, it is interpretation. Always restrict by MANDT and MESTYP together when looking at a specific interface. Do not draw conclusions from BDCPS in isolation - its value only comes from being read alongside BDCP counts and job logs for the change pointer collection program.

Symptom: change pointers for a message type keep accumulating and no new IDocs are being generated even though the collection job is scheduled and apparently running. Select BDCPS for MANDT and the affected MESTYP. If the status/lock indicator shows a run still marked as active while no corresponding job is actually executing, a previous run died mid-processing and left the message type locked, which is why every subsequent scheduled run for that message type is silently skipping.

BDCPS belongs to the classic ALE change pointer mechanism, which remains available as a supported outbound distribution technique on S/4HANA the same way it existed in ECC. There is no compatibility CDS view associated with it, since it is a technical control table rather than an application-facing one, and its structure and role are not documented as having changed materially across releases.

This table is small and looks simple, which invites shortcuts that cause real damage in a live interface.

This is ALE/interfaces technical territory, owned by whoever configures and monitors change pointer activation and the collection job schedule, not by the functional consultant of the sending module. When a business team reports that master data changes are not reaching an external system, the first stop is the interface/ALE team checking BDCP and BDCPS together, before escalating to the functional side to check the actual master data change.

BDCP holds the individual change pointer entries this table tracks the processing status for, BDCP2 is the equivalent for reduced message types, and EDIDC, EDIDD and EDID4 hold the IDoc control and segment data produced once the collection report converts a pointer into an outbound IDoc. The change pointer collection program is normally scheduled per message type, and change pointer activation itself is maintained through standard ALE distribution model and message type activation configuration.