Переход на S/4HANA: миграция и тестирование TRM

Сначала определите, какой именно переход планируется#

Словом «миграция» часто называют разные работы, которые нельзя объединять в один чек-лист:

System conversion переводит существующую SAP ERP систему на SAP S/4HANA. Для такого сценария нужны проверки readiness, применимые simplification items, преобразования финансовых данных и адаптация custom code.
Migration Cockpit / Direct Transfer - ERP переносит выбранные данные из исходной ERP в целевую систему через объекты миграции. Наличие объекта не означает перенос всей истории, всех статусов или всех связанных данных.
Staging Table использует промежуточные таблицы и иной маршрут загрузки. Набор объектов зависит от выбранного сценария и доступен в конкретной системе.
TRM Legacy Data Transfer загружает исходные сделки или позиции на дату в Transaction Manager и использует отдельные настройки и последовательности. Это прикладная загрузка legacy-позиций, а не синоним конверсии системы.

Прежде чем проектировать тесты, зафиксируйте исходный и целевой продукт, редакцию, релиз и FPS, тип перехода, source и target системы, активный scope, применяемый migration approach и владельца каждого набора данных. Сверьте список объектов с Migration Cockpit именно целевой системы: опубликованная SAP таблица предупреждает, что список зависит от активированного объёма и выбранного подхода.

Составьте инвентаризацию TRM#

Начните с процессов и открытых обязательств, а не с экспорта всех таблиц. Для каждой категории укажите источник, контрольный ключ, ответственное лицо, целевое представление, метод переноса и проверку результата.

Договорные сделки#

До перехода запишите тип продукта и сделки, компанию, контрагента, внутренние и внешние ключи, статус и дату/событие отсечения. В target сверяйте число сделок и номиналы по компании, продукту, валюте и статусу.

Основные условия и потоки#

Соберите условия, даты и типы потоков и обновлений, платёжные реквизиты и валюту. В target сравните количество и суммы будущих потоков по датам, валютам и типам с графиком договора.

Позиционные значения#

Запишите ключевую дату, valuation area, ledger или правило учёта, инструмент и валюту. В target сравнивайте количество позиций и балансовые/номинальные значения на той же дате и в том же представлении.

Бухгалтерские остатки и история#

Определите переносимые остатки, уже отражённые потоки, FI-документы и последние периоды. Контролируйте балансы и связи документов, а также отсутствие повторной проводки открытых потоков.

Основные данные и Customizing#

Инвентаризируйте business partners и роли, продуктовые типы, типы сделок, потоки и обновления, валюты, valuation areas и счета. До загрузки получите отчёт о полноте зависимостей и сверку настройки source/target.

Расширения и интерфейсы#

Перечислите Z-разработки, модификации, BAdI, API, CDS, прямой доступ к таблицам, задания и файлы. Проверьте результаты ATC/simplification checks, подтверждение используемых интерфейсов и интеграционный тест с журналом.

Зафиксируйте и исключения: закрытые, отменённые, истёкшие или перевёрнутые сделки, ручные операции, hedge accounting, risk limits, correspondence, trade repository и данные, которые специально не переносятся. SAP указывает для отдельных TRM объектов миграции собственные in-scope/out-of-scope наборы; это нужно читать по каждому объекту и точному релизу, а не распространять одну таблицу на весь TRM.

Выберите способ переноса по объекту#

В документации SAP S/4HANA On-Premise есть отдельные Migration Cockpit objects для ряда TRM договоров, потоков, условий, payment details и position values. Например, объект Foreign Exchange Spot/Forward Contract описан как Direct Transfer - ERP и выбирает определённые активные категории сделки. В его пределах указаны договорные данные, иные потоки, платежные детали и расчётные данные; некоторые статусы и виды операций исключены. Для конкретного контракта SAP отдельно перечисляет предшествующие зависимости.

Для этой категории SAP отмечает также, что успешная симуляция создания spot/forward сделки не симулирует settlement. Следовательно, зелёный результат одного этапа не является подтверждением полного цикла.

Используйте такой порядок подготовки:

