Change pointers and BD52: why master data changes are not distributed

How change pointers work

Change pointers are the mechanism with which ALE distributes changes to master data (for example material, customer or vendor data) as IDocs. When a relevant field changes, the system writes a change pointer. A report later reads the open pointers and creates IDocs for the configured message type.

For this chain to work, several settings must fit together:

• BD61 — change pointers are activated globally;
• BD50 — change pointers are activated for the message type (for example MATMAS);
• BD52 — the fields whose changes should create change pointers are assigned to the message type;
• BD64 — the distribution model contains the message type for the sender and receiver;
• BD21 (report RBDMIDOC) — processes the open change pointers, usually as a scheduled job.

Why changes are not distributed

• A field was added to the interface but not assigned in BD52, so its changes never create a pointer.
• The message type is not activated in BD50, or change pointers are globally inactive.
• The BD21 job is not scheduled, fails, or runs for a different message type.
• The distribution model has no filter or receiver for the changed object.
• Configuration differs between systems because a transport is missing.

How to analyse it

1. Start from the business requirement: which fields must reach which receiver?
2. Compare that list with the BD52 field assignment for the message type.
3. Check activation (BD61, BD50) and the distribution model in the same system.
4. Verify that pointers are processed: job scheduling and processing status.

ERP Preflight's Change Pointer Coverage Auditor compares required fields with exported change pointer configuration and reports uncovered fields with evidence. See Integration.