CDPOS table — Change Document Items

CDPOS stores field-level before-and-after values belonging to a change-document header. Each row must be interpreted using the complete technical key and the application process that writes it. A consultant should first establish whether the row represents current state, a dated master-data slice, a document item, a history event, an index entry or a compatibility representation. Organizational levels, validity dates, fiscal years, ledgers, languages, statuses and sequence numbers are part of the grain whenever those dimensions exist. The table should be read as evidence of application behavior, not as an isolated spreadsheet. Confirm the owning business object and configuration before deciding that a value is wrong.

Read OBJECTCLAS, OBJECTID and CHANGENR together with TABNAME, TABKEY and FNAME to identify which field change belongs to which recorded business object. Tab keys are encoded and must be interpreted using the affected table definition.

Correlate change items with CDHDR using object class, object ID and change number (and client when relevant). CDPOS can contain multiple changed fields per change header, so joining and then counting headers may multiply events.

When investigating an unexpected material, vendor or sales-order field change, start with the business object and its change-document class. Read the CDHDR time/user context, then isolate the CDPOS field and old/new values to avoid blaming unrelated updates.

Take one reproducible example from the relevant SAP screen, report or application log. Record its full displayed key, organizational context, key date, language and status. Locate the matching CDPOS row using those values, then follow the documented parent and child joins without dropping key components. Compare the result using the same key date and ledger. When values differ, test for leading-zero conversion, multiple validity slices, inactive history, parallel ledgers, fiscal-year boundaries, archived data and asynchronous replication. Save the read-only evidence before escalating. If the row is wrong, reproduce the maintenance path in a non-production system and route the fix to the application owner rather than changing the table.

CDPOS remains the standard field-level change-document store in S/4HANA for applications using the classic change-document framework. Some applications additionally expose change history through dedicated logs or CDS views, so CDPOS coverage is application dependent.

The functional owner establishes whether the change was authorized. ABAP/application support traces the change-document object and enhancement behavior, while security investigates confirmed unauthorized access.

Review CDPOS with its connected SAP objects rather than in isolation. The main related objects in this draft are C, D, H, D, R, |, D, D, 0, 2, L, |, D, D, 0, 3, L. Relationship direction and cardinality depend on the full key and application context, so every graph link should be used as a navigation aid and confirmed against the installed release before it becomes production extraction logic.