Предпосылки

Почему этот вопрос так важен?

В первую очередь потому, что подключение различных систем к интерфейсу CFIN позволяет в полной мере использовать возможности системы S/4 HANA для достижения различных целей:

1. Для целей управленческого учета, в том числе МСФО учета:
   1. Возможность оперативного принятия управленческих решений за счет анализа рентабельности продаж в режиме реального времени в рамках группы;
   2. Повышение прозрачности и аналитичности управленческих отчетов за счет доступа к транзакционному уровню данных и, как следствие, снижение трудозатрат на подготовку управленческой отчетности в рамках группы;
   3. Возможность осуществления как параллельного, так и трансформационного МСФО учёта в рамках группы компаний в едином корпоративном финансовом шаблоне;
2. Для целей консолидации:
   1. Оперативная выверка внутригрупповых оборотов (ВГО) в режиме реального времени;
   2. Формирование консолидированной отчетности на уровне S/4 HANA в оперативном режиме, с возможностью детализации до транзакционного уровня;
3. Для целей налогового учета:
   1. Организация доступа к транзакционному уровню данных для задач налогового мониторинга;
4. Для целей казначейства:
   1. Построение единой системы управления дебиторской задолженностью в группе Компаний.

Цель данной статьи заключается в представлении экспертного мнения в профессиональном сообществе о доступных альтернативах при реализации интеграции «1С» приложений и CFIN, основанном на существующем в РФ и странах СНГ опыте и лучших мировых практиках. Указанный сценарий интеграции является наиболее востребованным на территории РФ.

Статья опирается на S/4 HANA 1909, но также применима к более ранним версиям, если не указано иное. Для знакомства с Central Finance, рекомендуется изучение курсов S4F60 и S4F61.

Варианты решений

На сегодняшний день существует всего два подхода к реализации:

• Промышленный метод реализации через SourceConnect by Magnitude (далее решение от Магнитьюд).
• Реализация собственной разработки коннектора.

Как правило, второй подход чаще всего обусловлен двумя причинами:

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

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

Способы интеграции с не-SAP системами

Как же обеспечить взаимодействие системы CFIN и систем-источников «1С»?

Традиционно интерфейс взаимодействия с не-SAP системами представлен на рис.1

Рис.1 Классическая архитектура Central Finance

Основная задача состоит в реализации коннектора, который должен обеспечивать выгрузку данных из не-SAP системы, выполнять мэппинг и заполнять Staging-tables (промежуточные таблицы).

Учитывая, что в настоящий момент существует два подхода, рассмотрим каждый из них с точки зрения следующей структуры:

1. Передача основных данных из приложений «1С»
2. Выгрузка транзакционных данных из приложений «1С»
3. Обратная проводку в приложения «1С» (Back-posting/SyncBack)
4. Мэппинг технических данных и аналитических признаков для перекладки транзакционных данных в специальные staging-таблицы
5. Сверка как основных данных, так и транзакционных данных
6. Переход от документа (далее «Проваливание» или drilldown) из центральной системы к данным приложений «1С»

Механизм интеграции от компании Магнитьюд [1]

Компания Магнитьюд уже много лет занимается реализацией механизмов интеграции для обеспечения взаимодействия не-SAP систем и системы CFIN. В 2020 году, начались работы по разработке механизма интеграции между приложениями «1С» и CFIN. На момент написания данной статьи, решение от компании Магнитьюд является расширением (addon) к CFIN и лицензируется отдельно, как SAP-продукт.

В решение входят следующие функциональные блоки:

1. Репликация транзакционных данных от Магнитьюд
   • Предопределенные шаблоны мэппинга
   • Репликация финансовых транзакционных данных из не-SAP систем в CFIN
   • Взаимодействие с пользователем для обработки интегрированных данных
2. Гармонизация данных от Магнитьюд
   • Обработка существующих основных данных в SAP и не-SAP системах-источниках
   • Обеспечение определения такой записи основных данных, которая может быть принята за эталонную (первичную)
   • Загрузка основных данных и бизнес-правил в систему CFIN
   • Взаимодействие с пользователем для обработки интегрированных данных

