Преобразование финансовой модели при переходе на S/4HANA

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

Определите границу и способ перехода#

При системной конверсии SAP ERP в S/4HANA преобразование встроено в процедуру конверсии и зависит от версии, активных компонентов и применимых simplification items. Это не обычная загрузка миграционных файлов.

При новой реализации или selective data transition задайте целевое состояние и набор данных, который должен его создать. SAP Migration Cockpit использует миграционные объекты; доступные поля, правила и зависимости определяются для выбранного объекта и подхода, например staging или direct transfer. Изучите документацию объекта и целевого релиза, а затем проверьте его поля и область на экране Migration Object.

Для Public Edition Migration Cockpit предназначен для начального набора данных, необходимого для запуска операций; в документации версии 2608 закрытые исторические транзакции отделены от доступных к переносу остатков и открытых операций. Это конкретная граница продукта и версии, а не утверждение о каждом инструменте миграции или о технической конверсии On-Premise.

Зафиксируйте сценарий, исходную и целевую версии, целевые компании и периоды, состав истории, способ загрузки, допустимый cutover-срез и владельца каждого решения. Если способ перехода пока не выбран, сначала разрешите этот вопрос: от него зависят формат целевой модели и смысл результата сверки.

Составьте карту объектов по бизнес-смыслу#

Для каждого объекта создайте строку сопоставления со следующими полями:

Поле карты	Что зафиксировать
Исходный объект	Система, таблица/интерфейс или отчёт, источник полномочий и владелец
Значение и гранулярность	Что представляет запись, ключ, уровень строки и допустимая уникальность
Целевой объект	Миграционный объект или целевая сущность и поддерживаемая версия
Преобразование	Правило преобразования, таблица соответствий, значение по умолчанию и условие исключения
Организационные измерения	Компания, ledger, счёт, контрагент, объект CO и другие используемые назначения
Валюта и время	Код валюты и тип суммы; дата события, документа, проводки, расчёта или снимка
Контроль	Проверка обязательности, домена, связи, итога, дубля и последующей сверки

Сопоставляйте объекты по их роли в процессе и учёте, а не только по похожим названиям полей. Например, account number может быть общим счётом, счётом сверки субледжера или альтернативным идентификатором. Эти понятия нельзя связывать без подтверждённого правила и владельца.

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

Не теряйте гранулярность и документные связи#

До трансформации различите четыре формы данных:

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

Запишите, какие разрезы сворачиваются при переходе к остатку и какие поля остаются в целевой системе для аудита и сверки. Если загрузка формирует бухгалтерские документы из мигрируемых учётных записей, проверьте её posting logic отдельно для этого миграционного подхода. В документации SAP по этой модели перечислены балансирующие позиции и clearing accounts; эту логику нельзя автоматически распространять на конверсию системы или на другой инструмент.

Не загружайте один и тот же актив или субледжерный остаток одновременно через специализированный объект и общий G/L-остаток, если документация и проектное правило не подтверждают такой вариант. Устраните двойной учёт на уровне карты до подготовки файла, а не после расхождения итогов.

Сопоставляйте валюты вместе с суммами#

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

Храните исходное значение и результат преобразования раздельно. Если правила требуют пересчёта, зафиксируйте тип курса, дату определения курса, направление котировки и источник ставки. В SAP документе дата проводки может участвовать в выборе курса; вручную переданное значение курса или отдельная дата конвертации могут менять эту логику. Используйте процедуру выбранного объекта и версии, а не текущий курс на дату теста как неявную замену исторической суммы.

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

Разделяйте смысл дат и периоды учёта#

Дата исходного документа, дата ввода записи и дата проводки обозначают разные события. В документации S/4HANA Cloud дата проводки определяет posting period, а дата документа и дата ввода имеют другие функции. Поэтому не подменяйте все даты одной «датой транзакции».

