Меню

Комплексный подход при внедрении Central Finance

В статье даны рекомендации, которые помогут вам подготовиться к реализации проекта внедрения Central Finance. Использование Central Finance позволяет сократить затраты на внедрение SAP S/4HANA Finance для организаций с гетерогенными ландшафтами (несколько систем SAP ERP или сторонних систем). При наличии Central Finance таким организациям не потребуется выполнять апгрейд всех систем, чтобы внедрить SAP S/4HANA Finance. Вместо этого они смогут внедрить систему SAP S/4HANA Finance всего с одной инстанцией.

Ключевое понятие

Ключевыми аспектами внедрения Central Finance являются преобразование/гармонизация основных данных, копирование транзакционных данных и обработка отчетности.

Применяя следующие рекомендации, вы сможете заранее подготовиться к внедрению Central Finance с точки зрения системных требований, планирования ресурсов, настройки и освоения ключевых процессов, которые поддерживаются SAP, а также тех, которые не поддерживаются в версии S/4HANA Finance 1605. Central Finance — это вариант развертывания, а не функциональность в SAP S/4HANA. SAP предоставляет этот вариант для упрощения процесса внедрения SAP S/4HANA Finance.

Вариант развертывания Central Finance

SAP S/4HANA Finance это инновационная замена систем. При установке SAP S/4HANA Finance Add-On классические модули SAP Финансов и Контроллинга (FI-CO) заменяются улучшенным модулем SAP Accounting Powered by HANA, а все прочие модули остаются без изменений. Для установки SAP S/4HANA Finance Add-On требуется наличие SAP ERP Central Component (ECC) 6.0 с пакетом расширения 7 или выше. Кроме того, необходимо использовать базу данных SAP HANA.

Для организаций с гетерогенным ландшафтом (несколько инстанций SAP ERP или других систем), которые планируют внедрить систему SAP S/4HANA Finance, серьезные трудности вызывает выполнение следующих задач:

  • Миграция всех инстанций в базу данных SAP HANA.
  • Апгрейд всех инстанций до SAP ERP Central Component (ECC) 6.0 с пакетом расширения 7.
  • Установка SAP S/4HANA Finance Add-On на всех инстанциях.

Это повышает сложность проекта, а также увеличивает объем требуемых ресурсов и затрат на внедрение SAP S/4HANA Finance. Чтобы упростить процесс внедрения для таких клиентов, компания SAP предоставляет вариант развертывания Central Finance.

Вместо апгрейда всех инстанций можно добавить новую инстанцию, установив в ней SAP S/4HANA Finance Add-On. Далее можно подключить все существующие инстанции к новой системе SAP S/4HANA Finance. Благодаря новому подходу все существующие инстанции остаются без изменений, т. е. процесс не прерывает работу компании. Вам просто необходимо применить несколько SAP-нот в исходной системе.

Все проведенные в исходных системах финансовые операции автоматически переносятся в систему SAP S/4HANA Finance. Она становится системой регистрации для Финансов и может далее использоваться для выполнения центральных процессов. Например, закрытие периода можно выполнить в новой центральной инстанции, а не в нескольких инстанциях.

Важные аспекты реализации при ведении проекта Central Finance

В данной статье мы стремимся осветить различные аспекты внедрения Central Finance, включая системы, данные и собственно процесс.

Системы

Рассмотрим, какие системы задействованы в процессе, как они совместимы с Central Finance и как можно их развернуть. Требуемые системы представлены в табл. 1.

Табл. 1. Системы, необходимые для применения Central Finance

Сервер тиражирования SLT обязательно используется при внедрении с помощью Central Finance, поскольку он соединяет исходную систему (существующие SAP-системы/сторонние системы) с целевой системой SAP S/4HANA Finance. Для каждой финансовой проводки в исходной системе в реальном времени инициируется триггер базы данных. Далее SLT считывает эти данные из таблиц журналов и инициирует проводки в целевую систему Central Finance. Использование SLT в данном случае отличается от того как вы, возможно, его использовали в проектах евроконвертации. Бизнес-мэппинг выполняется в интерфейсе Central Finance.

Проводка в систему Central Finance представляет собой не репликацию, а собственно новую проводку, в отличие от проводок в системе SAP Business Warehouse (SAP BW), в которую они просто копируются. Это означает, что перед проведением документов вы можете выполнять собственные проверки и реализовывать замещения в системе Central Finance.