Архитектура решения представлена на рисунке 2 ниже:

Рис.2 Архитектура решения от Магнитьюд

1. ERP: Обозначает исходные системы или плоские файлы, содержащие данные финансовых транзакций.
2. CDC: Означает схему, которая содержит объекты, связанные с системой отслеживания измененных данных (CDC – Change Data Content). Данная схема находится в той же базе данных, что и исходная система. Она используется для:
   • хранения специфичных для системы-источника скриптов, связанных с ракурсами извлечения данных и с проверками;
   • фиксации последовательных изменений данных финансовых транзакций в исходной системе;
   • хранения промежуточных таблиц для сбора инвойсов и соответствующей платежной информации в SAP S/4 HANA для обратной проводки.
3. SAP Data Services: Обозначает инструмент, который помогает извлекать исходные данные из исходной системы, преобразовывать данные и загружать их в промежуточную базу данных.
4. Staging database: Обозначает промежуточную базу данных, содержащую два набора промежуточных таблиц: временные промежуточные таблицы и технические таблицы FIN% (например, FIN_HEADER, FIN_DEBIT и др.). 
5. SLT Replication Server: Обозначает сервер репликации SLT, на который загружаются данные из таблиц FIN% в промежуточной базе данных. Для получения информации о том, как настроить таблицы SLT Replication Server для сторонних систем, см. SAP Help Portal.
6. SAP S/4HANA: Указывает на систему SAP с поддержкой CFIN.
7. Magnitude ABAP Component: Обозначает компонент, который импортирует объекты развертки (drilldown) и согласования в SAP S/4 HANA. В компонент также входят приложения SAP Fiori и CDS-views.
8. Magnitude MTA Application: Обозначает приложение Магнитьюд MTA, развернутое в базе данных SAP HANA через SAP HDI. Приложение помогает создавать объекты базы данных, такие как схемы, представления и виртуальные таблицы, в базе данных SAP HANA. Виртуальные таблицы указывают на данные в промежуточной базе данных через интеллектуальный доступ к данным - Smart Data Access (SDA).
9. SyncBack: Обозначает компонент SyncBack, который можно использовать для полного или частичного выравнивания открытых инвойсов клиента/поставщика в исходной системе, если включена функциональность централизованных платежей.
10. Reconciliation Levels: Относится к различным уровням отчетов cверки, в которых сравниваются данные транзакций на различных этапах преобразования из исходной системы в SAP S/4 HANA.
11. SAP Fiori: Обозначает приложения SAP Fiori, используемые для отчетов по «проваливанию» или для сверки.

Далее, рассмотрим решение от Магнитьюд более детально:

1. Обеспечение передачи основных данных из приложений «1С»

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

Рис.3 Компоненты модуля гармонизации данных

Модуль Гармонизации данных включает в себя четыре ключевые возможности, которые помогают ускорить и автоматизировать многие ручные задачи, связанные с переносом основных данных из систем-источников в CFIN и MDG (Master Data Government):

1. Предварительное извлечение (экстракция) нескольких категорий основных данных из многих ERP плюс использование универсального формата плоского файла от Магнитьюд.
   1. 1. Включает в себя извлечение всех записей при первичной выгрузке, а также постоянный сбор новых записей при дальнейшей работе;
      2. Обеспечивает загрузку основных данных из исходной системы, отличной от SAP, с использованием API / доступных стандартных интерфейсов.
2. Инструмент профилирования данных, помогающий оценить качество исходных данных в сравнении с требованиями CFIN.

1. Позволяет пользователю определять любые действия по очистке данных, которые могут потребоваться на ранней стадии проекта;
2. Включает обработку исторических и текущих основных данных, а также загрузку мэппинга и устранение дублей. Исторические данные можно настроить для мэппинга с активными транзакциями перед их загрузкой в CFIN. Доступна полная история аудита любых изменений основных данных.

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

1. Включает преобразования данных в структуры SAP (бизнес-партнеры, совокупность балансовых единиц и т. д.) и внедрение любых необходимых бизнес-правил.

