S/4HANA: Compatibility-представления и изменённые объекты

В SAP S/4HANA знакомое имя таблицы ещё не доказывает, что сохранились её прежнее физическое хранение, уровень детализации и правила записи. В ряде сценариев перехода SAP оставляет слой совместимости для чтения старых объектов, тогда как актуальная модель хранит и связывает данные иначе. Поэтому сначала нужно определить конкретный объект и релиз, а уже затем выбирать интерфейс чтения или изменения.

Что делает compatibility view#

Если для объекта действует compatibility view, запрос по связанному имени может быть перенаправлен системой на представление. Оно формирует результат из новой модели данных; приложение при этом записывает данные в базовые объекты новой модели, а не в представление. Пример SAP LT Replication Server показывает перенаправление COEP на V_COEP, которая использует ACDOCA и другие объекты. Это пример конкретного сценария, а не правило, что каждое поле старой таблицы тождественно одноимённому полю ACDOCA.

В Simplification List для S/4HANA 2025 FPS01 приведены, например, пары COEP → V_COEP и старые объекты Asset Accounting → соответствующие представления. В том же документе для некоторых семейств Material Ledger указаны границы поддержки по релизам: часть объектов после определённой версии уже obsolete и не допускает доступа. Нельзя переносить состояние конкретного объекта или таблицы из одного релиза на весь продукт.

Наблюдение	Что можно заключить	Что нужно проверить отдельно
Старый объект доступен через compatibility view	Для указанного сценария может сохраняться совместимость чтения	Физические источники, преобразования полей, пропуски и уровень детализации результата
View совпадает именем с прежней таблицей	Старый SQL-путь может продолжать работать	Существует ли такой view именно в целевом релизе и поддерживает ли нужный сценарий
В новой модели есть `ACDOCA` или другой основной объект	Данные консолидированы или перестроены в новой модели для части сценариев	Какие дочерние процессы, статусы и значения не покрывает прямое чтение этого объекта
Объект помечен obsolete или удалён	Старый путь больше не является допустимым контрактом в затронутом релизе	Предлагаемая SAP альтернатива и работы по конверсии для конкретной системы

Совместимость чтения не означает совместимость записи#

SAP описывает compatibility views как средство поддержать определённые SELECT-сценарии. Ведение данных идёт через новую модель и прикладную логику. Для таблиц и представлений, перечисленных в Simplification List, стандартная запись INSERT, UPDATE, DELETE или MODIFY удалена либо пользовательский код должен быть адаптирован. Это не разрешение модифицировать базовую таблицу напрямую.

Для изменений используйте поддерживаемую прикладную операцию: released API, BAPI, транзакцию или другой документированный механизм подходящего продукта и редакции. Указанный здесь класс интерфейса не выбирает конкретный API: его существование и контракт нужно подтвердить по релизу, доступности и сценарию. Неизвестный объект, собственная таблица Z* или решение стороннего поставщика требует отдельного анализа.

Compatibility views и CDS VDM решают разные задачи#

Compatibility view помогает сохранить некоторые старые технические пути чтения после изменения модели. Виртуальная модель данных (VDM) на базе CDS представляет бизнес-данные с семантической структурой для аналитики и API. Эти механизмы связаны с CDS-технологией, но считать любой CDS view старой таблицы опубликованным интерфейсом нельзя.

Для повторного использования модели SAP проверьте release status и stability contract. В документации S/4HANA 2025 FPS01 SAP рекомендует released CDS views; объекты со статусом Not Released или Deprecated могут изменяться, удаляться и быть недоступны. View Browser помогает найти представление, проверить его тип, поля, аннотации, поддерживаемые возможности, состояние и successor. Состав и статус проверяйте в целевой системе и редакции.

Отдельно проверьте выгрузку и репликацию#

Совместимость внутри ABAP-системы сама по себе не гарантирует тот же результат у внешнего потребителя. Руководство SAP LT Replication Server предупреждает: после установки или обновления на S/4HANA для некоторых перенаправленных таблиц в репликации могут понадобиться дополнительные базовые таблицы. Набор действий зависит от релиза исходной системы, DMIS, механизма захвата изменений и целевой платформы.

Для существующей SLT-конфигурации документ описывает проверку Identify Redirected Tables After Source System Upgrade в LTRC. Для ODP требуется отдельно определить базовые таблицы, включённые в compatibility view, и добавить их в конфигурацию источника и BW; воспроизвести view в BW описанный путь не позволяет. Это инструкция о конкретных вариантах SAP LT/ODP, не универсальный рецепт для любого CDC, API, BW или EDWH.

Перед проектированием выгрузки зафиксируйте объект-источник, таблицы и views в фактической системе, версию коннектора, логику CDC, удаление и сторнирование, порядок событий, права и целевой уровень детализации. Сверьте результат с прикладным отчётом или официальным extractor/API и проведите контрольные суммы и выборочные трассировки. Не делайте вывод о полноте только из того, что старый SELECT выполняется.

Порядок анализа конкретного финансового объекта#

Зафиксируйте редакцию, релиз, FPS/SPS и источник данных, включая коннекторы репликации.
Найдите simplification item и объект в документации именно для исходного и целевого релизов; проверьте, является ли прежний объект таблицей, compatibility view или obsolete.
Определите семантику, гранулярность, фильтры, объединения, единицы, валюты, статусы и период действия значений. Сопоставьте результат с новой моделью, а не только по имени поля.
Разделите чтение и запись. Для разработки выберите документированный интерфейс; не используйте compatibility view как write API.
Для интеграции подтвердите базовые таблицы, delta/change capture и поведение после обновления. Повторите проверку после изменения релиза или коннектора.
Измерьте производительность на целевой системе и реальном профиле запросов. Не выводите её из названия объекта или из факта успешного чтения.
Сохраните доказательства: версия источника, решение по каждому объекту, схема преобразования, тестовые суммы и открытые ограничения.

