EDI как базовая система для электронного обмена данными и интеграций с партнёрами

Заказчики разработки часто думают, что EDI — это современный и универсальный для любой компании стандарт обмена данными и интеграций с любыми контрагентами. Так ли это? Давайте разберёмся, что же такое EDI и почему эта технология так популярна уже более 40 лет.

1. Что такое EDI. История возникновения и развития. Стандарты

EDI (сокр. от англ. electronic data interchange, рус. «электронный обмен данными») — технология автоматизированного обмена данными, включающая передачу, поток сообщений, формат документа и программное обеспечение, используемое для интерпретации документов.

EDI возник в 1970–1980-х и популярен до сих пор. Как и многие другие ранние информационные технологии, EDI-обмен придуман военными и изначально использовался в логистике.

В конце 1940-х воздушное сообщение в Европе сопровождалось передачей больших объёмов информации о грузах, при этом процесс обмена данными был неудобным, остро требовалась разработка новых концепций и методов обмена. Одной из первых интегрированных систем, использующих EDI, была схема лондонского аэропорта Cargo EDP Scheme (LACES) в аэропорту Хитроу (Лондон, Великобритания) в 1971 году. Внедрение метода прямого ввода данных трейдером (DTI) позволило экспедиторам вносить информацию непосредственно в систему таможенного оформления. После этого процесс оформления стал быстрее и легче.

Рост морских перевозок и проблемы на таможне, схожие с теми, что возникали в аэропорту Хитроу, привели к внедрению систем DTI в некоторых портах и группах портов в 1980-х.

Электронная передача данных между компаниями, а также между бизнесом и государством в едином, общем для всех формате привлекала всё больше внимания, и в 1987 году был утверждён стандарт UN/EDIFACT (стандарт Организации Объединённых Наций для электронного обмена данными в управлении, торговле и на транспорте). ООН взяла на себя эту ответственную миссию и до сих пор выпускает обновлённые справочники каждые полгода, инвестируя в эту работу немалые средства. Справочники содержат стандартные сообщения для разных отраслей, сейчас это более двухсот сообщений.

В разработке справочника принимает участие и Технический комитет по стандартизации № 154 Международной организации по стандартизации (ISO, сокр. от англ. International Organization for Standardization).

Использование единых стандартов EDI удобно бизнесу и выгодно контролирующим органам: таможенной, налоговой службе и т. д. Это делает обмен сообщениями прозрачным и легко управляемым. ООН даже рекомендует использовать стандарт UN/EDIFACT при обмене сообщениями в государственных органах и между правительствами стран.

Итак, для интеграций с иностранными партнёрами может использоваться стандарт UN/EDIFACT, а для обмена данными с компаниями внутри России распространены его подмножества, например SWIFT — в банковской сфере, EANCOM — в торговле. Также есть ряд других подмножеств для разных отраслей.

В российской интернет-торговле распространён формат CommerceML в виде XML от «1С», а также YML (сокр. от англ. Yandex Market Language) в виде XML. Но если вам нужна интеграция с глобальными корпорациями, этот стандарт не будет им знаком.

В Северной Америке распространён стандарт Американского национального института стандартов (ANSI, сокр. от англ. American National Standards Institute) — ASC X12 (также известен как X12).

GS1 EDI устанавливает стандарты в глобальных поставках. TRADACOMS — стандарт, распространённый в ретейле Великобритании. ODETTE, VDA используются в автомобильной промышленности, HL7 — в здравоохранении.

Как видите, под EDI нельзя понимать какой-то единственный универсальный стандарт — это множество стандартов для разных регионов и отраслей.

2. Особенности EDI-обмена

Понятие EDI часто путают с понятием обмена юридически значимыми документами. На российском рынке B2B-систем электронного документооборота можно выделить следующие направления:

• EDI как технология для интеграций с информационными системами партнёров;
  

• электронный документооборот (сокр. ЭДО) как средство обмена юридически значимыми документами между контрагентами;
  

• электронная отчётность в налоговую, таможенную службы и другие государственные контролирующие органы.
  

EDI или обмен юридически значимыми документами?

Заказчику разработки необходимо определиться: нужен ли ему именно обмен юридически значимыми документами, отчётность или всё же интеграция ИС? Это разные вещи.

