Двухуровневая ERP и SAP Business One: как это работает28.04.2018 11:18

Всем привет!

В этот раз мы решили вернуться к теме ERP-систем. В линейке продуктов SAP есть разные продукты для компаний самых разных размеров — от мультинациональных корпораций до среднего и малого бизнеса. Существуют и комбинации — когда в компаниях используют сразу несколько типов ERP, для штаб-квартир и для филиалов. Такие случаи и называют двухуровневыми ERP, и SAP Business One отлично подходит в качестве «облегченной» системы. В этой статье мы расскажем о подробностях и деталях интеграции.

Но для начала ответим на вопрос — что такое двухуровневая ERP?

Термин «двухуровневая ERP» уже стал привычным для многих. Концепт двухуровневой ERP-системы применяется в корпорациях, которым нужен единый стандарт отчетности и бизнес-приложений в своих дочерних структурах или филиалах. В маленьких бизнес-единицах по многим причинам просто нецелесообразно использовать большие ERP: другие бизнес-процессы, сложность адаптации сотрудников и медленная скорость развертывания, которое может занять месяцы. А если вы добавите сюда ещё время на обучение персонала, затраты на сопровождение системы и при всём этом вам необходимо внедрить «большое» решение сразу в 40 филиалах — на это уйдёт много времени (часто даже месяцы) и потребуются значительные затраты. Для сравнения — «маленькие» решения могут быть внедрены за несколько недель.

Двухуровневая ERP сегодня применима не только для больших корпораций, с их отношениями «штаб-квартира => филиал». Эта стратегия жизнеспособна при работе с поставщиками, дистрибьюторами, дилерами и обслуживающими организациями.

Пример нашего европейского клиента — компании Heineken Spain. У них появилась задача — как наладить обмен данными между 600 дистрибьюторами и Heineken Spain по заказам, движению товара и счетам на оплату и затем автоматизировать все процессы. В результате в компании решили разработать решение на базе SAP Business One.
В Heinekein Spain придумали сценарий с использованием интернета вещей — они собирают данные с более чем 300 тысяч датчиков, которые встроены в пивные краны. Компания получает информацию о потреблении пива с единую информационную систему. В результате в Heineken поняли, как лучше управлять каналом продаж, оптимизировать цепочку продаж и улучшить показатели. Также они стали получать данные о потреблении пива в режиме реального времени, можно сказать, «из каждого крана».

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

Зачем вообще внедрять ERP-системы в филиалах или дочерних компаниях? В крупных холдингах или больших компаниях, безусловно, хотят получать прозрачную аналитику или отчетность о бизнес-ппроцессах. При это часто случается такая проблема — в каждом филиале ставят своё решение, удобное местным специалистам, и в итоге в компании появляется «зоопарк» систем и сервисов. И конечно же, они могут быть не совместимы с «головной» ERP по самым разным причинам — например, из-за использования решений с закрытыми API. В этом случае нельзя надеяться ни на единую отчётность, ни на какую-то автоматизацию бизнес-процессов.

Что есть у SAP? У нас есть целая линейка ERP-систем, под разные задачи и цели. Для компаний со сложными бизнес-процессами нужны «тяжеловесы» — здесь выбирают S/4HANA, ECC или R/3. Для организаций попроще или поменьше подходит SAP Business One. При этом B1 легко может быть интегрирован с большими решениями SAP — S/4HANA, Hybris, Ariba, Customer Checkout, Concur, мобильные приложения и даже государственные сервисы.

Какие возможности есть в SAP Business One для разработки интеграционных сервисов:

.Net разработка для интеграции через SAP Business One SDK/DI-API
.Net разработка для интеграции через Service Layer (доступно для SAP Business One версия для SAP HANA)
Integration Framework (Интеграционная платформа)

Особенности, целевая аудитория и сфера применения приведены в таблице:

Далее статье мы в деталях расскажем о платформе Integration Framework.

Integration Framework

Платформа SAP Business One Integration Framework (B1iF) доступна в ERP-системе SAP Business One, начиная с версии 8.8. Её можно установить на базу данных SAP HANA или MS SQL. Основная задача B1iF — отправлять и принимать данные из внешних (SAP и неSAP) систем. Пакеты интеграционных сценариев строятся внутри Integration Framework. Логика сценариев основана на бизнес-процессах: управление ошибками, конфликтами, транзакциями (и их порядком выполнения), гарантия выполнения, мониторинг, отладка и администрирование выполняются в B1iF.

