CC BY
109
International Journal of Open Information Technologies ISSN: 2307-8162 vol. 3, no. 3, 2015
Реализация гетерогенного межкорпоративного документооборота (ЭДО) в ERP системах
Леонидов В.Н.
Аннотация— В работе описана предметная область, объектами которой являются учетная система предприятия и его контрагенты, между которыми осуществляется обмен юридически значимыми документами стандартных форматов по утвержденному регламенту через операторов электронного документооборота (ЭДО), проведен анализ возможных схем такого взаимодействия и их существующих реализаций.
На основании проведённого анализа предложена концептуальная схема гетерогенного адаптера и ее практическая реализация для системы SAP ERP, удовлетворяющая предъявляемым требованиям как со стороны операторов ЭДО, так и со стороны учетной системы.
Ключевые слова—гетерогенный адаптер, оператор ЭДО, веб-сервис.
I. Введение
В настоящее время система электронного документооборота (СЭДО) является неотъемлемой частью IT- инфраструктуры предприятия, которая обеспечивает реализацию концепции безбумажного делопроизводства, позволяющую получить снижение расходов на различные виды потребляемых ресурсов в процессе жизнедеятельности. О достоинствах СЭДО написано немало литературы, где приведено большое количество практических примеров внедрения, приведена подробная классификация систем по типам ЭДО и видам документооборота. Более подробно об этом можно узнать из приведенных источников [1, 2].
В настоящей работе рассмотрена лишь часть ЭДО в контексте организации процесса взаимодействия предприятий путем обмена юридически значимыми документами. Такой обмен осуществляется через операторов ЭДО. В настоящее время существуют интеграционные решения отдельно для каждого оператора ЭДО. В этом случае, для взаимодействия предприятия со своими контрагентами через нескольких операторов ЭДО, необходимо иметь семейство адаптеров к операторам ЭДО. Такая схема имеет ряд существенных недостатков:
Статья получена 12 декабря 2014. Работа является результатом магистерской диссертации «Реализация гетерогенного межкорпоративного документооборота (ЭДО) в ERP системах»
- задача маршрутизации при такой схеме возлагается на пользователя;
- нет единого интерфейса пользователя;
- сложность технической поддержки;
- добавление нового оператора ЭДО приводит к новой разработке;
Предлагаемая в работе схема позволяет устранить эти недостатки. При такой схеме взаимодействие осуществляется через гетерогенный адаптер, с использованием единого интерфейса пользователя.
II. НАЧАЛЬНЫЕ СВЕДЕНИЯ И ОПРЕДЕЛЕНИЯ
A. Описание исходных данных
Ключевые требования:
- со стороны законодательства [3-12]:
- формат документов xml в соответствии с утвержденными xsd;
- выполнение утвержденного регламента обмена для каждого типа документа;
- использование механизма цифровой подписи.
- со стороны оператора ЭДО:
- использование API провайдеров;
- формат сообщения;
- использование библиотеки КриптоПро.
- со стороны ERP SAP:
- среда разработки ABAP Workbench;
- реализация стандартной функциональности.
B. Постановка задачи
Для обеспечения процесса обмена документами ERP-системы с УЦ существуют реализации адаптеров к конкретным УЦ, основанные, в основном, на реализации API, предоставляемых УЦ для разработки интеграционных решений.
В рамках магистерской диссертации необходимо выполнить две задачи:
- разработать концепцию гетерогенного адаптера;
- реализовать адаптер, на основе разработанной концепции, в ERP- системе.
C. Общие сведения для разработки интеграционного решения Такском-Доклайнз
Интеграционное решение должно автоматизировать взаимодействие между ERP или учётной системой и Т акском-Доклайнз. Сложность разработки
интеграционного решения в значительной степени зависит от правильного выбора средств разработки интеграционного решения (рис 1).
Леонидов В.Н., МГУ имени М.В. Ломоносова (email: doffleoni @ mail.ru)
17
International Journal of Open Information Technologies ISSN: 2307-8162 vol. 3, no. 3, 2015
Рис. 1 Т акском: Общая схема интеграции
Для разработки интеграционного решения для Такском-Доклайнз необходимо понимание следующих вопросов:
- Формирование XML файлов и парсинг в соответствии с XSD схемами электронных документов, служебных сообщений и команд Такском-Доклайнз.
- Использование криптопровайдера (CSP) для формирования и проверки электронных подписей документов и служебных сообщений
- Выполнение регламента как последовательности транзакций документооборота и документообороты разных типов
- Применение исходящих и входящих транспортных контейнеров
- Авторизация в Такском-Доклайнз, применение защищенного транспортного протокола. [15]
D. Общие сведения для разработки интеграционного решения Диадок
Интеграционное решение должно автоматизировать взаимодействие между ERP или учётной системой и Диадок. Сложность разработки интеграционного решения в значительной степени зависит от правильного выбора средств разработки интеграционного решения.
Для разработки интеграционного решения для Диадок необходимо понимание следующих вопросов:
- Авторизация в Диадок, применение защищенного транспортного протокола;
- Формирование XML файлов и парсинг в соответствии с XSD схемами электронных документов, служебных сообщений, и сериализация/десериализация их в протобуфер;
- Использование криптопровайдера (CSP) для формирования и проверки электронных подписей документов и служебных сообщений;
- Выполнение регламента как последовательности транзакций документооборота и документооборот разных типов;
- Применение исходящих и входящих сообщений. [16]
III. Исследование и построение задачи
A. Сравнительный анализ API Такском и Диадок
Прежде чем проводить анализ предоставленных средств интеграции, необходимо определить какой API нам необходим для реализации гетерогенного адаптера.
Разработка, исходя из условий поставленной задачи должна проводиться:
- в среде ABAP/4 Development Workbench;
- использовать стандартный пользовательский интерфейс SAP
- использовать стандартные средства интеграции (BADI, интерфейсы и классы, фоновые задания),
поэтому из представленных средств интеграции обоих УЦ, для реализации нам подходят методы Web API, средства которых позволят организовать взаимодействие между приложениями с помощью реализации методов отправки и получения сообщений по протоколу HTTP(HTTPS).
B. Модуль авторизации: сравнительный анализ процесса авторизации
Процесс авторизации в обоих случаях представляет собой вызов определенного метода, который в свою очередь реализует отправку запроса POST с содержимым заголовка и тела HTTP-запроса. В обоих случаях метод, при успехе, возвращает маркер авторизации, который необходимо расшифровать для дальнейшего использования. Подробно сравнение приведено в таблице 1:___________________________
И- УЦ Такском УЦ Диадок
метод CertificateLogin Authenticate
Тип HTTP запроса POST POST
Ресурс запроса https://<server>.taxco m.ru/v<version>/API /CertificateLogin https://diadoc-api.kontur.ru/Auth enticate HTTP/1.1
Заголовок запроса IntegratorI^^^™ фикатор интеграционного решения. Формат этого идентификатора: COMPANY AAAAAAA A-AAAA-AAAA-AAAA-AAAAAAAAAAAA Authorization: DiadocAuth ddauth_api_client_ id=testClient- 8ee1638deae84c86 b8e2069955c2825 a
Тело запроса <Двоичное DER-представление X.509-сертификата пользователя> <Двоичное DER- представление X.509- сертификата пользователя>
Тело ответа <Бинарное представление зашифрованного маркера временного доступа (session token)> <Двоичное DER- представление зашифрованного авторизационного токена>
Вывод: механизм авторизации универсален в обоих случаях и заключается в реализации идентичных по своей структуре методов CertificateLogin и Authenticate с различающимися по содержанию параметрами для формирования заголовка и тела HTTP-запроса POST.
C. Модуль регламентных действий
Модуль должен обеспечивать выполнение отправки и приема сообщений в соответствии с установленными регламентами для различных типов документов. Для выполнения своих функций данный модуль тесно взаимодействует с модулем «работы с КриптоПро» (в контексте формирования и проверки подписи) и с модулем «формирования и обработки контейнера» (в контексте формирования структуры передаваемого сообщения).
18
International Journal of Open Information Technologies ISSN: 2307-8162 vol. 3, no. 3, 2015
Исходя из сравнительного анализа, можно заключить следующее: методы обмена в целом
идентичны. Процесс обмена основывается на выполнении определенного регламента для каждого типа документа.
Различие имеет место быть в названиях методов, именах ресурса в содержимом заголовка запроса, что не влияет структуру методов и может формироваться с помощью переменных. Так же Диадок, при передаче сообщений, использует два различных метода для передачи основного документа и служебных сообщений.
Вывод: механизм обмена сообщениями
универсален в обоих случаях и заключается в реализации идентичных, по своей структуре, методов передачи и приема сообщений с различающимися по содержанию параметрами для формирования заголовка и тела HTTP-запросов.
D. Модуль формирования и обработки контейнера.
Это вспомогательный модуль, предназначен для преобразования передаваемых документов, цифровых подписей и служебных сообщений в структуру обмена, пригодную для правильной обработки на стороне оператора (УЦ) и обратно.
Сравнительный анализ формирования сообщений обмена приведен в таблице 2:
УЦ Т акском УЦ Диадок
Контейнер Т акском Протобуфер Диадок
струк тура ZIP- архив, содержащий документ, ЭЦП, обязательные служебные файлы Документ, преобразованный с использованием механизма Google Protocol Buffers
опис ание Контейнер Т акском Документ, сериализованный в протобуфер определенной структуры (Message, Message Patch)
Структура передаваемых сообщений в процессе обмена, для каждого оператора (УЦ), формируется на основе разных механизмов, а значит процессы преобразования должны быть реализованы по-разному. Это основное, отличие в разрабатываемой реализации гетерогенного адаптера.
E. Модуль работы с КриптоПро
Это также вспомогательный модуль, с помощью которого формируется ЭЦП для отправляемых документов и осуществляется проверка подписей входящих документов и служебных сообщений. Использование модуля является требованием к реализации обоих УЦ. Данный модуль, по условиям поставленной задачи, уже имеет реализацию. Причем вызов методов данного модуля, может осуществляться как на машине клиента, так и на сервере и не зависит от реализации других модулей адаптера, которые осуществляют этот вызов. [17]
F. Схема реализации гетерогенного адаптера
На основании сравнительного анализа API Такском и Диадок можно сформулировать ряд
предпосылок универсальности разрабатываемого адаптера:
- для взаимодействия с пользователем используется стандартный интерфейс;
- основные документы обмена имеют единый тип и структуру, которые определены законодательно и не зависят от оператора (УЦ);
- обмен между системами осуществляется в соответствии с установленными регламентами обмена и не зависит от оператора (УЦ);
- методы модулей авторизации и регламентных действий имеют одинаковую структуру и могут быть реализованы классами, переопределяющими методы одного общего интерфейса;
-реализация модуля работы с КриптоПро также носит универсальный характер в контексте оператора (УЦ). Различия в реализации заключаются:
- в реализации структуры передаваемого сообщения (zip, protobuffers);
- в содержании строки запроса (ресурс);
-в содержании параметров, которые содержат заголовки реализуемых методов.
Таким образом модульная схема разрабатываемого гетерогенного адаптера будет иметь вид (рис. 2):
Гетерогенный
адаптер
Модуль работы с КриптоПро
К сервисам УЦ
4 »
Рис. 2 Гетерогенный адаптер
IV. ОПИСАНИЕ ПРАКТИЧЕСКОЙ ЧАСТИ
A. Используемые инструменты разработки
ABAP/4 (Advanced Business Application Programming, изначально по-немецки Allgemeiner Berichts-Aufbereitungs-Prozessor) — проприетарный внутренний язык программирования высокого уровня немецкой софтверной компании SAP. Наряду с Java является языком создания приложений для SAP NetWeaver Application Server. Язык реализует работу с внутренними структурами данных, интерфейсом пользователя SAP R/3, транзакциями, отчётами, интерфейсами загрузки и выгрузки данных. Используется исключительно для бизнесприложений и промежуточного программного
обеспечения компании SAP. Имеет возможности для объектно-ориентированного программирования. Имеет сборщик мусора. Компилируется в байт-код. Исполняется на виртуальной машине. [18]
КриптоПро CSP. Приложение командной строки», предназначенного для работы с сертификатами с использованием инфраструктуры открытых ключей, шифрова- ния/расшифрования сообщений,
содержащихся в файлах, создания/проверки
электронных под- писей и хеширования сообщений, содержащихся в файле или группе файлов. [17]
19
International Journal of Open Information Technologies ISSN: 2307-8162 vol. 3, no. 3, 2015
Protocol Buffers — язык описания данных, предложенный Google, как альтернатива XML. По замыслу разработчиков сначала должна быть описана структура данных, которая затем компилируется в классы, представляющие эти структуры. Вместе с классами идет код их сериализации в компактный формат представления. В дальнейшем, используя высокоуровневые языки программирования, такие как Java, C++ или Python, осуществляется чтение и запись данных. [19]
B. Описание основных компонентов системы
Для реализации гетерогенного адаптера необходимо создать:
- Интерфейсы
- Классы, реализующие интерфейсы
- Вспомогательные классы
- Функциональные модули
- Преобразования
- Т аблицы и структуры
- Домены
- Элементы
- Фоновые задания
Основным является класс
ZCL_TAXCOM_DIGITAL_INVOICE_IMP - который реализует расширение для BADI:
J_3RF_DIGITAL_INVOICE_BADI. Методы, переопределяемые в этом классе:
SEND - метод отправки сообщения;
RECEIVE - метод получения сообщения;
SIGN - метод подписания и проверки подписи. Методы расширяющие исходный класс:
GET_DOCUMENT_CONTAINER - метод создающий объект контейнер и его заполнение при отправки основного документа;
GET_IZPOL_CONTAINER - метод создающий объект контейнер и его заполнение при отправки служебных сообщений регламента;
GET_SIGNATURE - метод формирования подписи документа;
GET_SIGNER_INFO - метод, получающий данные подписанта;
SAVE_CONTAINER - сохранение контейнера.
Классы ZCL_TAXCOM_EDO_PROVIDER и ZCL_DIADOK_EDO_PROVIDER реализуют интерфейс ZIF_TAXCOM_EDO_PROVIDER и определяют основные методы работы с API оператора (УЦ): SendMessageContainer - метод, реализующий отправку сообщения оператору (УЦ);
GetMessageList - метод, реализующий получения списка сообщений по абоненту;
GetMessage - метод, реализующий получение сообщения из списка
GetMarker - метод, реализующий процесс авторизации на сервисе оператора (УЦ);
Prepare_Interaction - метод, реализующий подготовку данных для процесса обмена.
Классы ZCL_TAXCOM_EDO_FACTORY и ZCL_DIADOK_EDO_FACTORY реализуя общий интерфейс ZIF_EDO_FACTORY, создают объекты классов ZCL_TAXCOM_EDO_PROVIDER и ZCL_DIADOK_EDO_PROVIDER при вызове из методов основного класса
ZCL_TAXCOM_DIGITAL_INVOICE_IMP.
Классы ZCL_TAXCOM_ENCRYPTION_SERVER и ZCL_TAXCOM_ENCRYPTION_LOCAL реализуя
общий интерфейс ZIF_TAXCOM_ENCRYPTION, обеспечивают работу с крипто библиотеками, установленными на сервере и на клиенте соответственно.
Классы ZCL_TAXCOM_UTILITY и
ZCL_DIADOK_UTILITY реализуют методы, обеспечивающие обработку служебных документов.
Класс ZCL_TAXCOM_CONTAINER создает объект -контейнер Такском.
Класс ZCL_DIADOK_PROTO создает сообщение, сериализованное в protocol-buffer.
Взаимодействие между классами осуществляется в процессе работы основных методов класса ZCL_TAXCOM_DIGITAL_INVOICE_IMP.
C. Пользовательская работа с решением
Пользователь выполняет стандартные операции, предусмотренные SAP для работы с электронными счетами фактур. В журнале счетов (транзакция J_3RF_REGINV) после установки модуля гетерогенного адаптера появятся кнопки «Подписать» и «Отправить», которые будут вызывать функциональность взаимодействия с операторами (УЦ).
Так же для массового получения и отправления документов предусмотрена транзакция
ZTAXCOM_IN_OUT.
Для просмотров обработанных контейнеров Т АКСКОМ используется транзакция ZTAXCOM_IN_OUT_MESS Для фонового приема/получения сообщений рекомендуется использовать программу
ZTAXCOM_INCOMING_OUTCOMING и
ZDIADOK_INCOMING_OUTCOMING Количество обрабатываемых за один запуск сообщений и периодичность обработки определяется опытным путем. Ошибки обработки заносятся в журнал приложений -транзакция SLG1 объект RU_XMLINV.
D. Апробация гетерогенного адаптера В рамках проверки соответствия гетеродинного адаптера предъявляемым требованиям со стороны операторов УЦ, был проведен нагрузочный тест обмена сообщениями между интегрируемыми системами. Условия тестирования:
- количество сообщений: 1000
- ограничение по одновременной обработке: 100
- время обработки пакета сообщений: t < 3 мин Результат: время обработки сообщений соответствует граничным условиям, предъявляемым оператором.
V. Заключение
В рамках работы были исследованы схемы взаимодействия учетной системы предприятия со своими контрагентами через операторов ЭДО.
Были исследованы существующие реализации адаптеров к основным операторам ЭДО и проведен подробный анализ используемых при этом предоставляемых API.
На основании сравнительного анализа, была разработана концептуальная схема гетерогенного
20
International Journal of Open Information Technologies ISSN: 2307-8162 vol. 3, no. 3, 2015
адаптера, учитывающая регламенты обмена для различных типов сообщений и основные требования операторов к реализации обмена.
Разработана практическая реализация гетерогенного адаптера к двум операторам (Такском и Диадок) с использованием следующих подходов:
- применены основные принципы ООП;
- использован модульный подход к разработке
программного обеспечения, основанный на
использовании распределённых, слабо связанных
заменяемых компонентов, оснащённых
стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам;
- в реализации преимущественно использованы стандартные BADI, модули обработки SAP, механизм фоновых заданий и пользовательский интерфейс, что положительно отразиться на поддержке приложения.
- реализация отвечает требованиям масштабируемости в контексте расширения функциональности и добавления новых операторов.
- проведена апробация практической реализации с использованием нагрузочных требований оператора Такском.
Таким образом, разработанный гетерогенный адаптер полностью обеспечивает заданную функциональность по обмену ЮЗД между участниками обмена с соблюдением требований законодательства РФ, снижая при этом затраты на разработку и поддержку интеграционных решений, в силу своей универсальности, масштабируемости и применения стандартной функциональности учетной системы SAP.
[9] «Порядок выставления и получения счетов-фактур в электронном виде» приказ Минфина России от 25.04.2011 № 50н.
[10] «Понятия электронной подписи и ее виды» статья на сайте 1с (http://its.1c.ru/db/eldocs#content:4:hdoc)
[11] «Юридическая сила документов подписанных электронной подписью» статья на сайте 1 с (http://its.1c.ru/db/eldocs#content:5:hdoc )
[12] «Инфраструктура открытых ключей» статья на сайте Wikipedia (http://ru.wikipedia.org/wiki/ )
[13] «Информация для разработчиков» API Такском (https ://integration.taxcom.ru/DevHelp/ Start.html)
[14] «Diadoc API» информация для разработчиков (https://diadoc.kontur.ru/sdk/Index1.Html)
[15] «Крипто про CSP: Приложение командной строки для подписи и шифрования файлов» Техническое описание, ЖТЯИ.00050-03 90 07
[16] «ABAP» статья на сайте Wikipedia (https ://ru.wikipedia.org/wiki/)
[17] «Google protocol buffers», описание средств разработки (https://code.google.com/p/protobuf/)
Библиография
[1] Шишкин И.О. Корпоративный документооборот Учебное пособие - СПб.: Изд-во СПбГУЭФ,2008
[2] «Система автоматизации документооборота» статья
на сайте Wikipedia (https://ru.wikipedia.org/wiki/)
[3] «Правовые основы обмена электронными
документами» статья на сайте 1 с
(http://its. 1c.ru/db/eldocs#content:3:1)
[4] «Об электронной подписи» Федеральный закон № 1-ФЗ от 06.04.2011 № 63-ФЗ
[5] «Порядок представления по требованию налогового органа документов в электронном виде», ФНС России приказ от 17.02.2011 № ММВ-7-2/168
[6] «Форматы первичных документов - ТОРГ-12 и акта
приемки-сдачи работ (услуг)», ФНС
России приказ от 21.03.2012 № ММВ-7-6/172
[7] «Электронные форматы счета-фактуры, журнала полученных и выставленных счетов-фактур и книг продаж и покупок», приказ ФНС России от 05.03.2012 № ММВ-7-6/138
[8] «Форматы представления документов,
используемых при обмене счетами-фактурами в электронном виде по телекоммуникационным каналам связи» приказ ФНС России от 30.01.2012 № ММВ-7-6/36
21
International Journal of Open Information Technologies ISSN: 2307-8162 vol. 3, no. 3, 2015
Organization of the intercorporate electronic data interchange (EDI) in ERP systems.
Leonidov V.N.
Abstract - in this article describes the subject area, which is a system of analyzing processes of the enterprise and its counterparties, which are exchanged, between the legal documents of standard formats according to the approved regulations by the operators of electronic document management (EDM), an analysis of the possible schemes for such interaction and their existing implementations. Based on the analysis suggested a conceptual diagram of a heterogeneous adapter and its practical implementation for the system SAP ERP, which satisfies the requirements on the part of operators of EDM, and by the accounting system.
Keywords - adapter, EDO, web service
22
