Change pointers · Change Pointer Coverage Auditor
Duplicate change pointers for the same change (retry anomaly)
- Default severity
- Major
- Finding code:
- CP_RUNTIME_DUPLICATE_POINTER
- Engine version:
- 2.1.0
What this finding means
Change Pointer Coverage Auditor reports this finding with the default severity “Major”.
About the engine: BD21/BD52 change pointer config & event trigger validation
How to fix it
Several BDCP2 pointers exist for the same change document item (message type, table key, field, change number): the update task was retried or the change was posted twice, which creates duplicate IDocs. Find the retry source (SM13 update requests, custom re-posting), reorganise the duplicates with RBDCPCLR2 and make the receiver idempotent.
How ERP Preflight detects it
The analysis is deterministic: the same exported files and the same knowledge snapshot always produce the same findings. No SAP system connection is required — you upload exports.
- Engine
- Change Pointer Coverage Auditor
- Accepted formats
- JSON, CSV, TEXT
- What to export
ALE change pointer configuration: JSON {'target_message_type', 'bd61_active', 'bd50_msg_types', 'bd52_fields', 'expected_fields', 'dd04l_metadata', 'bdcp2_samples', 'change_documents', 'bd53_reduced_fields'} or a record-type CSV (BD61/BD50/BD52/DD04L/BDCP2/CDPOS rows).
- Required input
- message type (target_message_type or active BD50 entry)
- BD52 field configuration
- Evidence
- Each finding points to the artifact path, line and column, the code snippet and the SHA-256 of the uploaded file. Findings without such a pointer are demoted to confidence UNKNOWN.
- Confidence
- Each finding names the knowledge it relies on (Standard message type field profiles / change document objects) and is capped by that source’s verification status.
- Knowledge sources
- Standard message type field profiles / change document objects — curated, not verified against the source
- Target releases of the engine
- S4H_2022, S4H_2023, S4HANA_CLOUD_2402, S4HANA_CLOUD_2408
Related findings
- MajorBusiness change without the expected change pointer (expected vs observed)
- MajorUnprocessed change pointer backlog (BDCP2)
- CriticalChange pointers globally deactivated (BD61)
- CriticalMessage type change pointers inactive (BD50)
- MajorCustom field omitted from BD52
- MajorData element not change-document relevant
Terms used on this page
Background reading
- Change pointers and BD52: why master data changes are not distributedHow ALE change pointers work end to end — global activation, message type activation, BD52 field assignment and BD21 processing — and the configuration gaps that silently stop IDoc distribution.