SLT работает на уровне базы данных, что означает отсутствие изменений на уровне приложений исходных систем. Это удобно с точки зрения подключения сторонней системы к Central Finance, поскольку упрощает процесс трансформации без прерывания бизнес-процессов.

Применение MDG не является обязательным. Данная функциональность используется только в том случае, если одной из целей внедрения с помощью Central Finance является гармонизация данных. Например, если несколько балансовых единиц используют разные планы счетов, вы можете с помощью MDG преобразовать основные счета перед проводкой в систему Central Finance. Это упрощает обработку и гармонизирует отчетность из системы Central Finance.

Гармонизация данных посредством MDG не ограничивается планом счетов. Это может применяться также для ведения основных записей клиентов, основных записей поставщиков, основных записей материалов, МВЗ и МВП.

SAP S/4HANA Finance (системе Central Finance) это система в которой развернут SAP S/4HANA Finance Add-On. Она используется как целевая система, в которую переносятся все документы из исходных систем. Поэтому ее наличие является обязательным.

Все указанные выше системы можно развернуть как локально, так и в облаке.

Данные

В данном разделе статьи рассмотрим репликацию основных данных в систему Central Finance и гармонизацию этих данных. В данном контексте важно разграничивать следующие группы данных:

  • Данные, имеющие длительный срок использования (основная запись основного счета, основная запись поставщика, основная запись клиента, основная запись материала, МВЗ и МВП), которые в краткосрочной перспективе не изменяются. В случае же изменения таких данных требуется корректировка мэппинга в MDG или пользовательских таблицах в зависимости от ситуации.
  • Данные, имеющие небольшой срок использования (внутренние заказы, производственные заказы, заказы QM и заказы на ТОРО).

Данные, имеющие длительный срок использования

Для репликации долгосрочных основных данных (например, основных записей основных счетов, поставщиков, клиентов и материалов) можно использовать решение SAP BusinessObjects Data Services (BO-DS). Оно считывает данные из таблиц в исходной системе и реплицирует их в целевую систему Central Finance. Также, основные записи можно создать в целевой системе вручную или с помощью Legacy System Migration Workbench (LSMW).

Гармонизация долгосрочных основных данных выполняется с помощью MDG или путем ведения пользовательских таблиц для мэппинга и переноса финансовых документов в Central Finance посредством Business Add-In (BAdI). Например, во время перехода к продуктивной эксплуатации все существующие основные данные (например, основные записи основных счетов, материалов, клиентов и поставщиков) обновляются в таблицах мэппинга. Любую новую основную запись, созданную после перехода к продуктивной эксплуатации, необходимо обновить в таблицах мэппинга.

Для выполнения мэппинга с помощью MDG введите CFINIMG в командную строку, а затем в меню выберите CFINIMG > Central Finance > Mapping > Define Value Mapping (CFINIMG > Central Finance > Мэппинг > Определить мэппинг значений).

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

Рис. 1. Мэппинг MDG для основных счетов

Данные, имеющие небольшой срок использования

Как было сказано выше, мэппинг в MDG идеально подходит для долгосрочных основных данных. Однако для краткосрочных основных данных регулярное ведение мэппинга в таблицах выполнять нецелесообразно. Например, если в исходной системе ежедневно создается несколько производственных заказов, невозможно выполнять мэппинг в MDG несколько раз в день, поскольку это нарушит течение бизнес-процессов. Поэтому для таких краткосрочных носителей затрат SAP предоставляет решение — архитектуру Cost Object Mapping (мэппинг объектов затрат).

Далее показан узел SPRO для архитектуры Cost Object Mapping. В IMG выберите CFINIMG > Central Finance > Mapping > Cost Object Mapping > Define Cost Object Mapping (CFINIMG > Central Finance > Мэппинг > Мэппинг носителей затрат > Определить мэппинг носителей затрат). Появится экран, показанный на рис. 2.

Рис. 2. Стандартные сценарии, предоставляемые SAP для конфигурации мэппинга носителей затрат

Такие краткосрочные основные данные можно соотнести в соотношении 1:1 или N:1. Это означает, что можно выполнить мэппинг нескольких внутренних заказов в исходной системе с одним внутренним заказом в целевой системе Central Finance, например, по бизнес-сфере или МВП. Например, вместо ведения заказов с соотношением 1:1 в целевой системе Central Finance можно указать один внутренний заказ для бизнес-сферы/МВП.

Поскольку сама концепция Cost Object Mapping является достаточно объемной, в этой статье мы остановимся только на двух ключевых ее аспектах:

Для производственных заказов поддерживается только мэппинг N:1. В этом случае выполняется мэппинг нескольких производственных заказов из исходной системы в один коллектор затрат на продукт в целевой системе.

В связи с этим, если организация выполняет закрытие периода в системе Central Finance, незавершенное производство (НзП) и отклонения будут рассчитываться как для процесса серийного производства (т. е. оценка НзП выполняется при вычислении целевых затрат и расчет отклонения не зависит от статуса производственного заказа).

На момент написания статьи SAP не поддерживает репликацию структурного плана проекта (СПП) в версиях ниже 1511 FPS 02, следовательно, это недоступно в рамках Cost Object Mapping. См. SAP-ноту 2184567 — Central Finance — часто задаваемые вопросы.

Однако при необходимости использования Cost Object Mapping можно выполнить определенную пользовательскую разработку с помощью следующих двух BAdI: BADI_FINS_CFIN_AC_INTERFACE и BADI_FINS_CFIN_CO_INTERFACE.

В этом случае любая проводка по СПП-элементам в исходных системах может быть отображена по СПП-элементу или внутреннему заказу в целевой системе с помощью этих BAdI.

Процесс

В этом разделе описывается процесс переноса финансовых данных и транзакций из исходных систем в целевую систему Central Finance. Этот процесс состоит из следующих шагов:

  1. Первичная загрузка (исторических финансовых данных)
  2. Формирование финансовых документов из исходных систем в системе Central Finance
  3. Операции после обработки в случае появления ошибок переноса
  4. Просмотр контрольного журнала документа, от проведенного в целевой системе до документа в источнике.

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

Первичная загрузка в Central Finance

Первым шагом для подготовки к продуктивному старту в проектах внедрения с нуля является загрузка в SAP-систему прежних данных. Аналогично в проекте внедрения Central Finance выполняется первичная загрузка. Здесь необходимо указать, например, что требуется перенести подробные данные отдельных позиций за последние два или три года, а за периоды до этого — только сальдо.

При первичной загрузке исторические данные переносятся в систему Central Finance. Только после этого возможен перенос регулярных финансовых транзакций из исходных систем в систему Central Finance. Для этого необходимо присвоить первичной загрузке статус «Выполнено». Только после этого выполняется перенос текущих регулярных транзакций.

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

Рис. 3. Таблица для определения переноса сальдо и отдельных позиций

Как показано на рис. 3, для балансовой единицы 1001 будут перенесены отдельные позиции с 1 периода 2016 года (см. третий и четвертый столбцы на рис. 3). Подразумевается, что для периодов до 2016 года будут перенесены только сальдо. Также можно указать год, с которого требуется переносить сальдо. Это может быть год 0001 (с начала деятельности) или определенный год, например, финансовый год 2012, как в данном случае. Отдельные позиции будут перенесены с 1 периода финансового года 2016.

Перед переносом сальдо и отдельных позиций за прошлые периоды в целевую систему Central Finance необходимо выполнить следующее:

  • Необходимо завершить репликацию основных данных: МВЗ, основных счетов и МВП. Краткосрочные основные данные (внутренние заказы и коллекторы затрат на продукты) создаются на основе настроек, установленных в архитектуре мэппинга носителей затрат.
  • Может потребоваться выполнить ведение контировок по умолчанию в транзакции OKB9 для видов затрат.
  • Необходимо выполнить ведение перерасчетного счета миграции на уровне балансовой единицы, который будет использоваться для определения сальдо документа при репликации сальдо/отдельных позиций за прошлые периоды. Сальдо этого счета всегда равно нулю.
  • Все контрольные счета и счета входящих/исходящих налогов должны быть присвоены основному счету замещения. Проводки сначала выполняются по счету замещения, а затем переносятся на релевантный основной счет путем выполнения проводки по корреспондирующему счету замещения. Сальдо этого счета всегда равно нулю.

После выполнения первичной загрузки установите индикатор Initial Load… (Первичная загрузка), см. Рис. 3, который показывает, что первичная загрузка завершена. Репликацию в режиме онлайн в системе можно запустить только после установки этого индикатора.

Перенос финансовых транзакций в Central Finance

В этом разделе рассматривается репликация финансовых проводок из исходной системы в целевую систему. На рис. 4 представлена диаграмма этого процесса.

Рис. 4. Процесс переноса документов в Central Finance