Для разработки сценария интеграции двух систем навыки программирования не требуются.
Последовательность процесса задаётся с помощью встроенного графического дизайнера в платформе. Встроенные функциональные единицы B1iF BizFlow Atoms используются для сопоставления значений, настройки вызовов (SAP Business One, SAP ERP, HTTP, SQL, файловые системы и т.д.), XSLT преобразований. Сопоставление данных осуществляется с помощью XSLT-преобразований во встроенном (или внешнем) XML редакторе. Инструменты отладки позволяют разработать индивидуальную последовательность процесса в структурированном и наглядном виде.

Интеграционные сценарии, которые выполняются в интеграционной платформе, называются пакетами сценариев. Все необходимое для целостного обмена данными между системами находится в пакете сценария.
Пакет сценария содержит в себе один или более шаг сценария. Шаг сценария — это определенный интеграционный поток, который включает в себя входящую (inbound) фазу, фазу обработки (processing) и исходящую (outbound) фазу.

На первой фазе интеграционная платформа получает входящее сообщение и переводит его в XML формат. В процессе фазы обработки происходит трансформация и обработка сообщения, определение получателя и сопоставление параметров сообщения. На этапе вывода интеграционная платформа трансформирует сообщение в формат ERP-системы получателя и отправляет сообщение.

В процессе дизайна шага сценария необходимо задать основные параметры: способ запуска шага, какие системы взаимодействуют между собой, каким образом интеграционная платформа обрабатывает сообщение, существуют ли дальнейшие шаги (например, вызов внешней системы).

Шаги сценария могут быть следующими:

1. Синхронные (запрос-ответ):
— отправитель формирует запрос, который инициирует выполнение шага
— результат обработки возвращается отправителю как ответ

2. Асинхронные (отправитель получателю):
— запускается по таймеру, событию или вызову
— данные поступают из системы-отправителя, обрабатываются, трансформируются и передаются получателю в любое время

Входящий канал описывает тип системы-отправителя и интерфейс (API), которые могут быть использованы интеграционной платформой для получения входящих данных. В качестве входящего канала могут быть использованы HTTP, файл, пустое сообщение (Void (таймер)), Web Service, SAP Business One и SAP ERP.

Исходящий канал описывает тип системы-получателя и интерфейс (API), который будет использован интеграционной платформой для передачи данных. В качестве исходящего канала могут быть выбраны HTTP, файл, пустое сообщение (Void, только для синхронных шагов), Web Service, база данных, SAP Business One и SAP ERP.

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

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

Пример разработки интеграционного сценария

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

Давайте рассмотрим простой практический пример интеграции двух систем — заказчика и поставщика. Обе компании работают в SAP Business One и хотят автоматизировать процесс оформления заказов. В данном примере «Заказ на закупку» в компании 1 передается в компанию 2, где формируется документ «Заказ на продажу». Компания 2 подтверждает формирование заказа в компанию 1.

Интеграционный сценарий можно запустить при помощи создания документа «Заказ на закупку» в компании 1. В сценарии будет 2 интеграционных шага:

на первом шаге формируется документ «Заказ на продажу» в компании 2 с помощью атома B1 Object call
атом Call Step используется для связывания со вторым шагом
на втором шаге происходит информирование пользователя компании 1 о статусе созданного документа «Заказ на продажу»

Для запуска интеграционного сценария нам потребуется код основных данных компании 1. Эти данные не содержатся в «Заказе» и не передаются в интеграционную платформу. Для хранения этой информации может быть использована глобальная таблица (global table). Для задания параметров глобальной таблицы необходимо определить тип глобальной таблицы (тип 1 для отношений 1<->1; тип 2 для отношений 1 <-> N), длину и названия полей таблицы:

После создания глобальной таблицы можем внести в нее данные:

Далее для интеграционного шага 1 определим входящий канал:

тип канала — SAP Business One
запуск по событию B1 Event (создание документа «Заказ на закупку»)
в качестве идентификатора используется ID объекта «Заказ на закупку» (22)
получение данных по DI-API с типом Объект

Для исходящего канала выбираем пустое сообщение (void), т.к. у нас нет системы-получателя:

Перейдем к конфигурации процесса обработки сообщения. Нумерация атомов осуществляется в порядке добавления в процесс.