4. Предварительно реализованный процесс загрузки подготовленных записей (основные данные и мэппинг настроек) в CFIN и MDG.
   1. 1. Интерфейс основных данных использует специальные BAPI от Магнитьюд в CFIN для управления мэппингом и создания основных данных. Эти RFC-функциональные модули от Магнитьюд представляют собой оболочки для стандартных CFIN BAPI (пример - CL_MD_BP_MAINTAIN для деловых партнеров). API мэппинга от Магнитьюд позволяет выполнять любые обновления мэппинга на основе изменений основных данных в исходных ERP.
      2. Наличие интерфейса для клиента, поставщика, материала, проекта / СПП-элемента, центра затрат, основной записи основного счета.
      3. Расширяемая структура позволяет добавлять объекты основных данных для гармонизации основных данных.

Если данные не удалось сопоставить друг с другом, то эти ошибки отражаются в интерфейсе AIF в CFIN.

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

Для обеспечения корректной работы основных мэппингов, необходимо на этапе настройки системы, выполнить мэппинг полей основных данных (группа счетов, контрольный счет, налоговая информация и т. д.). Данный мэппинг выполняется вручную, через отдельный интерфейс, так как статические элементы конфигурации (редко меняющиеся параметры настройки) необходимо настраивать в CFIN. Модуль от Магнитьюд может извлекать такие элементы данных из исходных 1C и предоставлять заказчику / системному интегратору для создания в CFIN.

Если у клиента есть собственная MDG-система, то данные из нее возможно загрузить в интерфейс Magnitude SourceConnect через плоский файл / xml. При этом, есть возможность настроить приоритет для данных определенной системы (в случае если основные данные поступают из нескольких систем).

Процесс гармонизации данных тесно связан с процессом передачи транзакционных данных.

Рис.4 Процесс гармонизации данных

Возможности модуля Гармонизации данных объясняют почему те компании, которые уже используют Магнитьюд, при необходимости подключения новых систем, в том числе SAP-систем, предпочитают делать это используя функциональность от Магнитьюд.

2. Обеспечение выгрузки транзакционных данных из приложений «1С»

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

Рис.5 Поток транзакционных данных из 1С

Ключевые особенности блока репликации транзакционных данных от Магнитьюд:

1. 1. Обеспечивается загрузка данных из исходной системы, отличной от SAP (в настоящее время используются стандартные API)
   2. Обеспечивается перенос и мэппинг загруженных данных из исходной системы, отличной от SAP, в формат промежуточных таблиц SAP.
   3. Обеспечивается хранилище данных для детализации проводок (для проваливания)
   4. Предоставляются расширенные отчеты о сверке. Важно понимать преимущества отчетов сверки от Магнитьюд. Они позволяют выполнять более детальный анализ расхождений и более точно идентифицировать место возникновения и причину расхождений.
   5. Внедрение функциональности для обновления информации о статусе платежа в исходную систему, не относящуюся к SAP.
   6. Автоматизированная обработка изменений полей документов, которые являются не изменяемыми в системе SAP S/4 HANA: если интерфейс обнаруживает подобные изменения, то он инициирует проводку сторно первичного документа на стороне CFIN и повторную проводку документа с учетом изменений.
   7. Реализация большого количества проверок документов для минимизации количества ошибок AIF. Ниже приведены примеры таких проверок:
      1. Проверка на предмет балансировки документа
      2. Преобразование типа и длины данных в требования интерфейса SAP
   8. Обогащение дополнительной информацией о транзакциях (по клиентам, поставщикам, материалам, активам, WBS и т. д.) из вспомогательных справочников/регистров из исходных 1С.
   9. Обработка 100% документов относящихся к проводкам:
      1. Сальдо по счетам
      2. Открытые позиции ДЗ/КЗ
      3. История операций в том числе изменения документов
      4. Репликация документов в режиме реального времени
   10. Есть возможность расширения аналитических признаков и для репликации данных, и для реализации drilldown.

3. Обеспечение обратной проводки в приложения «1С» (back-posting)