Для каждого объекта Migration Cockpit откройте release-specific документацию и выпишите отбор, in-scope и out-of-scope данные, prerequisites, симулируемые функции и последующие действия.
Подтвердите фактическое наличие объекта в target system и его migration approach. Не полагайтесь только на статическую общую таблицу SAP.
Проверьте наличие business partners и ролей, авторизаций, Customizing, валютных настроек, продуктовых и потоковых типов и valuation areas до загрузки сделок.
Согласуйте последовательность зависимых объектов. Дополнительные потоки, условия и payment details могут требовать отдельной миграции после основного договора.
Для valuation-area-dependent позиционных значений отдельно подтвердите поддерживаемый маршрут и ключевую дату. SAP Legacy Data Transfer описывает собственный процесс по типу сделки/позиции и целевой дате.
Запустите симуляцию, проанализируйте ошибки, сохраните идентификаторы запусков и контрольные итоги; затем проводите загрузку только в согласованном cutover окне.

Migration Cockpit объекты предназначены для начальной загрузки; они не следует рассматривать как механизм регулярного изменения уже созданных записей. Проверяйте документацию объекта на ограничения, в том числе что именно симулируется.

Предотвратите двойное бухгалтерское отражение#

До переноса согласуйте, какие потоки уже включены в перенесённые финансовые остатки. Документация TRM migration object прямо предупреждает: повторная проводка соответствующих сделочных потоков в принимающей системе способна обновить главную книгу дважды. Для описанного сценария предусмотрена отметка потоков как уже проведённых с созданием posting log; точные доступные действия зависят от объекта и release.

Поэтому контроль строится в обе стороны:

каждый перенесённый остаток имеет согласованный источник и контрольную дату;
поток, уже включённый в остаток, не проводится повторно;
новые незакрытые будущие потоки остаются доступны для штатной дальнейшей обработки;
журнал переноса связывает source key, target transaction, поток, posting log и FI reference;
суммы сверяются в одной валюте, одной valuation area и на одной дате.

Не используйте операцию «отметить как проведённое» без проверки документации выбранного migration object, списка потоков и учётного решения. В некоторых сценариях SAP рекомендует этот шаг для предотвращения двойного баланса; он сам по себе не доказывает существование документа-проводки в target.

Настройки и собственный код проверяются отдельно#

Для сделки с валютным инструментом документация SAP перечисляет среди target prerequisites валюты controlling area и company codes, business partners и авторизации, valuation areas и их инициализацию, продуктовые типы, flow/update types и master agreements. Список приведён как пример и не является исчерпывающим. Зафиксируйте настройки в виде проверяемой матрицы source → target с владельцем и доказательством проверки.

Для custom code SAP S/4HANA Conversion documentation указывает на упрощения продукта и необходимость анализа адаптаций с помощью ATC и Simplification Database. Для TRM отдельно инвентаризируйте собственный код, который читает внутренние таблицы, обращается к заменённым объектам, меняет статус сделки или формирует проводки. Для отчётности рассмотрите документированные CDS-контракты; для создания и изменения данных подтвердите API или application process. Статическая проверка кода не заменяет процессный тест и сверку финансового результата.

План испытаний до и после переноса#

Для каждого сценария используйте одну и ту же выборку, дату отсечения, курсы/рыночные данные и правила округления либо документируйте их различия.

Создание и отбор сделки#

Сверьте счётчик, ключи, компанию, продукт, контрагента и ожидаемые статусы; найдите дубли по внутренним и внешним ссылкам.

График и расчёт#

Сопоставьте условия, сумму и направление, даты валютирования и платежа, календарь и набор потоков.

Переоценка и позиция#

Используйте одинаковую ключевую дату, valuation area, ledger/accounting principle, валюту и входные рыночные данные.

Платёж и проводка#

Проследите цепочку поток → статус фиксации/проведения → payment request → payment result → FI document и исключите повторную проводку.

Отмена и изменение#

Проверьте развороты, частичные расчёты, изменения договора и пересчёт; убедитесь, что миграционный scope включал эти состояния.

Интеграции и расширения#

Проверьте контракты API/CDS, авторизации, расписания, очереди, повторную обработку и журналы ошибок.

Сравнивайте агрегаты и детальные выборки. Минимальный денежный ключ: company code, transaction/activity, valuation area, account assignment или позиция, flow/update type, валюта, ключевая/платёжная/проводочная дата. Любое отличие классифицируйте как ожидаемое преобразование, отсечение по дате, округление/курс, отсутствующий объект, настройка, ошибка миграции, повторная проводка или различие логики. Не закрывайте разницу одной корректирующей суммой без поиска первичных строк.