Естественно, что у бизнеса есть много юридически значимых документов, которыми нужно обмениваться с покупателями, поставщиками и налоговой (как минимум). Особенность EDI в России — в многообразии форм: на рынке есть несколько систем электронной отчётности («СКБ Контур», СБИС); формат УПД (сокр. от «универсальный передаточный документ») носит рекомендательный характер; есть несколько операторов ЕЦП (сокр. от «единая цифровая подпись») и т. д.

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

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

Каким компаниям подходит EDI

Подобные стандарты не нужны мелким организациями. Хотя в мировых масштабах и какой-нибудь топ-1 — это не очень крупная организация, которая вполне может разрабатывать свои внутренние стандарты и использовать вместо EDI более современную технологию передачи данных, например API.

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

• либо брать существующие стандарты (UN/EDIFACT и его подмножества);

• либо разрабатывать собственные EDI-стандарты, которые будут поддерживать контрагенты.
  

Простая XML-схема не подойдёт.

Разработка собственных EDI-стандартов потребует большого количества усилий аналитиков (а если мы говорим о межгосударственном взаимодействии, то и политиков) с обеих сторон. А вот усилия, потраченные на техническую реализацию, в сравнении с согласованиями будут незначительными.

3. Мнение эксперта: как заказчик EDI-интеграции оценивает эту технологию

Чтобы узнать мнение крупного бизнеса об EDI, мы взяли интервью у представителя международной логистической компании FM Logistic. Итак, наш собеседник — Jonathan Woloszczyk, Head of IS Build & Deploy, наш давний заказчик и партнёр.

— В нашей совместной работе мы использовали API для интеграции со службами доставки, а в качестве средства интеграции с WMS — EDI. Также мы знаем, что у FM Logistic есть EDI-обмен с некоторыми партнёрами. Как вы считаете, почему EDI до сих пор интересен транспортно-логистическому бизнесу и его контрагентам? В чём его плюсы?

— Так сложилось исторически. Во-первых, все основные логистические системы и WMS были созданы 20–30 лет назад, когда существовал только EDI. Сейчас эти WMS не просто древние, а мегадревние, и сделать для них API часто бывает невозможно.

Во-вторых, в логистике до сих пор есть очень высокий уровень доверия к обмену файлами по EDI. Логисты — прагматичные люди, им привычнее представлять файл как физический объект, артефакт. С EDI логист может сказать «я выслал тебе файл» и «я получил твой файл». Ответственность прозрачна: каждый участник обмена всегда может доказать, что, когда и кому он отправил.

API и транзакционный обмен гораздо сложнее для понимания. Сложно концептуализировать формат передачи данных через API и доверять ему. Думаю, это главная причина, по которой EDI-обмен так популярен. Но во многих логистических компаниях уже есть подвижки: приходит молодое поколение с другими взглядами на EDI и API.

В-третьих, написать скрипт и подключить его к API гораздо сложнее, чем использовать EDI. У большинства IT-решений есть стандартная EDI-спецификация на входе или на выходе, и это достаточно легко использовать: когда ты хочешь подключить одну систему ERP-клиента к WMS или другой ИС, тебе достаточно сделать mapping — не нужно писать скрипты, методы, подключать их к API и т. д.

— Теперь давайте рассмотрим пример с «Ашаном». У них есть EDI Orders, и у вашей WMS есть Orders. Вы интегрировались через EDI? Как вы получаете данные по заказам от «Ашана»?

— Когда мы только начинали работать, интегрировались через EDI. Интеграция занимала 2–4 рабочих дня на каждый поток — это быстро.

— У вас одинаковые поля в Orders?

— Нет, не только поля, но и вся структура может быть совершенно разной, и сам объект, который называется Orders у них, может отличаться от объекта, который называется Orders у нас. Приходится анализировать спецификации и переформатировать их Orders, чтобы они совпадали с нашими. Хорошо, что провести такой анализ может даже человек, далёкий от программирования, — не технарь, а любой аналитик, которому нужно лишь составить список в Excel и показать, какие поля должны быть уравнены. Потом это реализует другой человек — разработчик. С API всё несколько сложнее — нужно хотя бы базовое понимание, что такое метод, и как приложение может реагировать на его вызов.

— Если говорить укрупнённо, вы могли бы просто выставлять интерфейс EDI своим e-Commerce-партнёрам и таким образом с ними интегрироваться. Почему же вы выбрали для этого API?