Обратные проводки в приложение «1С» реализуются также при помощи специальных API, которые позволяют, например, создать документ платежа в приложении «1С».

Например: -X POST odata/standard.odata/Document_InvoicePayment?$format=json

4. Обеспечение мэппинга технических данных и аналитических признаков для перекладки транзакционных данных в специальные staging-таблицы

Мэппинг технических данных встраивается в процесс извлечения данных из системы-источника. Он выполняется с использованием комбинирования ракурсов экстракции данных и специально разработанного функционала бизнес-правил.

Технические атрибуты не могут быть сопоставлены при помощи стандартного MDG. Специально разработанная структура мэппинга используется для определения связанных данных между приложениями «1С» и SAP.

5. Обеспечение сверки как основных данных, так и транзакционных данных и обработка ошибок

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

Рис.6 Уровни сверки данных

Процедура сверки у Магнитьюд выполнена на пяти уровнях данных:

1. Отчет по сверке между исходной системой и SAP Data Service – выполняется сверка данных полученных при помощи API из системы-источника и таблицами STAGE1, куда эти данные загружаются. Выполняется сверка по суммам и по количеству документов. В таблицах STAGE1 определяются все бухгалтерские транзакции из источника и выполняется проверка обязательных полей и типа данных / длины данных. В таблицах STAGE1 также разделяются (если в документе более 999 строк и суммы превышают 11 цифр) и балансируются документы.
2. Отчет по сверке внутри SAP Data Service. На этом уровне идет сверка между STAGE1 и STAGE2. В таблицах STAGE2 документы разбиты в соответствии с форматом SAP (заголовок, позиции основных счетов, кредиторские и дебиторские позиции, налоговые позиции, выравнивания). Отчет помогает убедится, что все документы корректно переданы в таблицы FIN% после преобразований.
3. Отчет по сверке данных между SAP Data Service и SLT-сервером. На этом уровне идет сверка между STAGE2 и данными в промежуточных таблицах на стороне SLT. Сравнение сумм, количеств и атрибутов по каждой позиции документа. Структура таблиц STAGE2 очень схожа со структурой промежуточных таблиц SLT. Отчет помогает убедиться, что все документы переданы в интерфейсные таблицы.
4. Отчет по сверке между SAP SLT и универсальным журналом. Отчет обеспечивает сравнение данных промежуточных таблиц SLT и данных ACDOCA и BKPF для каждой позиции документа. Он помогает убедиться, что все документы переданы на сторону CFIN.
5. Отчет по сверке между системой-источником и универсальным журналом. Сверка между данными репозитария, куда выгружаются первичные данные из системы-источника, и данными универсального журнала. Данный отчет позволяет выполнить заключительную сверку сумм, количеств и данных документов между данными исходной системы и CFIN.

Кроме этих отчетов предусмотрены еще два дополнительных отчета:

1. Отчет по балансу – Данный отчет сравнивает сальдо счета между временными данными системы-источника в STAGE1 и данными универсального журнала. В этот отчет также попадают все расхождения в стоимостях, возникших при обработке ошибочных ситуаций в AIF или при проводке операций в системе.
2. Отчет исключений – Данный отчет предоставляет информацию о документах, которые не были проведены в SAP из-за возникших исключительных ситуаций. Исключительная ситуация, как правило, возникает, если документ не удовлетворяет стандартным проверкам при проводке.

Стоит отметить, что в части сверки данных, Магнитьюд расширяет возможности стандартной функциональности CFIN. В стандарте имеется один уровень сверки данных, поэтому сверка выполняется лишь между системой-источником и центральной системой. При этом, при выявлении ошибки, бывает сложно понять на каком именно этапе она возникла и чем вызвана. Например, в AIF не попадает ошибка интеграции/мэппинга на стороне SLT, либо система выдает ошибку, которая требует детального анализа. В функциональности Магнитьюд, благодаря многоуровневой сверке, имеется возможность легко понять в какой момент и из-за чего произошла ошибка и внести необходимые корректировки.

Все проверочные отчеты реализованы на FIORI и на базе Analyzes for Office. FIORI-отчеты скомпонованы в единый Dashboard (см. на скриншоте ниже)