Установите пороги приёмки до тестового запуска: допустимые расхождения по числу объектов и суммам, нулевые допуски для дублей и необъяснённых проводок, обязательные ссылки на журнал загрузки и процедуру отработки каждого остатка. Выпуск переключения одобряется владельцами TRM и FI только после согласования исключений.

Границы и применимость#

Примеры Migration Cockpit относятся к официальной документации SAP S/4HANA On-Premise; список объектов в источнике зафиксирован для 2025 FPS01. Страница legacy transfer описывает SAP S/4HANA On-Premise 2025 FPS02. Набор объектов и подробные правила могут отличаться между релизами, migration approaches и установленным scope. Release-specific карточка выбранного объекта и его наличие в целевой системе имеют приоритет.

SAP Help metadata исследованы; source/target системы, данные, Customizing, код, прогоны Migration Cockpit, позиции, остатки и SAP runtime не проверялись. Материал задаёт рамку подготовки и тестирования, но не подтверждает, что конкретная TRM-конверсия безопасна или завершена.

Сначала прочитайте сопоставление TRM в ECC и S/4HANA. Затем сверяйте результаты через платёжную цепочку, оценочные представления и TRM-FI-Cash Management.

First identify the transition scenario#

The word "migration" often refers to different work that should not be combined into one checklist:

System conversion converts an existing SAP ERP system to SAP S/4HANA. It requires readiness checks, applicable simplification items, finance data conversion, and custom-code adaptation.
Migration Cockpit / Direct Transfer - ERP transfers selected data from a source ERP system into a target system through migration objects. An available object does not imply transfer of all history, statuses, or related data.
Staging Table uses intermediate tables and a different loading path. The object set depends on the selected scenario and what is available in the specific system.
TRM Legacy Data Transfer loads source transactions or positions into Transaction Manager for a key date using its own settings and sequences. It is an application-level legacy-position load, not a synonym for system conversion.

Before designing tests, record the source and target products, editions, releases and FPS, transition type, systems, active scope, migration approach, and data owner for each set. Check the object list in the target system's Migration Cockpit: SAP warns that the list depends on activated scope and the selected approach.

Inventory the TRM scope#

Start from processes and open obligations, not an export of every table. For each category record the source, control key, owner, target representation, transfer method, and result check.

Contractual transactions#

Before transition, record product and transaction type, company, counterparty, internal and external keys, status, and cutoff date/event. In the target, compare transaction counts and nominal amounts by company, product, currency, and status.

Conditions and flows#

Collect conditions, flow dates, flow and update types, payment details, and currency. In the target, compare future flow counts and amounts by date, currency, and type with the contract schedule.

Position values#

Record key date, valuation area, ledger or accounting principle, instrument, and currency. In the target, compare position counts and balance/nominal values on the same date and in the same view.

Accounting balances and history#

Identify transferred balances, flows already reflected, FI documents, and last periods. Control balances and document links, and confirm open flows are not posted twice.

Master data and Customizing#

Inventory business partners and roles, product and transaction types, flow and update types, currencies, valuation areas, and accounts. Before loading, obtain a dependency completeness report and source/target configuration comparison.

Extensions and interfaces#

List Z developments, modifications, BAdIs, APIs, CDS, direct table access, jobs, and files. Check ATC/simplification results, confirm supported interfaces, and run a logged integration test.

Record exclusions too: closed, reversed, expired, or terminated transactions; manual operations; hedge accounting; risk limits; correspondence; trade repository; and data intentionally left behind. SAP defines individual in-scope and out-of-scope sets for specific TRM migration objects. Read each object for the exact release rather than applying one object's table to all of TRM.

Select a transfer method for each object#

SAP S/4HANA On-Premise documentation lists separate Migration Cockpit objects for selected TRM contracts, flows, conditions, payment details, and position values. For example, the Foreign Exchange Spot/Forward Contract object is documented as Direct Transfer - ERP and selects specific active transaction categories. Its scope includes contract data, other flows, payment details, and settlement data; some statuses and activity types are excluded. SAP lists prerequisites for the particular contract separately.

For this category SAP also states that simulation covers creation of the spot/forward transaction but not settlement. A green result for one step therefore does not confirm the full lifecycle.

Use this preparation sequence:

