Граница между FI/CO и ABAP определяется не количеством условий и не тем, кто быстрее реализует изменение. Если SAP уже предусматривает нужное поведение как часть стандартного процесса, организационной модели или Customizing, это зона FI/CO. Если необходимо добавить поведение, которого стандартная конфигурация не предоставляет, начинается расширение – через key-user-механизм, BAdI, developer extensibility или внешнее приложение.

При этом финансовую семантику нельзя передать разработчику вместе с техническим заданием. Владелец процесса и FI/CO-консультант должны определить, какой бухгалтерский результат считается правильным. Разработчик отвечает за допустимый способ технической реализации, но не единолично решает, какие счета, аналитики, ledger или контрольные правила должны применяться.

Конкретный выбор зависит от редакции и версии: SAP S/4HANA Cloud Public Edition, Private Edition и on-premise предоставляют разные модели расширения и разные наборы опубликованных точек. Поэтому приведённая ниже граница – архитектурный принцип, а не каталог функций для любого релиза.

Термины, которые нельзя смешивать

В проектной речи словом «настройка» часто называют любое изменение системы. Для распределения ответственности этого недостаточно.

  • Configuration / Customizing – выбор и параметризация предусмотренного SAP поведения: организационных единиц, правил проводок, account determination, вариантов процессов, проверок и других параметров. В этой статье оба термина обозначают стандартную бизнес-настройку, хотя в конкретных продуктах SAP их технический смысл может различаться.
  • Key-user extensibility – расширения, создаваемые key user через предусмотренные продуктом приложения. Они могут быть декларативными, например пользовательские поля и адаптация интерфейса, а в доступных продуктах и сценариях – включать Custom Logic или in-app BAdI. Декларативный подвид не требует программной логики. Набор таких возможностей необходимо проверять для целевой редакции и release (Key User Extensibility, App Configuration).
  • Enhancement – дополнительная функциональность, подключённая через предусмотренную SAP точку расширения без изменения исходного стандартного объекта.
  • Developer extensibility – программное расширение, тесно связанное с приложением SAP: например, реализация опубликованного BAdI или разработка на разрешённых ABAP API. SAP сопоставляет key-user и developer extensibility как разные уровни расширения (Key User Extensibility and Developer Extensibility).
  • Side-by-side extensibility – отдельное, слабосвязанное приложение, обычно на SAP BTP, которое взаимодействует с S/4HANA через опубликованные API, события или интеграционные интерфейсы (Side-by-Side Extensibility). Такое приложение не обязательно написано на ABAP.
  • Modification – изменение объекта SAP standard. В отличие от enhancement, модификация затрагивает поставленный SAP объект и может потребовать отдельной адаптации при обновлении; SAP рассматривает планирование adjustment для modifications и enhancements как отдельную задачу обновления (Modification and Enhancement Adjustment Planning).

Custom Logic или реализация BAdI остаётся разработкой, даже если код вводит key user через специальное приложение. Удобный редактор не превращает программную логику в Customizing: у неё есть опубликованный контракт, жизненный цикл, публикация и собственные тесты. Доступность такого инструмента проверяется для целевой редакции и release. FI/CO при этом по-прежнему определяет финансовую семантику расширения.

Что остаётся на стороне FI/CO

FI/CO-настройка выбирает стандартное поведение системы, а не воспроизводит его программным кодом. К этой области обычно относятся:

  • company code, controlling area и связи организационных единиц;
  • ledger, валютные и периодические параметры в пределах доступной конфигурации;
  • планы счетов, типы документов и правила account determination;
  • допустимые account assignments и параметры интеграции FI с CO;
  • стандартные validation и substitution rules;
  • workflow и процессные параметры, если требование покрывается предусмотренной моделью;
  • параметры закрытия, распределения, расчёта и отчётности, доступные в стандартном scope.

Например, связь company code с controlling area является частью организационной модели и настраивается средствами SAP, а не пользовательской программой (Assigning Controlling Areas and Company Codes). Это не просто техническая запись в таблице: выбор влияет на интеграцию финансового и управленческого учёта. Поэтому определять такую связь должен функциональный владелец совместно с FI/CO-консультантом.

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

Где начинается разработка

Разработка нужна, когда требуемое поведение нельзя выразить стандартными параметрами или разрешёнными декларативными правилами. Типичные признаки:

  • значение вычисляется по алгоритму, которого нет в стандартной derivation или substitution;
  • проверка обращается к дополнительным данным либо требует сложного контекста;
  • необходим новый сервис, отчёт, пользовательский интерфейс или массовая обработка;
  • процесс должен реагировать на событие и передавать данные другой системе;
  • стандартный объект требуется расширить через опубликованный BAdI;
  • отдельное приложение должно хранить собственное состояние или иметь независимый жизненный цикл.

Это не означает, что любое такое требование следует реализовать классическим ABAP-кодом внутри S/4HANA. Сначала нужно выбрать подходящий тип расширения.

