Подпишитесь на нашу рассылку!
Будьте в курсе новостей мира разработки и менеджмента, узнайте первыми о наших новых кейсах, событиях и личном опыте!

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

06/05/2020
Устаревшая технология или надёжное решение?
Заказчики разработки часто думают, что 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, наш давний заказчик и партнёр.
WMS (сокр. от англ. warehouse management system) — система управления складом.
— В нашей совместной работе мы использовали 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 как раз в том, что контрагенты (и бизнес, и государство) могут договориться один раз о том, что сообщения должны быть составлены определённым образом, в них должны передаваться определённые данные, чтобы в будущем формировать, корректно передавать и получать такие данные автоматически, без участия человека.

Поделиться
Хотите больше полезных материалов?
Подпишитесь на нашу новостную рассылку!

Новости мира разработки и дизайна, переводы статей, наши новые кейсы. Пишем просто о сложном, без рекламы и спама.
Остались вопросы?
Вы можете обсудить любые вопросы по своему IT-проекту с нашим экспертом.
Error get alias
Получить консультацию
Читайте также

Нравится статья?
Укажите свою почту, и мы будем присылать вам еженедельный анонс
новых статей.