Рис.7 Пример панели отчетов Fiori от Magnitude

В дополнение, более детально рассмотрим процесс обработки ошибок, начиная от обнаружения ошибки до ее корректировки

Благодаря продуманной архитектуре решения, Магнитьюд уменьшает процент ошибок, а в некоторых случаях устраняет многие типичные ошибки - примеры включают в себя разбиение большого документа (более 999 позиций), преобразование дат, ошибки округления и т. д. Оставшиеся ошибки, обычно попадают в функциональные или технические категории.

Функциональные ошибки обычно передаются в AIF, где происходит обычное устранение неполадок, исправление и повторная обработка.

Технические ошибки (например, сбой сети, сервера или базы данных) обрабатываются следующим образом:

1. В случае возникновения технической ошибки, задания (jobs) Магнитьюд DS отправят уведомление соответствующему ИТ-специалисту или группе ИТ-специалистов с подробной информацией об ошибке.
2. Техническая команда диагностирует и исправляет исходную ошибку (например, восстанавливает сетевую ссылку).
3. «Администратор» Магнитьюд выполняет шаги в соответствии с инструкцией для перезапуска заданий и повторной обработки неудачных транзакций.
4. Отчеты по согласованию данных могут использоваться для идентификации документов с различным статусом обработки («В процессе», «Техническая ошибка», «Функциональная ошибка», «Отменено», «Успешно с предупреждением» и «Успешно»). Отчет об исключениях предоставляет подробную информацию об ошибке на каждом этапе процесса преобразования.

6. Обеспечение drilldown из центральной системы к данным приложения «1С»

Рис.8 Переход к данным первичного документа из не-SAP системы

Приложение от Магнитьюд предназначенное для перехода в первичный документ реализовано, как расширение Manage Journal Entries Fiori app, и показывает данные соответствующие типу документа в универсальном журнале. Если документ является инвойсом клиенту, приложение отображает соответствующие данные из системы-источника (основные счета, контрагент, данные отгрузки и т.д.). Если документ является входящим инвойсом, приложение отображает соответствующие данные из системы-источника (основные счета, поставщик, данные поставки и т.д.). Для прочих типов документов выводится информация релевантная данным проводки по основным счетам.

Механизм Drilldown может быть расширен дополнительными полями. Важно понимать, что функционал от Магнитьюд не создает логистические проводки, но собирает все необходимые данные либо в поля универсального журнала, либо в специальный репозиторий Drilldown на стороне SAP Data Service (по сути отдельная таблица в базе данных HANA).

Реализация коннектора собственными силами

Рассмотрим реализацию коннектора собственными силами также в разрезе указанной структуры:

1. Передача основных данных из системы 1С
2. Выгрузка транзакционных данных из системы 1С
3. Обратная проводку в систему 1С (back-posting)
4. Мэппинг технических данных и аналитических признаков для перекладки транзакционных данных в специальные staging-таблицы
5. Сверка как основных данных, так и транзакционных данных
6. Переход от документа (drilldown) из центральной системы к данным системы 1С

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

1. Передача основных и транзакционных данных, а также реализация обратной проводки.

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

Для обеспечения интеграции программных продуктов компании «1С», как между собой так и между сторонними приложениями, был разработан специальный формат обмена данными EnterpriseData. Данный формат является бизнес-ориентированным и базируется на XML. Описанные в нем структуры данных соответствуют документам и элементам справочников, представленным в программах «1С», например: акт выполненных работ, приходный кассовый ордер, контрагент, договор и т. п. С одной стороны это облегчает понимание операций, с другой стороны несколько затрудняет мэппинг на структуры SAP, так как наименования документов и справочников приведены на кириллице.

Детальное описание формата EnterpriseData (ED) и его использование для обмена данными приведено в приложении к статье.

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

• «1С:ERP Управление предприятием 2.0»,
• «Бухгалтерия предприятия», редакция 3.0
• «Бухгалтерия предприятия КОРП», редакция 3.0
• «Розница», редакция 2.0,
• «Управление торговлей базовая», редакция 11
• «Управление торговлей», редакция 11,
• «Зарплата и управление персоналом КОРП», редакция 3.