— E-Commerce-рынок достаточно молодой, и наша компания тоже молодая и современная. 50 % наших клиентов имеют свой сайт, который не общается по EDI, но через который они получают заказы и отправляют их нам как логистам. Остальные 50 % клиентов до сих пор обмениваются XML-файлами через EDI. Это не UN/EDIFACT, ANSI X12 или что-то подобное, но тем не менее это тоже EDI. Они отправляют тебе файлы, ты преобразовываешь их и интегрируешь.

E-Commerce очень транзакционна, и каждый день через нас проходит много мелких заказов, часто — штучных. Обмен данными быстрый и интенсивный, документов много. Тогда как в B2B-логистическом бизнесе мы имеем дело с крупными партиями товаров, и все данные за день можно отразить в одном документе.

Большой плюс API в том, что после каждой отправки данных ты получаешь ответ — «OK» или «не OK». В случае с EDI ты не получаешь обратной связи: просто отправляешь файл и ждёшь, не зная, что произошло с ним дальше. EDI какое-то время назад пытался поставить внутри файлов флаги, нужен ли отправителю ответ, но сделать это не удалось. До сих пор EDI не подтверждает факт правильной интеграции, и хотя есть обходные способы это получить, но они очень редко внедряются. Даже если клиенту пришёл файл, он может «застрять» в бизнес-процессе сразу после получения.

EDI придумали ещё в 1970-х, чтобы уйти от бумажного документооборота: раньше партнёры обменивались реальными документами с напечатанными в них заказами, а теперь в той же парадигме стали обмениваться файлами. API работает по другому принципу: мы отправляем запрос и получаем данные. HTTP-методы: GET, HEAD, POST, PUT, DELETE и т. д. — они тоже двусторонние, т. е. я могу отправить партнёру данные, чтобы он что-то в них поменял, и получу ответ, что изменения внесены. Либо я могу отправить запрос, нацеленный на то, что мне ответят справочником. Я обращаюсь к методу, который возвращает мне часть каталога и отображает его в UI и в мобильном приложении.

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

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

Сразу переходить с бумаги на API — слишком радикальная смена концепции. «Нет, API не имеет отношения к тому, чем я занимаюсь. Лучше я возьму свою бумагу и отправлю её в виде файла через EDI».

Решиться заменить бумагу на файл, в котором содержатся такие же данные, как в бумаге, очень легко. Это выглядит почти одинаково. А API? «Нет, я не разберусь в этой вашей технологии, „заверните" мне EDI, так проще».

— Почему разработчики WMS не хотят внедрять API в саму систему, ведь для них важна скорость обмена данными и, например, ERP (в частности, SAP) уже довольно активно движутся в сторону API?

— На самом деле WMS уже тоже смотрят в сторону API, но им очень сложно делать конкретные шаги, потому что все популярные WMS связаны с EDI большим количеством алгоритмов. Чтобы прикрутить API к WMS, требуется огромная работа по концептуализации и перемоделированию объектов, функций и т. д. На данный момент на рынке очень мало WMS, которые могут управляться по API, а у тех, что есть, очень ограниченный каталог действий. И в основном они просто транслируют единый API, т. е. когда ты делаешь запрос, они прогоняют его через скрипт импорта EDI и отдают ответ и результат в синхронном виде. Но создавать для них новый метод, который будет напрямую влиять на базы данных или обмениваться данными в ядро, — нереально трудоёмкая работа.

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

Выводы

Основная задача, которая стоит перед EDI в современном мире, — заменить бумажный документооборот электронным и автоматизировать обмен данными. И EDI успешно справляется с этим.

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

Банковская ИС, получив этот WSDL, не сможет автоматически понять, какой конкретно службе нужно отправлять уведомление. Банку и налоговой нужно заранее договориться, как будут называться службы. И это не может произойти автоматически, без согласования.

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

Обо всех обязательных элементах нужно договариваться, обсуждать их, и только после этого разработчики смогут начать пилить свои WSDL, XSD и т. п. На выяснение всех разногласий и создание единых требований обычно уходит немало времени и денег. А в каком синтаксисе решение будет реализовано: EDI, JSON, XML или каком-то другом — вопрос второстепенный.

Ценность EDI как раз в том, что контрагенты (и бизнес, и государство) могут договориться один раз о том, что сообщения должны быть составлены определённым образом, в них должны передаваться определённые данные, чтобы в будущем формировать, корректно передавать и получать такие данные автоматически, без участия человека.