Переход CO и Funds Management: что проверить в целевой модели

При переходе CO и Funds Management (FM) проверяйте не совпадение названий, а сохранение нужной функции, учётного смысла и контрольного результата. Техническая конверсия работающей системы, выборочный перенос и новая реализация задают разные границы данных. Настройки и остатки, присутствующие в исходной системе, не доказывают, что соответствующая функция включена, настроена или должна переноситься в целевой.

Сначала выберите сценарий и целевой процесс#

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

Разведите три решения:

Конверсия системы: проверьте версионные требования и изменённые объекты в Conversion Guide и Simplification Items. Не добавляйте «миграцию данных» к конверсии без отдельного требования.
Новая реализация или selective transition: определите целевые процессы и данные, которые нужны для их запуска. Наличие объекта в Migration Cockpit ещё не означает, что его область, поля и зависимости совпадают с используемым исходным процессом.
Функциональная замена внутри продукта: например, отдельный переход между режимами бюджетирования. Его предпосылки и содержимое миграции относятся именно к этому сценарию и не являются общим планом S/4HANA conversion.

Версионируйте эту классификацию по компании, FM area/controlling area, периоду и целевому ландшафту. Если планируется новый бюджетный или управленческий процесс, сначала согласуйте его модель, затем решайте вопрос переноса исторических данных.

Составьте карту соответствия CO#

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

Проверьте как минимум те элементы, которые реально задействованы:

Классификация затрат: в S/4HANA cost elements представлены как типы счетов G/L и часть плана счетов; отдельно поддерживаемые поля и отчёты могут отличаться от прежней отдельной модели master data. Сопоставьте исходный вид элемента затрат, категорию, счёт и целевое представление по документации целевой версии.
Объекты и назначения: controlling area, cost/profit center, внутренний заказ, WBS, сегмент прибыльности и другие объекты, на которые ссылаются проводки и распределения. Проверьте обязательные поля, статусы, сроки действия, диапазоны номеров и связи с компанией.
Потоки стоимости: первичные проводки FI, распределения, расчёты заказов, product costing, Material Ledger/actual costing и используемая модель CO-PA. Различайте изменения модели данных и изменения метода расчёта: они требуют разных согласований и тестов.
План и факт: версии, периоды, типы значений, валюты, источник данных и поддерживаемые целевые сценарии планирования. Сравните не только итоговую сумму, но и размерность, по которой пользователи объясняют отклонения.

Для каждой пары source/target определите один результат: без изменения; преобразовать при конверсии; перенастроить; сопоставить на другие объекты; загрузить отдельным migration object; пересоздать; оставить только для чтения; вывести из использования. Не выводите судьбу объекта из сходства названий или наличия данных в таблице.

Составьте отдельную карту Funds Management#

Сначала установите конкретный вариант и scope FM: используемый бюджетный механизм, FM area, fiscal year, источники документов, интегрированные компоненты, требования к availability control и версию цели. Не смешивайте Funds Management в SAP ERP, PSM-FM в S/4HANA и отдельные migration objects Public Edition в одну универсальную модель.

Для фактически используемых процессов проследите:

Структуру назначения: funds center, commitment item, fund, functional area, grant и применимые связи. Зафиксируйте область уникальности ключей, допустимость по периоду и правила преобразования.
Деривацию: из каких полей FI, MM/закупки и других feeder-компонентов заполняется FM assignment, в каком порядке применяются правила, где допускается ручное значение и как обрабатываются пропуски.
Бюджет и контроль: бюджетная структура, типы и версии бюджета, период, бюджетные документы, availability control profile, проверяемые лимиты и исключения.
Обязательства: заявки, заказы, авансы, фактические проводки, освобождение/снятие обязательств и их связь с исходными документами.
Вариант бюджетирования: если источник использовал Former Budgeting, а цель требует Budget Control System (BCS), оценивайте это как самостоятельное преобразование процесса. SAP описывает клиентские сценарии такого перехода и отдельно предупреждает о рисках одновременного изменения структур назначения; не считайте его обязательным этапом любой конверсии.