Шаги для переноса документа в систему Central Finance выполняются в следующей последовательности:

  1. Документ проводится в исходной системе (SAP/сторонняя система).
  2. Триггер базы данных обновляет таблицу журнала в исходной системе.
  3. SLT считывает таблицы журналов. SLT работает на уровнях таблиц базы данных и использует объект репликации для каждой таблицы, которую требуется перенести. Для переноса документов FI считываются триггеры для таблицы CFIN_ACCHD. Для документов CO считываются триггеры для таблицы COBK. Для переноса заказов считываются триггеры для таблицы AUFK. Все эти связи поставляются в стандартном контенте SLT, установка их вручную не требуется.
  4. Перед переносом в Central Finance SLT проверяет наличие мэппинга MDG. При наличии такого мэппинга данные заменяются по правилам мэппинга.
  5. Перед переносом в Central Finance SLT также проверяет необходимость замены каких-либо данных в исходном документе с помощью настройки Cost Object Mapping (мэппинг носителей затрат) и заменяет объект затрат соответствующим образом.
  6. Далее SLT переносит эти данные в интерфейс учета Central Finance.
  7. Все записанные в Central Finance проверки и замещения также выполняются до переноса.
  8. Выполняется перенос бухгалтерского документа и обновление универсального журнала.
  9. В случае появления каких-либо ошибок пользователь может просмотреть документ в Application Interface Framework (AIF) и обработать его после устранения ошибок. (AIF рассматривается в этой статье ниже.)

Операции после обработки в случае появления ошибок переноса

В этом разделе рассматриваются способы устранения ошибок во время переноса документов в Central Finance.

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

После устранения причины сбоя проводки можно обработать в AIF. Перед повторной обработкой проводок в AIF основные счета и МВЗ, участвующие в проводке можно изменить.

До появления AIF использовался инструмент Error Correction and Suspense Accounting (ECS; устранение ошибок и учет по вспомогательным счетам). Однако AIF имеет перед ECS целый ряд преимуществ с точки зрения возможностей постобработки. Например, с помощью AIF можно обработать ошибки онлайн-репликации, связанные с проводками FI и вторичными проводками CO. В ECS ошибки, связанные со вторичной проводкой в CO, устранить невозможно.

AIF позволяет отправлять сообщения различным пользователям для анализа.

Выполните транзакцию /n/AIF/ERR. На появившемся экране (не показан) введите AIF в поле Application (Приложение) и выберите пиктограмму выполнения или нажмите клавишу F8. Откроется экран, представленный на рис. 5.

Рис. 5. Экран AIF для обработки ошибок

На рис. 5 видно, что выделенное сообщение об ошибке указывает на отсутствие присвоения для объекта затрат.

Какие транзакции можно перенести

Важно отметить, что Central Finance является системой централизованной финансовой отчетности, поэтому в Central Finance переносятся только документы FI и CO. Таким образом, документы логистики, в том числе связанные предшествующие документы (заказы на поставку или заказы клиента) не реплицируются. Документы материала (поступления материала, входящие счета и фактуры клиентов) также не реплицируются. Вместо этого бухгалтерские документы собираются вместе и переносятся как финансовые документы.

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

Табл. 2. Транзакции, не поддерживаемые во время переноса документов в Central Finance

Контрольный журнал — обратная развертка

Отделу финансов любой компании необходимо иметь возможность отслеживать и проверять перенесенные в целевую систему документы. Для этих целей Central Finance предлагает комплексное решение. Любой финансовый документ, перенесенный в целевую систему, можно связать с документом в исходной системе.

После несложной модернизации в зависимости от используемого приложения Central Finance позволяет выполнять обратную развертку не только в SAP ERP, но и в стороннюю систему ERP.

В заголовке документа появляются новые поля: Sender Logical System (Логическая система отправителя), Sender Company Code (Балансовая единица отправителя), Sender Document No. (Номер документа отправителя) и Sender Fiscal Year (Финансовый год отправителя). По этим данным можно определить, из какой исходной системы проводка была перенесена в Central Finance.

Выполните транзакцию FB03. На появившемся экране введите номер документа и просмотрите заголовок документа. В заголовке отображаются новые поля, см. Рис. 6.

Рис. 6. Новые поля в заголовке документа

Для просмотра связи финансового документа в Central Finance с исходным документом из системы-отправителя (заказ клиента, заказ на поставку или финансовый документ в исходной системе) можно также использовать браузер взаимосвязи документов.

Выполните транзакцию FB03 и просмотрите документ (экран не показан). После нажатия Environment (Среда), Document Environment (Среда документа) и далее Relationship Browser (Браузер отношений) появится экран, представленный на рис. 7.

