CDS Compatibility Views in S/4HANA

During S/4HANA simplification SAP changed the physical persistence behind a number of classic application tables. To keep older ABAP reads working, SAP provides compatibility interfaces, frequently CDS-based views with the old table name or field shape, that derive legacy-style data from the new persistence model. Well-known examples include the classic material-document names MKPF/MSEG around the MATDOC model and a number of former Finance, New G/L, CO and Asset Accounting structures that are no longer the strategic persistence source. The critical nuance is that this is object-specific: not every classic table became a compatibility view. BSEG, for example, remains a database table and continues to hold the accounting entry view in S/4HANA. Therefore a migration assessment must verify each object against SAP's simplification documentation rather than applying a blanket 'old table equals compatibility view' rule.

There is no scenario where a consultant deliberately designs new development against a compatibility view. It exists purely so that legacy code survives the technical conversion to S/4HANA without an immediate rewrite. The right use of the concept is diagnostic and tactical: when a custom program references a table name that has become a compatibility view, treat that as a flag to assess, not a green light to leave alone. It is acceptable to tolerate the view temporarily for low-volume, read-only, non-critical reporting while a proper fix is scheduled. It is a mistake to build new Z-reports, new interfaces, or new RAP business objects that select from the old table name on the assumption that it still behaves like a table, and it is a serious mistake to leave any write logic pointed at it, because that write will fail at runtime rather than at activation or syntax check.

Below the compatibility view sits the real S/4HANA persistence: the universal journal table for finance, the consolidated material document table for logistics, or whatever new table absorbed the old one's data. Above the compatibility view sits everything that never got rewritten: classic ABAP reports, custom function modules, older BAPIs, and any Z-code doing native SQL against the old table name. It does not supersede anything by itself; it is inserted as a bridge during the data model conversion, standing in for a table that no longer physically exists under that name. It is conceptually adjacent to, but distinct from, the released CDS view entities SAP provides for the same business data, which are properly modeled, association-aware, and intended as the actual long-term interface for new development, unlike the compatibility view which is a technical stopgap.

A converted ECC report reads MSEG for historical goods movements. The code still compiles because S/4HANA preserves legacy read compatibility, but the underlying persistence and optimizer path now come from the MATDOC-based model. Under production volume the old access pattern performs poorly, so the team traces the statement and redesigns the report against a released material-document CDS view. In the same conversion, another FI report reads BSEG. The team does not rewrite it merely because someone assumes BSEG was replaced by ACDOCA: SAP still persists the entry view in BSEG, while ACDOCA supplies the Universal Journal/ledger view. The two cases require different remediation decisions even though both are 'classic table' code.

Compatibility mechanisms exist to reduce immediate custom-code breakage during S/4HANA conversion; they are not the strategic data-access model for new clean-core development. New code should consume released CDS views, business objects and APIs that represent the S/4HANA semantic model. Existing compatibility reads should be prioritized by business criticality, volume and target-release simplification guidance. Some classic tables remain genuine persistence—for example BSEG—so remediation must be evidence-based rather than a wholesale table-name replacement exercise.

This starts as a developer-level finding, surfaced through code scanning during a conversion or upgrade project, but the remediation decision belongs to the architect, since it involves prioritizing rewrite effort against business risk. Functional consultants confirm which reports and batch jobs are business-critical enough to fix before go-live. The handover should list every affected object, whether the usage is read or write, and the target CDS view entity to migrate to.

Read the page on CDS view entities versus classic CDS DDIC views next to understand what the proper replacement target looks like once code is migrated off a compatibility view. The page on performance of nested CDS views is directly relevant to the volume-related failure mode described here, since a compatibility view is itself a nested, joined structure. The page on CDS table functions and AMDP is worth reviewing when the replacement logic needs procedural handling that a plain CDS view entity cannot express.