Атом преобразования (атом¹) является не обязательным. Он позволяет хранить информацию об условиях запуска и системе-отправителе для последующего использования в других атомах. Значение CustomerCode для компании 1 загружается из глобальной таблицы. Значение User ID выбирается из секции T (запуск, trigger) XML преобразования входящего события B1 Event, создающего «Заказ на закупку».

При конфигурации атома B1 Object (атом²) будем использовать следующие параметры:

Sysid: ID, присвоенный SAP Business One в интеграционной платформе
B1 Login: присваивается из настроек интеграционной платформы
Method: синхронный
Object identifier: 17 (заказ на продажу)
Key Name: DocEntry
Key Value: N/A (заполняется автоматически в момент создания документа в SAP Business One)
Payload: имя предшествующего атома преобразования

Перед атомом B1 Object мы используем предшествующий атом преобразования (атом³). В этом атоме подготавливается информация для загрузки в атом² (B1 Object).
В разделе Documents необходимо определить значения заголовка документа «Заказ на продажу»:

код основных данных заказчика для компании 1 (CardCode)
дата документа (DocDate) задается вызовом функции даты и времени, встроенной в интеграционную платформу, которая возвращает текущую дату и время
дата отгрузки (DocDueDate) вычисляется на основе DocDate

В разделе Document_Lines определяются строки документа «Заказ на продажу». Необходимая информация извлекается из секции S (сообщение из системы-отправителя, sender message) входящего документа «Заказ на закупку».

Завершающий атом (атом⁰), как правило, преобразовывает данные для передачи в систему-получатель. В нашем сценарии в качестве типа исходящего канала выбрано пустое сообщение (void). Тем не менее, мы должны определить данный атом для создания записи в логах. В элементе будут содержаться атрибуты DIresult и DImsg. Атрибут DImsg должен содержать ключ созданного документа (в случае успешного завершения сценария) или сообщение об ошибке (в случае неуспешного выполнения).

Атом⁴ и атом⁵ относятся ко второму интеграционному шагу: отправка сообщения пользователю компании 1. Атом вызова (с типом Call step) не подразумевает предшествующий атом преобразования. Тем не менее, как и в случае первого шага, для атома4 мы зададим предшествующий атом преобразования (атом⁵). В параметрах атома5 указываем данные, передаваемые в вызываемый атом. Эти данные в нашем случае будут содержать элемент с атрибутами DIresult (результат обработки атома B1 Object) и код пользователя SAP Business One (B1User).

Для атома вызова задаем параметры:

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

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

Для атомов с условиями может быть использовано несколько атомов с типом path и только один атом типа otherwise. Интеграционная платформа работает только с результатами истина при выполнении path. Поэтому, в нашем случае необходимо задать только условие для атома path:

/*[/vpf: Msg/vpf: Body/vpf: Payload[./@Role='S']/B1Result/Result = 'success']

Атом otherwise будет работать только в том случае, если результатом выполнения атома path будет ложь. Атом unbranch завершает ветвление и содержит результаты выполнения атомов условий.

В параметрах атомов B1 Message необходимо указать тему и текст сообщения, а также информацию о пользователе

/vpf: Msg/vpf: Body/vpf: Payload[./@Role='S']/B1Result/B1User

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

Активация и проверка сценария

Интеграционная платформа проверяет целостность интеграционного сценария при открытии окна настройки сценария.

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

После создания документа мы видим уведомление от пользователя B1i, что заказ создан успешно:

В компании 2 создан «Заказ на продажу» с данными из «Заказа на закупку» и указанием номера документа в компании 1:

Заключение

В качестве заключения предлагаю посмотреть ролик нашего клиента — компании DeLaval. Компания уже давно и активно использует стратегию двухуровневой ERP: в головном предприятии и в крупных филиалах — SAP ERP, а в малых дочерних структурах — SAP Business One. В этом видео Steve Woodgate, Business Integration Director в компании DeLaval, рассказывает о причинах и результатах выбора SAP Business One в качестве ERP второго уровня.

Ознакомиться с примерами внедрений SAP Business One можно на нашем сайте.

Видео с обзорами возможностей решения и не только доступно на нашем Youtube-канале.

В следующей статье мы расскажем о возможностях новой версии SAP Business One 9.3, которую сейчас активно тестирует как SAP, так и клиенты. Кстати, одним из первых «живых» клиентов в мире на SAP Business One версия 9.3 стал заказчик из России — компания «Телеком-Биржа». Видео с комментариями клиента можно посмотреть здесь: youtu.be/GTgm-nJddDI

Всем спасибо за прочтение и обратную связь!