Рис. 7. Обратная развертка из системы Central Finance в исходную систему

На рис. 7 показан бухгалтерский документ 100000817 в системе Central Finance и его связь с бухгалтерским документом 4400000727 из исходной системы.

В таблице ACDOCA хранится информация по основным счетам и носителям реальных затрат в исходной системе. Выполните транзакцию SE11. На появившемся экране (не показан) введите ACDOCA в поле Transparent Table (Прозрачная таблица), а затем выберите пиктограмму просмотра. Откроется экран, представленный на рис. 8.

Рис. 8. Поля в таблице ACDOCA с информацией из исходной системы

Дополнительно можно добавить больше полей в тот же include таблицы ACDOCA для сбора дополнительных данных из исходной системы, например, краткий текст или присвоение.

Также в системе Central Finance можно выполнять поиск документа по номеру документа в исходной системе.

Ключевые аспекты и рекомендации при работе с Central Finance

В среде Central Finance необходимо учитывать следующее:

  1. Отчетность по налогам — рекомендуется выполнять из исходной системы, поскольку в системе Central Finance коды налогов создаются с нулевым процентом. Проводки по основным счетам учета налогов переносятся только как проводки по обычным счетам Главной книги.
  2. Разделение документов — можно активировать в целевой системе без выполнения миграции новой Главной книги. Такая настройка применяется ко всем данным.
  3. Первичная загрузка — следует инициировать даже в том случае, если сальдо для миграции отсутствуют. Например, на этапе проверки концепции SAP рекомендует выполнять пустую загрузку. Это позволяет активировать функциональность репликации в исходной системе.
  4. На этапе проверки концепции первичная загрузка не используется для демонстрации переноса проводок операций в систему Central Finance в реальном времени, поскольку для них применяется другой процесс.
  5. Разделение себестоимости продаж (COGS) во время первичной загрузки — SAP не поддерживает разделение COGS во время первичной загрузки. Разделение компонентов затрат для COGS поддерживается только во время переноса в режиме онлайн.

Дорожная карта для Central Finance на будущее

Согласно дорожной карте SAP, опубликованной на Service Marketplace, компания SAP планирует реализовать следующие новые функции в будущих версиях Central Finance:

  1. Репликация СПП-элементов из исходной системы в целевую систему Central Finance
  2. Центральные функции платежей и выверки
  3. Репликация из калькуляционного Учета результатов (CO-PA)
  4. Центральный регистр материалов

Авторы

Аджай Махешвари вот уже более 13 лет работает архитектором решений SAP в сфере Финансов и Контроллинга (FI/CO). Он широко известен по своим публикациям на форуме SAP Community Network (SCN).

Автор входит в первую двадцатку самых активных участников форума SCN по всем модулям SAP и является одни из лидеров в своей специализации, SAP FI/CO.

Аджай — официальный преподаватель SAP. Он ежегодно получает признание как ведущий консультант форума SCN с 2011 года.

Автор принимал участие в проектах внедрения и развертывания SAP-систем в различных отраслях. Он получает удовольствие от проектирования комплексных бизнес-процессов и преподавательской деятельности по темам, связанным с FI/CO и S/4HANA.

В настоящее время Аджай на практике применяет свои знания в сфере бизнес-аналитики в FI/CO и является партнером SAP категории Platinum.

С автором можно связаться по адресу ajaycwa1981@gmail.com. 

Кавита Агарвал уже более 16 лет работает архитектором решений SAP Finance. Она широко известна по своим публикациям на форуме SAP Community Network (SCN) и является на этом форуме консультантом категории Platinum.

Кавита принимала участие в средних и крупных проектах внедрения и развертывания SAP в разных отраслях и регионах. Основную часть программ по трансформации финансов она выполняла в кондитерской промышленности. Автор получает удовольствие от проектирования комплексных бизнес-процессов и преподавательской деятельности по темам, связанным с SAP FI и S/4HANA.

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

С автором можно связаться по адресу kaviag06@gmail.com.

Корректура

Татьяна Шевченко — консультант FI-AA, CO. За её плечами более десяти лет опыта работы бухгалтером, отвечающим за международный учет, а затем за учет по стандартам US GAAP. Кроме того, у неё столь же богатый опыт работы ключевым пользователем FI, FI-AA SAP R/3. Татьяна участвовала в разработке методологии по отражению обесценения активов, результатов от продажи компании (push-down accounting), изменений в политике учета активов.