Для тесно связанной логики внутри транзакции может подойти опубликованный BAdI, Custom Logic или developer extensibility. Такая логика относится к разработке независимо от того, открывается ли редактор из key-user-приложения. Для отдельного приложения, долгой обработки или межсистемной оркестрации часто уместнее side-by-side-подход.

Пользовательское поле или адаптация интерфейса могут полностью укладываться в декларативную key-user extensibility. Но наличие технической capability само по себе не назначает исполнителя: FI/CO или key user может вести такое изменение только при доступном механизме, требуемых ролях и согласованном архитектурном и процессном контроле. Для Custom Logic дополнительно необходимы техническая проверка и разработческие тесты.

Основой устойчивой разработки должен быть опубликованный контракт. В ABAP Cloud объект со статусом Released предоставляется как public API в рамках соответствующего release contract (Released APIs). Техническая доступность внутреннего класса или таблицы не делает их стабильным интерфейсом.

Дерево решения: от стандарта к расширению

Решение удобно принимать последовательно.

  1. Покрывает ли требование стандартный процесс? Проверяются scope, организационная модель, master data, account determination, validation/substitution, workflow и Customizing. Покрытие можно считать достаточным, если нужная финансовая семантика выполняется без программной логики на всех существенных каналах и вариантах операции – например, при ручном вводе, загрузке, межфирменной операции и сторно, – а отклоняющие сценарии дают ожидаемый контрольный результат. Тогда реализация остаётся в FI/CO.
  2. Можно ли скорректировать сам процесс? Иногда требование переносит в новую систему историческое обходное решение. Следует сравнить его со стандартным SAP-процессом, а не автоматически копировать прежний код. Если скорректированный процесс покрывается стандартом, следует вернуться к шагу 1; если нет, продолжить проверку механизмов расширения на шагах 3–6.
  3. Есть ли подходящий декларативный key-user-механизм? Пользовательское поле или адаптация интерфейса предпочтительнее отдельной разработки, если механизм действительно покрывает все каналы процесса. Если требуется Custom Logic, это уже программное расширение, а не FI/CO Customizing.
  4. Есть ли released extension point, API или event? Проверяется не только его название, но и момент вызова, доступные поля, поддерживаемые типы документов и ограничения конкретного релиза. Источником служат документация extension point для целевого релиза и доступное в продукте приложение или каталог расширяемости.
  5. Насколько тесно логика связана с проводкой? Синхронная проверка перед сохранением документа обычно требует in-app extension. Независимая обработка или внешняя функция может быть вынесена side-by-side.
  6. Что делать, если разрешённого расширения нет? Возможные ответы – изменить процесс, запросить поддержку требуемого сценария, вынести функцию наружу либо отложить изменение. Отсутствие BAdI само по себе не оправдывает модификацию SAP standard.

Такой порядок соответствует clean-core-подходу: использовать предусмотренные модели расширения и опубликованные интерфейсы, снижая зависимость от внутренних объектов SAP. Clean core не запрещает разработку, а ограничивает способ её встраивания; SAP описывает применимость ABAP Cloud к разным продуктам отдельно (Different SAP Products).

Пример: замещение аналитики и контроль проводки в journal entry

Рассмотрим условное требование: «При проводке расходов автоматически определять profit center по company code, cost center и типу документа; для определённой комбинации запрещать проводку без дополнительной аналитики».

Сначала FI/CO-консультант должен уточнить финансовую семантику:

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

Затем проверяются стандартные substitution и validation. SAP документирует такие функции для journal entries (Substitution/Validation for Journal Entries). Если требуемые поля и условия доступны в стандартном правиле, это Customizing FI/CO.

Если декларативного правила недостаточно, проверяется опубликованный BAdI или другой предусмотренный механизм. SAP документирует BAdI для отдельных контекстов substitution и validation journal entries, в том числе для некоторых контекстов заголовка, позиции и coding block (Business Add-Ins for Substitution for Journal Entries). Однако наличие BAdI не гарантирует пригодность для произвольной проверки. Для целевого release необходимо проверить его фильтры, доступные поля, момент вызова, поддерживаемые типы документов и семантику сообщений, включая возможность синхронно отклонить проводку.

Чтобы довести пример до решения, примем условные проектные допущения: profit center является производным полем; исходными служат company code, cost center и тип документа; автоматический результат нельзя менять вручную. Получится следующая граница:

Условный сценарий Требуемое поведение Способ реализации Контрольный результат
Для заданной комбинации company code, группы cost centers и типа документа все условия и производное значение доступны в стандартной substitution Заполнить profit center FI/CO Customizing До проводки profit center заполнен ожидаемым значением во всех затронутых каналах
Для особой комбинации требуется дополнительная аналитика, а декларативная validation не может выразить необходимую проверку Отклонить проводку при незаполненной аналитике Опубликованный BAdI, Custom Logic или иной допустимый pattern после проверки контракта Документ отклоняется только в том случае, если выбранный и проверенный механизм поддерживает синхронный отказ и требуемое сообщение; иначе нужен другой допустимый pattern или изменение процесса
Комбинация не входит в область правила Сохранить стандартное поведение Без дополнительной настройки или кода Проводка обрабатывается стандартным процессом без непредусмотренного замещения