For each Migration Cockpit object, read the release-specific documentation and record selection, in-scope and out-of-scope data, prerequisites, simulated features, and follow-on activities.
Confirm that the object is available in the actual target system and note its migration approach. Do not rely on a static SAP overview table alone.
Before loading transactions, check business partners and roles, authorizations, Customizing, currency settings, product and flow types, and valuation areas.
Agree the sequence of dependent objects. Additional flows, conditions, and payment details may need separate migration after the base contract.
For position values dependent on valuation area, confirm the supported route and key date separately. SAP Legacy Data Transfer describes its own process by transaction or position type.
Simulate, analyze errors, retain run identifiers and control totals, and then load only in the approved cutover window.

Migration Cockpit objects are designed for initial data loading; do not treat them as a regular mechanism for changing records already created. Check each object's documentation for limitations, including which features are simulated.

Prevent duplicate accounting#

Before migration, agree which flows are already included in the transferred financial balances. SAP's TRM migration-object documentation explicitly warns that reposting transaction flows in the receiving system can update the general ledger twice. In the documented scenario, flows can be flagged as already posted with a posting log; the exact available actions depend on the object and release.

Build controls in both directions:

Every transferred balance has an agreed source and control date.
A flow already included in a balance is not posted again.
New open future flows remain available for normal processing.
The load log links source key, target transaction, flow, posting log, and FI reference.
Amounts are compared in one currency, valuation area, and date.

Do not use "flag as posted" without checking the selected migration object's documentation, the flow set, and the accounting decision. SAP recommends this step in some scenarios to prevent double balances; by itself, it does not prove that an FI document exists in the target.

Validate configuration and custom code separately#

For a foreign-exchange instrument, SAP lists target prerequisites including controlling-area and company-code currencies, business partners and authorizations, valuation areas and their initialization, product types, flow and update types, and master agreements. This example is not exhaustive. Record settings in a source-to-target matrix with an owner and evidence for each check.

For custom code, SAP S/4HANA Conversion documentation identifies product simplifications and the need to analyze adaptations using ATC and the Simplification Database. Separately inventory custom TRM code that reads internal tables, calls replaced objects, changes transaction status, or generates postings. For reporting, consider documented CDS contracts; for data creation or changes, confirm a documented API or application process. Static code checks do not replace process tests and reconciliation of financial results.

Plan tests before and after transition#

For each scenario use the same sample, cutoff date, exchange and market data, and rounding rules, or document differences.

Transaction creation and selection#

Compare counts, keys, company, product, counterparty, expected statuses, and duplicates by internal and external reference.

Schedule and calculation#

Reconcile conditions, amount and direction, value/payment dates, calendar, and flow set.

Valuation and position#

Use the same key date, valuation area, ledger/accounting principle, currency, and market-data inputs.

Payment and posting#

Trace flow -> fixed/posting status -> payment request -> payment result -> FI document, and exclude duplicate posting.

Reversal and change#

Check reversals, partial settlements, contract changes, and recalculation; confirm these states were in migration scope.

Integrations and extensions#

Check API/CDS contracts, authorizations, jobs, queues, retry behavior, and error logs.

Compare aggregate totals and detailed selections. A minimum monetary key contains company code, transaction/activity, valuation area, account assignment or position, flow/update type, currency, and key/payment/posting date. Classify each difference as an expected conversion, cutoff, rounding/rate, missing object, configuration, migration error, duplicate posting, or logic difference. Do not close a difference with a single adjustment amount without finding the source rows.

Set acceptance thresholds before the test run: permitted count and amount differences, zero tolerance for duplicates and unexplained postings, required migration log references, and an owner and resolution path for every open item. TRM and FI owners approve the cutover only after exceptions are reconciled.

Applicability and limits#

The Migration Cockpit examples refer to official SAP S/4HANA On-Premise documentation; the available-object list is for 2025 FPS01. The TRM Legacy Data Transfer page describes S/4HANA On-Premise 2025 FPS02. Objects and detailed rules can vary by release, approach, and installed scope. The release-specific object documentation and actual presence in the target system take precedence.

SAP Help metadata was reviewed; source/target systems, data, Customizing, code, Migration Cockpit runs, positions, balances, and SAP runtime were not inspected. This is a preparation and testing framework; it does not establish that a particular TRM conversion is safe or complete.

Start with TRM in ECC and S/4HANA. Then reconcile results through the payment chain, valuation views, and TRM-FI-Cash Management.