CDS Compatibility Views in S/4HANA

When SAP restructured the persistence layer for S/4HANA, several classic transparent tables lost their physical form. Financial line items moved into the single universal journal table, and material movement data moved into a single wide document table. To avoid breaking every piece of custom ABAP that ever did a direct SELECT against BSEG or MSEG, SAP renamed the underlying tables and put a CDS view in their place carrying the original table name and the original field list. From the outside, an old SELECT statement sees the same structure it always did. The structural fact that explains almost every downstream problem: this is a read-oriented compatibility shim, not a like-for-like replacement. It reproduces field values through joins, unions and case logic against the new tables, so it can be slower than the original table, it can behave differently under buffering, and in most cases it does not support INSERT, UPDATE, DELETE or MODIFY the way a real transparent table did.

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 custom finance report built years before the S/4HANA conversion runs a direct SELECT against BSEG to pull open items for a reconciliation check, and a separate custom correction program occasionally does a targeted UPDATE against BSEG to fix a flagged posting flag. Both pass UAT: the reconciliation report returns correct figures against a handful of test documents, and the correction program is only exercised against one or two records by the tester. After go-live, at month-end close, the reconciliation report runs against the full year's line items and times out because the view resolving BSEG against the universal journal now does far more work per row than the old table did. In the same close cycle, the correction program fires against a batch of real postings and dumps immediately, because the compatibility view rejects the UPDATE outright. Neither failure was visible in a small, low-volume, read-light test environment; both were guaranteed by the nature of the object once the code hit production shape and production timing.

Compatibility views exist purely to get an ECC-era codebase through a technical conversion without an immediate rewrite; they are not part of the target architecture and are explicitly discouraged as a basis for anything new. Under a clean core approach, custom development should never reference the old table name at all; it should consume the released CDS view entities that SAP provides for the same business data, or a RAP-based custom business object where extension is needed. SAP has not published a hard removal date for these compatibility layers, but treating them as permanent is the wrong assumption; each S/4HANA upgrade project should carry a task to inventory remaining direct references to converted tables and retire them, rather than letting them accumulate as technical debt that resurfaces at the next conversion or upgrade.

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.