Это условный результат, а не утверждение о возможностях любого релиза. Пригодность substitution/validation и конкретного BAdI необходимо проверить по документации целевой версии: важны доступные поля, момент вызова, фильтры, типы документов, каналы создания проводки и поддерживаемая семантика отказа.

Распределение ответственности в этом примере выглядит так:

  • FI/CO определяет таблицу решений, приоритеты правил и ожидаемые проводки;
  • архитектор подтверждает, что стандартного механизма недостаточно, и выбирает допустимый extension pattern;
  • ABAP-разработчик реализует опубликованный контракт и обрабатывает предусмотренные технические ситуации;
  • FI/CO и владелец процесса подтверждают финансовый результат на сквозных сценариях.

Если алгоритм обращается к внешней модели данных и не обязан блокировать проводку синхронно, side-by-side-решение может оказаться лучше встроенного кода. Если же результат должен быть известен до сохранения документа, асинхронная внешняя обработка, вероятно, не обеспечит требуемый контроль. Архитектурный выбор следует из момента принятия финансового решения, а не из предпочтения конкретной технологии.

Кто отвечает за результат

Граница между FI/CO и ABAP не должна создавать разрыв ответственности.

Роль Основная ответственность
Владелец финансового процесса Определяет цель, контрольный результат, допустимые исключения и утверждает бизнес-эффект
FI/CO-консультант Описывает бухгалтерскую семантику, проверяет стандартный процесс, выполняет Customizing и задаёт ожидаемые проводки
Key user Выполняет разрешённые декларативные расширения в пределах назначенных ролей и согласованного архитектурного и процессного контроля
Архитектор Выбирает между стандартом, key-user, in-app и side-by-side extensibility; проверяет совместимость с clean-core-политикой
ABAP-разработчик Анализирует extension contract, реализует программную часть и предоставляет технические тесты
Тестировщик или процессный аналитик Выполняет сквозные и регрессионные сценарии, сопоставляет фактические результаты с ожидаемыми
Change manager Координирует зависимости, последовательность транспортов, approvals и продвижение по ландшафту

Финансовый владелец утверждает семантику и итоговый результат, архитектор – допустимый extension pattern, а назначенные исполнители отвечают за настройку или код и за тестовые доказательства. Разработчик может выявить техническое ограничение, но не должен самостоятельно выбирать иной счёт или ослаблять проверку. Аналогично FI/CO-консультант не должен предписывать обращение к внутренней таблице SAP, не оценив устойчивость интерфейса.

Транспорты и тесты являются частью границы

Customizing и разработка образуют разные, но согласованные потоки изменений. В классическом ABAP-ландшафте клиентские настройки обычно связаны с customizing requests, а repository-объекты – с workbench requests; SAP отдельно определяет назначение customizing requests (Customizing Requests). В облачном трёхсистемном ландшафте действуют собственные механизмы продвижения и ограничения (3-System Landscape and Transport Management).

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

Успешный импорт подтверждает только техническое перемещение объектов. Он не доказывает правильность финансового результата. Ниже приведён не универсальный обязательный набор, а кандидаты для impact analysis: каждый сценарий включается в тестовый scope с учётом влияния изменения на ledger, валюты, локализации, каналы создания, интерфейсы, закрытие и отчётность. Для проводки могут потребоваться проверки следующего пути:

  • создание первичного документа всеми затронутыми каналами;
  • derivation и account assignment;
  • отражение в FI и CO;
  • ledger и валютные представления, если они затронуты;
  • отмена, сторно и повторная обработка;
  • закрытие и отчётность;
  • интерфейсы и reconciliation;
  • отрицательные сценарии, в которых документ должен быть отклонён.

Эталон теста должен содержать не только статус «проведено», но и ожидаемые счета, суммы, валюты, аналитики и контрольные сообщения. Именно эти результаты связывают техническую реализацию с финансовым требованием.

Практическая матрица выбора

Характер требования Предпочтительный путь Кто ведёт реализацию
Предусмотренная организационная структура или правило учёта FI/CO Customizing FI/CO
Пользовательское поле или декларативная адаптация интерфейса, поддержанная продуктом Key-user extensibility без программной логики Назначенный FI/CO-консультант или key user при наличии требуемых ролей и согласованного контроля
Синхронная проверка или вычисление, не выразимые стандартной substitution/validation, в опубликованной точке расширения BAdI, Custom Logic или developer extensibility FI/CO задаёт семантику, разработчик реализует; для Custom Logic обязательны техническая проверка и разработческие тесты
Независимое приложение или слабосвязанная интеграция Side-by-side extensibility Архитектор и команда разработки
Нет стандартной функции и разрешённого extension point Изменение процесса, внешний вариант или откладывание Владелец процесса и архитектор
Требуется изменение SAP standard Исключительный архитектурный разбор, а не обычный путь Архитектурный орган и владелец риска

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