Пробный переход: воспроизводимые прогоны и финансовые сверки

Пробный переход проверяет не только, можно ли загрузить данные. Он должен показать, какой именно исходный срез преобразовали, по каким правилам, что попало в цель, что было отклонено и почему итоговое расхождение допустимо. Без зафиксированных входа, настроек и эталона повторный прогон нельзя надёжно сравнить с предыдущим.

Зафиксируйте исходный снимок#

Перед извлечением запишите систему, клиент, релиз, компании, ledger, годы и периоды, дату и время среза, включённые типы документов и правила отбора. Укажите, как обрабатываются изменения, проведённые после среза. Для больших выгрузок сохраните манифест файлов с размером и SHA-256; сам хэш подтверждает неизменность зафиксированного файла, но не доказывает его полноту или корректность выборки.

Храните выгрузку и журналы в разрешённом закрытом хранилище. В публичном отчёте или репозитории используйте только синтетические примеры и неперсональные идентификаторы. Не помещайте туда клиентские проводки, данные сотрудников, банковские реквизиты, токены или сертификаты.

Для SAP S/4HANA On-Premise 2025 FPS01 SAP описывает создание проекта в тестовой системе, являющейся копией производственной, и новый проект для следующего тестового переноса с учётом исправлений предыдущего прогона. Это правило относится к документированному процессу Migration Cockpit. Не переносите его автоматически на техническую конверсию, Public Edition или другой инструмент без проверки руководства конкретного релиза.

Версионируйте преобразование и целевую среду#

Каждому прогону присвойте отдельный идентификатор и сохраните:

версии исходной и целевой системы, клиента и используемых компонентов;
снимок целевой тестовой системы и существенные настройки, влияющие на результат;
идентификаторы проекта, объекта и экземпляров миграции;
версию шаблона, правил отбора, mapping и преобразований;
ревизию кода и конфигурации, если данные обрабатываются внешним инструментом;
владельцев правил, дату утверждения и условия, при которых mapping разрешено менять.

Каждое исправление mapping создаёт новую версию результата. Не заменяйте файлы или правила предыдущего прогона задним числом: иначе нельзя понять, исправил ли результат конкретное изменение или изменился исходный набор данных.

Снимите baseline до преобразования#

Baseline - это контрольные величины, рассчитанные по тому же зафиксированному входу, который будет мигрировать. Сохраняйте итоги на уровне, где видна ошибка: количество и ключи строк, суммы дебета и кредита, валюта и её вид, компания, ledger, финансовый год и период. Для счетов сальдо не заменяет детализацию документа, если от неё зависят открытые позиции или последующая трассировка.

Добавьте профильные контрольные наборы для выбранной области: открытые позиции AP/AR по статусу и сроку, стоимость активов по области оценки, CO-объекты и незакрытые обязательства там, где они входят в переход. Для каждого показателя определите источник, формулу, уровень агрегации, валюту, дату и ожидаемое округление. Не складывайте разные валюты или ledger в один итог без явно определённого правила.

Если цель изменяет представление или семантику данных, зафиксируйте утверждённый способ сравнения. Сопоставьте одну исходную выборку с целевым результатом через конкретную функцию или таблицу соответствий. Одинаковое название отчёта или счета само по себе не доказывает, что показатель в двух системах имеет тот же смысл.

Выполните контролируемый тестовый прогон#

Разделите этапы и сохраните их статусы по каждому объекту: извлечено, загружено в staging, проверено, симулировано, перенесено, отклонено, исправлено и повторно обработано. Фиксируйте количество строк на каждой границе, чтобы локализовать потери и дубликаты.

В Migration Cockpit On-Premise 2025 FPS01 симуляция позволяет увидеть сообщения предполагаемого переноса и не записывает данные в целевую систему. SAP предупреждает, что первая симуляция может выявить дополнительные mapping-задачи; после их обработки симуляцию нужно повторить. Симуляция проверяет конкретный шаг этого процесса и не является доказательством полноты выборки или бизнес-корректности финансового результата.

Для системной конверсии отделяйте результат технической процедуры от прикладного сравнения. SAP Data Transition Validation документирован как средство сравнить бизнес-данные до и после конверсии или при обновлении/апгрейде; его спецификации тестов, извлечения и сравнения нужно настраивать для целевого релиза. Для selective data transition с Business Transformation Center SAP отдельно описывает финансовые проверки согласованности. Это разные сценарии и инструменты, а не единый обязательный шаг для всех видов перехода.

Ведите реестр ожидаемых различий#

