SAP Change Documents: CDHDR, CDPOS and the Change Document Framework

The change-document framework is generated around a change-document object. Application code supplies old/new data to generated write logic, which creates a CDHDR header with object class, object ID, user, date/time, transaction context and change number, plus CDPOS items for changed tables/keys/fields and old/new values where supported. Because TABKEY is a serialized technical key and values are stored generically, interpretation requires DDIC knowledge. Some changes are summarized, filtered, archived or represented differently depending on object configuration and field change-document flags.

Use change documents when support, audit or a business process needs a standard field-change history for an object that participates in the framework. Use generated change-document objects for custom business data where auditability is required and direct before/after persistence would otherwise be invisible. Do not query CDPOS broadly by field name across production without restrictive object/date filters; it can be very large. For compliance-grade auditing, confirm whether change documents satisfy retention and coverage requirements or whether security audit logs/application-specific logs are also required.

CDHDR/CDPOS are cross-application technical tables consumed by 'Environment > Changes' style displays, report tools and audit extractors. They are different from table logging, application logs (BAL), workflow history, IDoc status, and database redo/audit mechanisms. CHANGEDOCUMENT_READ* function modules can read the framework without custom table-key parsing. Archiving can move older change documents out of the online tables, so absence from current CDPOS may be a retention issue rather than proof of no history.

A customer credit field appears to have changed unexpectedly. Support captures the business object's change-document class and key, finds the relevant CDHDR entries for the time window, then reads CDPOS for the change number. The history identifies the user, transaction and old/new field values. A second field has no entry; investigation shows that field is not flagged/registered for change-document logging. The team does not conclude that the field was never modified just because CDPOS is silent.

The classic change-document framework remains widely used in S/4HANA, including by standard business objects and custom on-stack extensions. Fiori apps may surface history through service-specific views, but the backend can still use CDHDR/CDPOS. Clean-core development should use released change-history mechanisms for standard objects rather than directly instrumenting SAP-owned tables.

Application/ABAP teams define and write custom change documents; functional owners decide audit-relevant fields. Security/audit teams define retention and evidence requirements. Basis/data-volume management teams support archiving/performance when CDPOS grows very large.

CDHDR and CDPOS table pages cover exact table semantics. CHANGEDOCUMENT_READ and CHANGEDOCUMENT_READ_HEADERS provide programmatic access. SLG1/BAL is for operational application messages, not field-level before/after history.

Production verification: Capture change-document object class, business object ID, change number, user, date and time, table, key and field, plus retention or archive context. Use standard change-document readers where possible and distinguish missing logging configuration from evidence that no business change occurred.

Operational readiness: For production readiness of SAP Change Documents: CDHDR, CDPOS and the Change Document Framework, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.