Для каждой даты укажите исходное поле, бизнес-смысл, часовую зону или правило календаря при необходимости, целевой атрибут и то, влияет ли он на открытый период, срок оплаты, старение задолженности, курс или cutover. Если дата проводки меняется, пересчитайте ожидаемый период и последствия для отчётности; значение по умолчанию не должно случайно перемещать сумму между периодами.

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

Сохраните ссылку с исходным документом#

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

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

Докажите соответствие на тестовом цикле#

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

Проверьте соответствие в нескольких независимых разрезах:

Количество и уникальность исходных и целевых ключей с перечнем исключений.
Итоги по компании, ledger, периоду, счёту, валюте и другим сохранённым измерениям.
Остаток и его детализацию: набор открытых позиций должен сходиться с контрольным остатком согласно принятому правилу.
Документные суммы, валюты, даты и ссылки на исходный документ.
Контрольные и clearing accounts, если их требует конкретный миграционный объект.
Повторный запуск теста на фиксированном снимке: результат и исключения объяснимы и воспроизводимы.

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

Этот материал частично покрывает MIG-06. Документация SAP Migration Cockpit для On-Premise относится к SAP S/4HANA 2025 FPS02, отдельные источники по полям дат и доступному initial dataset относятся к Public Edition 2608, а posting logic миграции цитируется только в границах описанной SAP модели. Источники зарегистрированы как metadata_only; реальные таблицы, mapping, клиентские суммы, миграционный проект и SAP runtime не проверялись.

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

Transforming a financial model is not a mechanical replacement of old codes with new ones. First define what is moving and why: an existing system may undergo a technical conversion with its data, a new implementation loads an agreed initial dataset, and a selective transition transfers a bounded scope. These scenarios cannot share one promise to "migrate every document."

Define the transition boundary and approach#

In a system conversion from SAP ERP to S/4HANA, data transformation is part of the conversion procedure and depends on the release, active components, and applicable simplification items. It is not an ordinary load of migration files.

For a new implementation or selective data transition, define the target state and the dataset that will create it. SAP Migration Cockpit uses migration objects. Available fields, rules, and dependencies are determined by the selected object and approach, such as staging or direct transfer. Review the object documentation and target release, then inspect the object's active fields and scope on the Migration Object screen.

For Public Edition, the Migration Cockpit supports an initial dataset required to start operations. Public Edition 2608 documentation distinguishes closed historical transactions from balances and open transactions available for migration. This is a product- and version-specific boundary, not a statement about every migration tool or On-Premise system conversion.

Record the scenario, source and target versions, company codes and periods in scope, history boundary, load approach, permitted cutover snapshot, and owner for each decision. If the transition approach is not yet selected, resolve that first: the target model and meaning of reconciliation depend on it.

Map objects by business meaning#

Create one mapping row for each object with these fields:

Mapping field	What to record
Source object	System, table/interface or report, system of record, and owner
Meaning and grain	What a record represents, its key, row-level detail, and uniqueness rule
Target object	Migration object or target entity and supported release
Transformation	Conversion rule, mapping table, default, and exclusion condition
Organizational dimensions	Company, ledger, account, business partner, CO object, and other used assignments
Currency and time	Currency code and amount type; event, document, posting, settlement, or snapshot date
Control	Required-field, domain, relationship, total, duplicate, and downstream reconciliation checks

Map objects by their role in the process and accounting, not only by similar field names. For example, an account number may represent a general ledger account, a subledger reconciliation account, or an alternative identifier. Do not map these concepts without a confirmed rule and an accountable owner.

Document identifier transformations separately. For source and target keys, retain the rule, uniqueness scope, format, leading-zero behavior, and possible number reuse. If the source identifier is not a target key, preserve an approved cross-reference table and a way to trace back to the source record.

Preserve grain and document relationships#

Before transformation, distinguish four data forms:

Posting or document with line items: document amounts and line relationships explain how the result was formed.
Open item: a balance remains tied to a business partner, due date, currency, payment terms, and clearing status; an account total alone does not retain this meaning.
Balance: an amount at a key date, aggregated by explicit dimensions such as company, ledger, account, currency, and account assignment.
Historical transactions: records from closed processes that may fall outside the selected migration object's scope.

Record which dimensions are aggregated when converting detail to balances and which fields remain in the target for audit and reconciliation. If a load creates accounting documents from migrated accounting records, check its posting logic for that specific migration approach. SAP's documentation for one such model describes balancing line items and clearing accounts; do not extend that logic to system conversion or another tool automatically.

Do not load the same asset or subledger balance through both a specialized object and a general ledger balance object unless the documentation and project rule explicitly allow it. Prevent double counting in the mapping before preparing the file, not after a reconciliation difference appears.

Map currencies together with amounts#

An amount without a currency code is not a complete financial value. For each amount, identify whether it is a document, transaction, local, ledger, or group-currency amount; map the source value to the target field; and state whether recalculation is allowed.

Keep the source amount and transformed result separately. If a rule requires conversion, record the exchange-rate type, rate determination date, quotation method, and rate source. In SAP, the posting date may determine rate selection; a supplied exchange rate or separate translation date can change that logic. Use the procedure for the selected object and version instead of silently replacing a historical amount with the current rate at test time.

Currency translation, introducing a currency, and changing a parallel-accounting model are separate projects with their own procedures and controls. Do not infer a rate or accepted rounding rule for them from a general migration map.

Separate date meanings and posting periods#

The source-document date, the date a record was entered, and the posting date represent different events. SAP S/4HANA Cloud documentation assigns different roles to document date and entry date, while the posting date determines the posting period. Do not replace them with a single "transaction date."

For each date, record the source field, business meaning, applicable time zone or calendar rule, target attribute, and whether it affects an open period, payment due date, receivables aging, exchange rate, or cutover. If the posting date changes, recalculate the expected period and reporting effect; a default must not move an amount to another period accidentally.

Define the balance key date, open-item state at that date, treatment of documents around period boundaries, and capture of transactions received after the snapshot. Store extraction time separately from business-event dates so that reruns and late-arriving records can be explained.

Retain a link to each source document#

For transferred documents, define which attributes link header to lines, business partner to reconciliation account, line to account assignment, document to reversal, and source record to target number. A number generated by the target does not replace the source key. Preserve a source reference or cross-reference according to the object's supported fields and the audit policy.

Check required dependencies separately: master data and roles exist before transactions use them; accounts and assignments are valid for the target company and period; references to preceding or subsequent documents are within the supported migration boundary. If the target object does not retain a historical link, define an archive or analytics access method before the transfer.

Prove the mapping in a test cycle#

For each mapping rule, prepare a source example, expected target value, and control. At minimum, include multi-line documents, open items in multiple currencies, debit and credit balances, period-boundary records, reversals, duplicates, and records with missing required relationships.

Check the result along several independent dimensions:

Counts and uniqueness of source and target keys, with an exception list.
Totals by company, ledger, period, account, currency, and other preserved dimensions.
Balance detail: the selected open-item population reconciles to the control balance under the agreed rule.
Document amounts, currencies, dates, and links to source documents.
Migration clearing accounts if required by the specific migration object.
A repeat run against a fixed snapshot, with explainable and reproducible results and exceptions.

Do not hide differences inside an aggregate total. Each accepted difference needs a reason, owner, amount, evidence, and finance-owner approval. A technically completed load does not prove that the financial model is complete or correct.

This partially covers MIG-06. SAP Migration Cockpit documentation for On-Premise refers to S/4HANA 2025 FPS02; separate date-field and available initial-dataset sources refer to Public Edition 2608; posting logic is cited only within the documented migration model. Sources are registered as metadata_only; real tables, mappings, customer amounts, a migration project, and SAP runtime were not checked.