До запуска согласуйте список различий, которые могут появиться из-за целевого scope или утверждённого преобразования. Для каждого случая укажите ключ или класс строк, правило, сумму и валюту при необходимости, причину, владельца, подтверждение и срок действия разрешения. При сравнении классифицируйте каждое наблюдение как совпадение, ожидаемое различие, ошибка, дубликат, потеря или неразрешённое исключение.

Различие становится допустимым только по заранее утверждённому основанию. Не создавайте объяснение после обнаружения неудобного остатка и не закрывайте множество разных ошибок одним балансирующим значением. Если список ожидаемых различий изменён, сохраните новую версию и повторно сформируйте результаты сравнения.

Для денежных величин учитывайте валюту, вид оценки, ledger, курс и дату пересчёта, а также точность хранения. Любое допустимое округление должно быть задано до сравнения и не должно скрывать систематическое отклонение. При агрегации проверяйте и общий итог, и распределение по компаниям, периодам и ключевым счетам: равные суммы в целом могут скрыть разнонаправленные пропуски.

Подготовьте воспроизводимый пакет доказательств#

К отчёту о прогоне приложите закрытые или обезличенные ссылки на:

манифест и хэши исходных файлов, границы среза и параметры отбора;
версию среды, миграционного проекта, объектов и mapping;
журналы извлечения, симуляции, переноса, исключений и повторной обработки;
baseline, целевые контрольные величины, алгоритм сравнения и результаты по каждому ключу/агрегату;
реестр ожидаемых различий с версиями и владельцами;
список дефектов, решений, утверждений владельцев финансовых данных и итоговый sign-off.

Короткая запись прогона может выглядеть так:

run_id: rehearsal-02
source_snapshot: sha256:<hash-of-approved-extract-manifest>
mapping_revision: <immutable-version>
target_copy: <test-system-and-client>
project_id: <migration-project>
extraction_cutoff_utc: <timestamp>
baseline_id: <baseline-version>
expected_differences_id: <approved-register-version>
evidence_bundle: <restricted-location>

Значения в примере - поля для заполнения, не реальный SAP-проект или результат переноса. Сам по себе manifest тоже недостаточен: приложите результаты, исключения и решение о готовности.

Повторите прогон и примите решение#

Повторите сравнение после любого изменения исходного среза, целевой версии, объекта, mapping, правила преобразования или настройки, способной изменить финансовый результат. Укажите, что изменилось относительно предыдущей ревизии, и сравните только прогоны с известными входами. При изменении среды или правил заново соберите baseline, если сопоставимость прежнего набора больше не гарантируется.

Перед допуском к cutover подтвердите владельцами бухгалтерского и технического потоков полноту выбранного среза, контрольные суммы, допустимые различия, исправление блокирующих исключений, доступность журналов и процедуру повтора. Статус инструмента «успешно» - только один факт в пакете доказательств, а не итоговое решение о готовности.

Материал частично покрывает MIG-12. Руководства Migration Cockpit относятся к On-Premise 2025 FPS01 и Public Edition 2608; Data Transition Validation приведён для S/4HANA 2023, а Finance Consistency Checks - только для selective data transition с Business Transformation Center. Источники имеют статус metadata_only; извлечённые выдержки и клиентские доказательства не сохранены. SAP-система, миграция, сравнение данных, конверсия, авторизации и sign-off не выполнялись. Практика по baseline и доказательствам является инженерным шаблоном, который требуется согласовать с конкретным проектом и SAP-руководством целевой версии.

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

A transition rehearsal must show more than whether data can be loaded. It should identify the exact source slice, the rules applied, what reached the target, what was rejected and why, and why each remaining difference is acceptable. Without fixed inputs, settings, and a baseline, a rerun cannot be reliably compared with its predecessor.

Freeze the source snapshot#

Before extraction, record the system, client, release, companies, ledgers, years and periods, snapshot time, included document types, and selection rules. State how changes posted after the cutoff are handled. For large extracts, retain a file manifest with sizes and SHA-256 hashes. A hash confirms that a retained file has not changed; it does not prove that the selection was complete or correct.

Store extracts and logs in an approved restricted location. Use synthetic examples and non-personal identifiers in public reports or repositories. Do not place customer postings, employee data, bank details, tokens, or certificates there.

For SAP S/4HANA On-Premise 2025 FPS01, SAP describes creating a project in a test system copied from production and creating a new project for each subsequent test transfer with the previous run's corrections. This applies to the documented Migration Cockpit process. Do not automatically apply it to technical conversion, Public Edition, or another tool without checking the guide for the relevant release.

Version the transformation and target environment#

Assign a separate identifier to every run and retain:

source and target system versions, clients, and relevant components;
the target test-system snapshot and material settings that affect the result;
migration project, object, and instance identifiers;
template, selection-rule, mapping, and transformation versions;
code and configuration revision when an external tool processes the data;
rule owners, approval date, and conditions for changing the mapping.