Проверьте конкретный target migration object, его scope item, структуру шаблона и связи. Например, описание объекта PSM - Fund для Public Edition 2608 говорит о миграции мастер-данных фонда; оно не доказывает поддержку тем же объектом бюджетных документов, обязательств, FM assignments и availability control.

Проверьте переходы настройки и данных отдельно#

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

Изменение правил деривации может изменить FM assignment будущей проводки, но само по себе не исправляет прежние документы. Перенос бюджета не гарантирует пересоздание всех зависимых остатков и проверок. Перенос commitment item или fund center не переносит автоматически его иерархии, статусы, master data groups или документы.

Зафиксируйте sequence, если несколько уровней должны быть готовы до транзакций: организационные единицы и счета; CO/FM master data; derivation и интеграция; бюджетные настройки; открытые документы и начальные значения; регрессия и открытие периода. Это логическая карта зависимостей, не универсальный порядок SAP-задач.

Задайте доказательства функционального соответствия#

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

В тестовый цикл включите:

FI-документ с CO/FM account assignment и проверку целевых измерений.
Проводку из feeder-компонента и результат account assignment derivation.
Первичную проводку, allocation и settlement, если они используются.
Заявку/заказ, возникновение и изменение commitment, фактическое потребление и снятие остатка.
Бюджетную проверку ниже, на границе и выше лимита; отдельно ожидаемое сообщение и разрешённое исключение.
Год/период границы, изменение назначения, сторно и повторную загрузку, если они входят в сценарий.

Сверяйте количества документов, суммы по dimension, открытые commitments, бюджетный остаток и результат availability control. Любое отличие классифицируйте как ошибку соответствия, ожидаемое изменение поведения, сознательное преобразование, исключённую историю или необъяснённое расхождение. Технически успешная конверсия не подтверждает работу процесса CO/FM.

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

Этот материал частично покрывает MIG-07. Источники относятся к SAP S/4HANA On-Premise 2025 FPS01/FPS02, SAP ERP 6.0 EHP8 SP25 для отдельного Former Budgeting-to-BCS сценария и Public Edition 2608 для конкретного фонда-объекта. Все записи metadata_only; реальная конфигурация CO/FM, документы, бюджет, commitment, конверсия и SAP runtime не проверялись.

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

When transitioning Controlling (CO) and Funds Management (FM), check preservation of the required function, accounting meaning, and control result rather than matching names. A technical conversion of a running system, a selective transfer, and a new implementation have different data boundaries. The fact that settings and balances exist in the source does not prove the corresponding function is enabled, configured, or meant to be transferred to the target.

Select the scenario and target process first#

For each process, state what is required after the transition: the same result through the same method; a similar result through a different function; new behavior; read-only archive access; or retirement of the old function. Identify the target edition and release, the configuration owner, and which source documents start the process.

Keep three decisions distinct:

System conversion: check release-specific requirements and changed objects in the Conversion Guide and Simplification Items. Do not add a data migration to the conversion without a separate requirement.
New implementation or selective transition: define target processes and the data needed to start them. The existence of an object in Migration Cockpit does not mean its scope, fields, and dependencies match the source process in use.
In-product functional replacement: for example, a separate transition between budgeting methods. Its prerequisites and migrated data belong to that specific scenario and are not a general S/4HANA conversion plan.

Version this classification by company, FM area/controlling area, period, and target landscape. If a new budget or management process is planned, agree on its model before deciding which history to transfer.

Build a CO correspondence map#

For each CO process in use, record the source function, object and settings; target function; fate of data; expected result; and test.

Check only the elements that are actually used, including:

Cost classification: in S/4HANA, cost elements are represented as G/L account types and are part of the chart of accounts; the separately maintained master-data model changes. Map source element type, category, account, and target representation using documentation for the target release.
Objects and assignments: controlling area, cost/profit center, internal order, WBS, profitability segment, and other objects referenced by postings and allocations. Check required fields, statuses, validity dates, number ranges, and company relationships.
Value flows: primary FI postings, allocations, order settlements, product costing, Material Ledger/actual costing, and the CO-PA model in use. Data-model changes and calculation-method changes require different approvals and tests.
Plan and actual: versions, periods, value types, currencies, data source, and supported target planning scenarios. Compare not only the total but also the dimensions users rely on to explain variances.