Далее рассмотрим как выглядит обмен данными при помощи ED.

На рисунке 9 представлен возможный вариант обмена данными при помощи формата ED

Рис.9 Вариант обмена данными

Для обеспечения обмена данными в формате ED между приложением «1С» и сторонним приложением SAP, необходимо на стороне «1С» выполнить настройку для синхронизации данных. В настройке необходимо указать уникальный код приложения, с которым будет производиться обмен, а также определить по какому каналу будет происходить обмен данными. В настоящий момент доступны следующие опции:

• веб-сервис;
• файловый обмен через каталог;
• файловый обмен через FTP;
• обмен через электронную почту.

Рассмотрим эти опции чуть детальнее.

1. Обмен через веб-сервис

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

Для двухстороннего обмена между конфигурацией «1С» и сторонними приложениями, на стороне «1С» должен быть развернут веб-сервис EnterpriseDataExchange. Двухсторонний обмен требуется для реализации обратной проводки.

При использовании веб-сервиса инициатором сеанса обмена выступает стороннее приложение. В нашем случае SAP-приложение (Data Service). Упрощенно процесс выглядит так:

1. Для получения данных от приложения «1С» нашему SAP-приложению (DataService) нужно вызвать веб-метод GetData, передав в качестве параметров метода уникальный код приложения, введенный при настройке синхронизации «1С».
2. В ответ «1С» вернет файл, содержащий данные о бизнес-объектах в формате ED.
3. Далее работа по мэппингу данных будет происходить уже на стороне Data Service.

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

2. Обмен через другие каналы (файловый обмен, электронная почта)

В случае обмена данными (файловый обмен) через каталог/FTP каталог или электронную почту инициатором обмена будет выступать приложение «1С».

Оно будет помещать в соответствующий канал (каталог или почтовый ящик) файл описанного специального формата и ожидать от стороннего приложения в этом же канале ответных файлов.

В случае обмена через каталог/FTP каталог, имя файла должно быть составлено специальным образом (Message_<КодОтправителя>_<КодПолучателя>.xml), чтобы приложение «1С» смогло его обработать.

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

Также для вариантов с файловым обменом через каталог и электронную почту, на стороне «1С» настраивается, с какой периодичностью будет происходить синхронизация:

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

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

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

2. Мэппинг технических данных и аналитических признаков

Этот этап с точки зрения трудоемкости и важности – ключевой. Подавляющее количество ошибок, как правило связано именно с мэппингом данных. Речь идет, в первую очередь, о мэппинге данных из XML-файла в формате ED в формат Staging tables на стороне SLT.

Staging Tables – это промежуточные таблицы, необходимые для организации интерфейса сторонней системы. Они представляют собой запись журнала, которая должна быть проведена в системе CFIN.

Мэппинг реализуется на стороне SAP-системы при помощи разработки. На основе XSD-схемы выстраиваются маршруты обработки данных в зависимости от типов передаваемых данных.

В случае с приложениями «1С» мы имеем дело с двум типами данных:

1. Справочник (основные данные)
2. Документ (транзакционные данные)

Соответственно, при передаче объекта с типом «Справочник», потребуется выполнить следующие шаги:

1. Определить какие основные данные соответствуют этому справочнику в системе SAP
2. Проверить наличие передаваемой записи справочника в справочнике в системе SAP
3. Если запись отсутствует, то:
   • Либо инициировать ошибку, с отправкой уведомления ответственному лицу. Если автоматическое создание основной записи в справочнике невозможно.
   • Либо инициировать выполнение BAPI-функции (если SLT и CFIN развернуты на разных инстанциях, то потребуется организация RFC-вызовов) для создания соответствующей основной записи в системе SAP. Перед этим возможно потребуется выполнить дополнительное заполнение обязательных, для создания записи в SAP, полей.
4. Обновить/создать мэппинг в интерфейсе MDG foundation

 При передаче объекта с типом «Документ», алгоритм несколько иной:

1. Подготовка Staging tables.