Этот материал частично покрывает S4-09. Документы относятся к SAP S/4HANA On-Premise 2025 FPS01 и SAP LT Replication Server guide version 1.9 от 2026-10-07. Запись sidecar-источников имеет статус metadata_only: модель customer system, список реально перенаправленных объектов, SQL-план, репликация и runtime не проверялись. Для Private Edition подтвердите релиз и допустимый интерфейс в контрактной документации и SAP Help.

Связанные материалы#

In SAP S/4HANA, a familiar table name does not prove that its earlier physical storage, grain, or write rules remain unchanged. In some transition scenarios, SAP keeps a compatibility layer for reading legacy objects while the current model stores and relates data differently. Identify the exact object and release before choosing a read or change interface.

What a compatibility view does#

When a compatibility view is defined for an object, access by the associated name can be redirected by the system to the view. The view derives its result from the new data model; the application writes to the underlying objects of that model, not to the view. The SAP LT Replication Server guide illustrates COEP redirected to V_COEP, which uses ACDOCA and other objects. This is one scenario, not a rule that every old table field is identical to a field with the same name in ACDOCA.

The SAP S/4HANA 2025 FPS01 Simplification List includes, for example, COEP -> V_COEP and older Asset Accounting objects -> corresponding views. The same document marks some Material Ledger object families as obsolete after particular releases, with access no longer allowed. Do not apply one object's status or release boundary to the whole product.

Observation	What can be concluded	What must be checked separately
A legacy object is available through a compatibility view	Read compatibility may remain for the documented scenario	Physical sources, field transformations, omissions, and result grain
The view has the former table name	An old SQL read path may still work	Whether the view exists in the target release and supports the required scenario
The new model contains `ACDOCA` or another central object	Data is consolidated or reshaped for some scenarios	Which sub-processes, statuses, and values direct access to that object does not cover
An object is marked obsolete or removed	The old path is no longer a valid contract for the affected release	SAP's proposed alternative and conversion actions for the specific system

Read compatibility does not imply write compatibility#

SAP describes compatibility views as a means of supporting particular SELECT scenarios. Data maintenance goes through the new model and application logic. For tables and views listed in the Simplification List, standard INSERT, UPDATE, DELETE, or MODIFY access has been removed, or customer code must be adapted. This is not permission to modify the underlying table directly.

For changes, use a supported application operation: a released API, BAPI, transaction, or other documented mechanism for the appropriate product and edition. This list of interface types does not select a specific API; its availability and contract must be confirmed for the release and scenario. An unknown object, a customer Z* table, or a partner solution needs separate analysis.

Compatibility views and CDS VDM serve different purposes#

A compatibility view can preserve some older technical read paths after a model change. The virtual data model (VDM), based on CDS, represents business data with semantic structure for analytics and APIs. The mechanisms are related to CDS technology, but a CDS view over a legacy table is not automatically a released interface.

For reuse, check the release status and stability contract. In the S/4HANA 2025 FPS01 documentation SAP recommends released CDS views; views marked Not Released or Deprecated may change, be removed, or be unavailable. View Browser helps find a view and inspect its type, fields, annotations, supported capabilities, status, and successor. Verify the available set and status in the target system and edition.

Check extraction and replication separately#

Compatibility inside an ABAP system does not by itself guarantee the same result for an external consumer. The SAP LT Replication Server guide warns that, after an S/4HANA installation or upgrade, replication may need additional underlying tables for some redirected tables. The required actions depend on the source release, DMIS version, change-capture mechanism, and target platform.

For an existing SLT configuration, the guide describes Identify Redirected Tables After Source System Upgrade in LTRC. With ODP, identify the underlying tables in the compatibility view and add them to the source and BW configuration; the documented route cannot recreate the view in BW. This applies to particular SAP LT/ODP combinations, not as a universal recipe for every CDC, API, BW, or EDWH implementation.

Before designing an extraction, record the source object, tables and views in the actual system, connector version, CDC logic, deletion and reversal handling, event order, authorizations, and target grain. Reconcile the result with an application report or official extractor/API, then test totals and sample traces. A successful legacy SELECT alone does not prove completeness.

A practical review for a finance object#

Record the edition, release, FPS/SPS, and source system, including replication connectors.
Find the simplification item and object for both source and target releases; determine whether the former object is a table, compatibility view, or obsolete.
Establish semantics, grain, filters, joins, units, currencies, statuses, and effective periods. Compare the result with the new model, not only field names.
Separate reading from writing. Choose a documented interface for development; do not treat a compatibility view as a write API.
For integration, confirm underlying tables, delta/change capture, and upgrade behavior. Repeat the check after a release or connector change.
Measure performance on the target system and a representative query profile. Do not infer it from an object name or a successful read.
Keep evidence: source version, object-by-object decision, mapping, reconciliation totals, and open limitations.

This material partially covers S4-09. The documents refer to SAP S/4HANA On-Premise 2025 FPS01 and SAP LT Replication Server guide version 1.9 dated 2026-10-07. Sidecar source records are metadata_only: customer objects, actual redirects, SQL plans, replication, and runtime were not checked. For Private Edition, verify the contracted release and supported interface in its documentation.