Every mapping correction creates a new result version. Do not overwrite the previous run's files or rules: otherwise, you cannot tell whether a change improved the result or the input set changed.

Capture the baseline before transformation#

A baseline is a set of control values calculated from the same frozen input that will be migrated. Retain totals at a level where errors are visible: row counts and keys, debit and credit amounts, currency and currency type, company, ledger, fiscal year, and period. A balance does not replace document detail when open items or source-document traceability depend on it.

Add domain-specific controls for the selected scope: AP/AR open items by status and due date, asset values by depreciation area, CO objects, and open commitments where they are part of the transition. For every measure, define its source, formula, aggregation level, currency, date, and expected rounding. Do not combine currencies or ledgers in one total without an explicit rule.

If the target changes the representation or meaning of data, define an approved comparison method. Compare one source selection with the target result through a specific transformation function or mapping table. The same report or account name does not prove that a measure has the same meaning in both systems.

Run a controlled rehearsal#

Separate the stages and retain their status for each object: extracted, loaded to staging, checked, simulated, migrated, rejected, corrected, and reprocessed. Record row counts at each boundary to locate losses and duplicates.

In Migration Cockpit On-Premise 2025 FPS01, simulation shows messages that would occur during transfer and does not write data to the target. SAP notes that the first simulation can reveal additional mapping tasks; after processing them, repeat the simulation. Simulation checks a particular step in this process. It does not prove that the selection is complete or that the financial result is correct.

For a system conversion, separate the technical procedure from application-data comparison. SAP Data Transition Validation is documented as a way to compare business data before and after a conversion or during an update/upgrade; its test specifications, extraction, and comparison must be configured for the target release. For selective data transition with Business Transformation Center, SAP separately describes finance consistency checks. These are different scenarios and tools, not one mandatory step for every type of transition.

Maintain an expected-difference register#

Before the run, agree on differences that may arise from the target scope or approved transformation. For each case, record the key or row class, rule, amount and currency if relevant, reason, owner, evidence, and approval expiry. During comparison, classify each observation as a match, expected difference, error, duplicate, loss, or unresolved exception.

A difference is acceptable only with a reason approved in advance. Do not invent an explanation after discovering an inconvenient balance, or close several different errors with one balancing amount. If the expected-difference register changes, retain a new version and regenerate the comparison results.

For monetary values, account for currency, valuation type, ledger, exchange rate and conversion date, and storage precision. Any rounding allowance must be defined before comparison and must not conceal systematic drift. When aggregating, check both the total and its distribution by company, period, and relevant accounts: equal totals can hide omissions in opposite directions.

Assemble a repeatable evidence bundle#

Attach restricted or redacted references to the run report for:

source file manifest and hashes, snapshot boundaries, and selection parameters;
environment, migration project, object, and mapping versions;
extraction, simulation, transfer, exception, and reprocessing logs;
baseline, target controls, comparison algorithm, and results by key and aggregate;
the expected-difference register with its versions and owners;
defects, decisions, approvals from finance-data owners, and final sign-off.

A compact run record can look like this:

run_id: rehearsal-02
source_snapshot: sha256:<hash-of-approved-extract-manifest>
mapping_revision: <immutable-version>
target_copy: <test-system-and-client>
project_id: <migration-project>
extraction_cutoff_utc: <timestamp>
baseline_id: <baseline-version>
expected_differences_id: <approved-register-version>
evidence_bundle: <restricted-location>

The values are placeholders, not a real SAP project or migration result. The manifest alone is not enough; attach outcomes, exceptions, and the readiness decision.

Repeat the run and decide#

Repeat the comparison after any change to the source snapshot, target version, object, mapping, transformation rule, or setting that can affect the financial result. Record the change from the previous revision, and compare only runs with known inputs. If the environment or rules change so that the previous baseline is no longer comparable, capture a new baseline.

Before cutover, have the finance and technical owners confirm the completeness of the selected slice, control totals, acceptable differences, resolution of blocking exceptions, availability of logs, and rerun procedure. A tool's "successful" status is one fact in the evidence bundle, not the final readiness decision.

This material partially covers MIG-12. Migration Cockpit sources refer to On-Premise 2025 FPS01 and Public Edition 2608; Data Transition Validation is referenced as of S/4HANA 2023, and Finance Consistency Checks apply specifically to selective data transition with Business Transformation Center. Sources are metadata_only; extracted passages and customer evidence were not retained. No SAP system, migration, data comparison, conversion, authorizations, or sign-off was performed. The baseline and evidence process is an engineering template that must be aligned with the specific project and the target-release SAP documentation.