For each source/target pair, select one outcome: unchanged; transformed by conversion; reconfigured; mapped to different objects; loaded through a separate migration object; recreated; retained as read-only; or retired. Do not infer the fate of an object from similar names or the presence of data in a table.

Build a separate Funds Management map#

First establish the actual FM variant and scope: budgeting method, FM area, fiscal year, source documents, integrated components, availability-control requirements, and target version. Do not collapse Funds Management in SAP ERP, PSM-FM in S/4HANA, and individual Public Edition migration objects into one generic model.

For processes in use, trace:

Assignment structure: funds center, commitment item, fund, functional area, grant, and applicable relationships. Record key scope, period validity, and transformation rules.
Derivation: which FI, MM/procurement, and other feeder fields populate FM assignments; the rule sequence; where manual values are allowed; and how missing values are handled.
Budget and control: budget structure, budget types and versions, period, budget documents, availability-control profile, checked limits, and exceptions.
Commitments: requisitions, orders, advances, actual postings, release/reduction of commitments, and their links to source documents.
Budgeting method: if the source used Former Budgeting and the target requires the Budget Control System (BCS), assess that as a separate process transition. SAP documents customer-specific scenarios and warns about changing assignment structures at the same time; this is not a required step for every conversion.

Check the exact target migration object, its scope item, template structure, and relationships. For example, the Public Edition 2608 PSM - Fund object describes fund master-data migration; it does not prove that the same object supports budget documents, commitments, FM assignments, or availability control.

Check configuration and data transitions separately#

Divide the worklist into configuration and reference data, open documents and commitments, budgets/balances, closed history, and derived control records. For each layer, state whether it is preserved by conversion, transferred by an object, recreated, reconciled separately, or kept in an archive. Confirm the decision for the source, target, and release.

Changing derivation rules can affect FM assignments on future postings, but does not itself correct prior documents. Transferring budget does not guarantee that all dependent balances and controls are regenerated. Transferring a commitment item or funds center does not automatically transfer its hierarchies, statuses, master-data groups, or documents.

Record the sequence when several layers must be ready before transactions: organizational units and accounts; CO/FM master data; derivation and integration; budget configuration; open documents and opening values; regression and period opening. This is a logical dependency map, not a universal SAP task order.

Define evidence of functional correspondence#

For each process, agree on the scenario, source and target settings, control sample, expected result, accepted differences, and acceptance owner. Use the same companies, periods, currencies, and snapshot dates. Compare documents and assignment fields, not only the grand total.

Include in the test cycle:

An FI document with CO/FM assignment and verification of target dimensions.
A posting from a feeder component and its derived FM assignment.
A primary posting, allocation, and settlement where used.
A requisition/order, commitment creation and change, actual consumption, and remaining commitment.
A budget check below, at, and above the limit, including expected messages and allowed exceptions.
A fiscal year/period boundary, assignment change, reversal, and rerun when in scope.

Reconcile document counts, dimensional totals, open commitments, remaining budget, and availability-control results. Classify every difference as a correspondence error, expected behavior change, intentional transformation, excluded history, or unexplained variance. A technically successful conversion does not confirm CO/FM process operation.

Do not change master-data structure and migration scope at the same time unless the test can explain each effect separately. Do not clear commitments or transfer budgets just to make a control account zero; establish the business meaning and target-process rule first.

This partially covers MIG-07. Sources refer to SAP S/4HANA On-Premise 2025 FPS01/FPS02, SAP ERP 6.0 EHP8 SP25 for the separate Former Budgeting-to-BCS scenario, and Public Edition 2608 for a specific fund object. All records are metadata_only; actual CO/FM configuration, documents, budgets, commitments, conversion, and SAP runtime were not inspected.