EDI - Электронный Обмен Данными. Электронный документооборот для ритейла Курс стандарты и технологии edi

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

Электронный Обмен Данными представляет собой определенный набор стандартов для выполнения торговых операций и обмена деловыми документами. При помощи технологии EDI указанные документы переводятся на понятный всем стандартный деловой язык и пересылаются партнерам по безопасным коммуникационным каналам.

Переход торговых организаций на электронный обмен данными при взаимодействии со своими контрагентами по поставке товара и его реализации имеет ряд неоспоримых преимуществ.

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

Как работает EDI?

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

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

Система извлекает и автоматически пересылает их от одного контрагента к другому. При этом информация принимает стандартную форму с сохранением всего содержимого.

Выгоды от внедрения системы EDI:

  • Конфиденциальность информации – реализуется путем использования безопасных каналов передачи данных;
  • Достоверность - исключена возможность внесения изменений в документ без ведома получателя;
  • Гарантия доставки , осуществляется благодаря системе автоматического оповещения о доставке документа;
  • Оперативность – обработка и передача документа в течение 15 секунд;
  • Точность – встроенные интеллектуальные механизмы системы обеспечивают обработку содержания передаваемых документов, и при совершении ошибки в заполнении формы она мгновенно об этом сообщает;
  • Экономичность – внедрение EDI позволяет минимизировать временные и материальные затраты, связанные с составлением и отправкой документов;
  • ИТ-совместимость – EDI легко интегрируется с любой ERP-системой, установленной в компании, что избавляет клиента от двойного ввода данных.

Реализация EDI на практике

  • Разработка систем связи
  • EDI стандарт (Electronic Data Interchange) - часть старых, устоявшихся систем. Но мы постоянно видим, как EDI представляют, как современный стандарт. Так ли это? Надо ли нам рассматривать EDI в качестве базовой технологии для новых проектов?
    Давайте посмотрим на EDI с технической точки зрения, отбросив все остальное.

    Формат данных в EDI

    EDI использует delimited text формат . Он хорошо работает для плоских структур данных, таких как таблицы. Он не так хорош для представления иерархических структур данных. Вложенные объекты лучше сериализуются с помощью tagged форматов, таких, как XML и JSON.
    Очень странно, но так и не был создан язык описания (document definition) для EDI. Прошло столько лет с момента появления EDI и столько усилий было затрачено на него, но язык описания так и не создан. Язык описания позволяет автоматизировать обработку данных, а именно их генерацию, верификацию, преобразование, сериализацию, десериализацию. Для сравнения, для верификации XML данных мы берем схему данных (XML Schema, xsd) и парсер автоматически проверяет данные на соответствие этой схеме.
    Можно обойтись и без схемы, но тогда желательна разметка документа. XML и JSON документы могут быть десериализованны и без схемы, потому что сами данные содержат тэги (имена) элементов данных. EDI имеет тэги только для сегментов и не имеет тэгов для элементов. Элементы определяются позицией внутри сегмента. Универсальный EDI парсер сможет разобрать документ только на примитивные коллекции, потому что документ не содержит ни имен, ни типов для элементов данных.

    Давайте обратимся к деталям.

    EDI стандарт состоит из двух основных частей:

    • Envelope (пакетный?) формат (смесь стандартов сообщений (messaging))
    • Спецификации (форматы) документов (смесь индустриальных (domain) стандартов)

    Пакетный формат

    EDI определяет пакеты для наборов документов, групп документов и самих документов/транзакций (Interchange , Group and Transaction /Document) . Пакеты ограничиваются соответственно ISA/IEA, GS/GE, ST/SE парами сегментов.
    Замечание: Для иллюстрации я использую EDI X12 вариант стандарта, распространенный в Северной Америке. Другой вариант стандарта, EDIFACT, распространен в Европе и принципиально не отличается от X12.
    Здесь представлен пример самых первых сегментов всех трех пакетов: ISA, GS и ST. Пример взят отсюда :
    ISA*00* *00* *ZZ*RECEIVERID *12*SENDERID *100325*1113*U*00403*000011436*0*T*>~
    GS*FA*RECEIVERID*SENDERID*20100325*1113*24712*X*004030~
    ST*997*1136~

    Что мы видим в первом сегменте?
    Последние три символа сегмента ISA - это разделительные символы : "*>~": ‘~’ - символ разделения сегментов; ‘*’ - символ разделения элементов внутри сегмента; ‘>’ - символ разделения подэлементов внутри элемента. Изменяя эти символы мы по сути изменяем форматы пакетов и документов. В XML и JSON разделительные символы прописаны в стандарте, их нельзя изменить. Изменяемые разделительные символы - это рудименты эпохи, когда Unicode еще не был создан. Но даже в те времена делать разделительные символы изменяемыми было не очень хорошей идеей. Разделительные символы - очень важные символы. Если мы можем использовать любые символы в качестве разделителей, это не только именяет логику разбора пакетов на составляющие части, это сильно усложняет логику разбора текста внутри самих элементов.
    Еще в ISA сегменте мы видим элементы, определяющие форматы времени и дат . Они помогают нам использовать настраиваемые форматы дат и времён внутри документов. Это имело смысл в семидесятых годах, когда нам надо было сохранить несколько байт при кодировке дат и времён. Нужны ли эти элементы теперь, после того как мы побороли проблему «2000-ного года», после того как были созданы специализированные и очень подробные стандарты представления времени ?
    Мы видим в ISA сегменте элементы, определяющие отправителя и адресата . По сути это - адресная (routing ) информация. То есть стандарт упаковки объединен со стандартом адресации. Используя EDI, мы должны задавать отправителя и адресата внутри наших данных. В сегменте ISA есть еще и авторизационные элементы . Вся идея размещения этой авторизационной информации внутри самих сообщений когда-то была довольно прогрессивная, но сейчас она выглядит по меньшей мере наивной, а то и опасной. Сейчас мы понимаем, что авторизационная информация - много-много сложнее чем пара значений. То же самое можно сказать и про адресную информацию. EDI стандарт подталкивает нас к использованию этих элементов.
    Еще мы видим элемент запроса подтверждения (acknowledgement request ). То есть создатель документа задает стратегию использования подтверждений прямо в документе. Хорошая ли это идея? Мы можем использовать документы в разных сценариях. В некоторых из них подтверждения используются на уровне приложений, в других для повышения надежности используются другие протоколы. Политика надежности определяется не внутри самих данных, потому что надежность - это довольно сложная тема в передаче данных, определяемая многими участниками коммуникации.
    Еще внутри сегментов пакетов мы видим контрольные номера (Control Numbers ). Они нужны в сценариях, когда мы получаем набор документов, но часть набора потеряна или искажена по пути, и мы пытаемся восстановить как можно больше данных. Этот сценарий давно уже не используется, так как подобная проблема надежности как правило решается на нижних уровнях коммуникационных протоколов. Мы не встраиваем надежность коммуникаций на уровень приложений, так ведь?
    Другой элемент ISA сегмента, это EDI версия (Standard Identifier ). Это похоже на поддержку версионности, знакомую нам по сериализационным стандартам.
    В сегменте GS находится элемент, определяющий тип документа (Type of Document ). К примеру, это заказ или накладная. Ничего очень плохого в этом нет, хотя задавать тип документа проще внутри самого документа.

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

    EDI - это стандарт формата данных или протокол?
    EDI пытается быть протоколом, именно поэтому мы видим эти элементы адресации, авторизации и запроса подтверждения. Я не знаю, как эту информацию можно сопоставить с OSI protocol layer model.
    Но все же большая часть EDI стандарта посвящена форматам данных.
    Форматы документов
    Внутри пакетов мы видим сами документы. Но мы не найдем стандарта для универсального, обобщенного документа. Стандарт определяет многочисленные форматы для всевозможных типов документов: для заказов, для накладных, для описей вложения… вы найдете небольшую часть из громадного списка стандартизованных документов.
    EDI следует известному мифу: «Где-то там есть идеальный формат, который описывает все на свете сценарии. Мы обязательно найдем этот формат. Нам нужно просто добавлять новые сценарии и подстраивать старые.»
    Как результат EDI стандартные документы (спецификации) чрезмерно сложные.
    Возьмем один пример: Нам нужна накладная для небольшого местного книжного магазина. Мы нашли подходящую стандартную спецификацию, EDI 850, заказ на покупку (Purchase Order). На первый взгляд он выглядит чересчур детальным. Мы не будем покупать продукты питания, уголь, зерно, жидкие продукты, опасные продукты, медицинские препараты. Нам не нужны международные адреса. Мы не будем использовать службы срочной доставки. EDI спецификация описывает все эти возможные варианты, но в ней слишком много полей, которые мы никогда не будем использовать. Она чересчур сложна для нашего простого документа.
    Существует много индустриальных (domain) стандартов, которые используются как своеобразные хранилища знаний. Но эти стандарты не используются как стандарты передачи данных. (Посмотрите , описывающую проблему индустриальных стандартов.)
    Циклы (Loops) внутри документов
    Структура индивидуальных документов довольно проста. Документы составлены из серии сегментов, внутри которых находятся данные документов.
    Но оказывается, что сегменты могут объединяться в группы или в повторяющиеся группы, так называемые циклы (loops ). Пикантность в том, что эти циклы абсолютно никак не выделены в документе. О наличии цикла мы можем прочитать в спецификации данного конкретного документа. Сегменты одинакового типа (с одинаковыми тэгами) могут располагаться как независимо, так и внутри циклов. Создать парсер, распознающий циклы (которые, повторяю, никак не отмечаются в документе), это довольно нетривиальная задача.
    В XML и JSON такой проблемы не стоит, иерархические объекты или коллекции объектов любого уровня вложенности очень просто задаются с помощью открывающих и закрывающих тэгов, именованных или неименованных.
    EDI попытался усидеть на двух стульях. С одной стороны, его документный формат похож на формат csv и удобен для представления табличных данных. С другой стороны, он пытался описывать иерархические объекты, и попытка эта окончилась очень неубедительно. Конечно, мы понимаем это сейчас, когда имеем перед глазами JSON. Но давайте вспомним, что EDI был сделан не для передачи табличных данных, а именно для передачи документов, структура которых именно иерархическая.

    Нетехнический взгляд на EDI

    Для полной картины я все же перечислю некоторые из нетехнических особенностей EDI:
    • EDI стандарт не бесплатный . Это выглядит довольно странно по сравнению с другими стандартами.
    • Спецификации EDI стандарта чрезмерно детальны . EDI спецификации настолько сложны, что компании должны нанимать специалистов, знакомых с конкретной спецификацией. Эти специалисты общаются с помощью специальных EDI терминов, это почти EDI язык, который никак не связан с бизнесом. Посмотрите на EDI соглашения (agreements) между компаниями. Эти соглашения полны специфических требований, определяемый EDI стандартом, но далекими от требований бизнеса.
    • EDI стандарт не стабилен . Специальный комитет выпускает модификации EDI стандарта каждые полгода. Каждая из этих версий привносит новые уточнения. Развитие стандарта не следует запросам пользователей, скорее оно просто следует календарному плану. Предположительно это происходит не из-за очень высоких требований к стандарту, а потому что комитету нужно показать результаты своей работы.
    • EDI был создан, чтобы экономить биты и делать документы как можно более компактными. Это требование до сих пор существует, но оно вряд ли используется для передачи документов. Каждый ребенок сейчас владеет телефоном, который перекачивает гигабайты видео. На дворе уже не эпоха мэйнфреймов и телетайпов. И довольно странно читать отчеты, которые совершенно серьезно обсуждают экономию ресурсов из-за перехода с бумажного документооборота на использование EDI.
    • Для экономии памяти EDI использует коды для представления данных где только возможно. В результате документы выглядят зашифрованными, что создает дополнительную проблему обмена кодовыми таблицами.
    • EDI стандарт был создан для передачи наборов (batches) документов из-за того, что коммуникации и компьютеры стоили дорого и работали медленно. С тех пор многое изменилось, коммуникации и компьютеры стали быстрыми и дешевыми. Данные сейчас передаются маленькими сообщениями или потоками, и эти маленькие сообщения являются основой распределенных систем. Наборы документов еще используются, но не из-за медленного оборудования, а потому что это требуют бизнес-процессы.
    • Не существует стандарта на язык описания EDI . Это означает, что мы не можем создать универсальный парсер для обработки EDI документов. Парсеры должны содержать описания тысяч существующих EDI спецификаций с огромным количеством деталей. (К примеру, Microsoft предоставляет около 7 тысяч XML схем для EDI документов как часть BizTalk Server.) Имеющиеся EDI парсеры стоят дорого. Для работы с EDI документами нам скорее всего придется преобразовать EDI документы в формат XML и использовать XML Schema вместе с XML парсером для обработки EDI документов: для проверки, преобразования, сериализации, десериализации, создания. Что и делается в BizTalk Server.
    • Из-за отсутствия стандартного языка описания EDI документы описываются с помощью… многостраничных инструкций. Разработчики EDI парсеров трактуют эти инструкции по-разному, и из-за этого различные EDI парсеры несовместимы .
    • EDI стандарт создавался во времена, когда разработка программ, протоколов и форматов данных была чрезвычайно дорога и длилась очень долго. Создание стандарта для универсального формата документов было оправдано. Сейчас форматы данных генерируются на лету и наши программы как правило не используют каких-то универсальных стандартов, а создают разные форматы под конкретные случаи. EDI спецификации включают максимально возможное количество деталей , чтобы удовлетворить всех пользователей. Современные программы включают в спецификации передаваемых данных только те данные, которые необходимы. Количество элементов в EDI спецификации, ненужных в вашем конкретном случае всегда будет очень большим.
    • EDI смешивает два типа стандартов: стандарты для коммуникаций и стандарты для форматирования бизнес данных. Современные тенденции прямо противоположны: стандарты должны быть независимы друг от друга (ортогональны), что позволяет смешивать их в любых сочетаниях.

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

    Что такое EDI?
    Под аббревиатурой EDI понимают Electronic Data Interchange или Электронный Обмен Данными. Проще говоря, EDI– это отправка и получение информации с использованием компьютерных технологий.

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

    Любые стандартные деловые документы, которыми, к примеру, одна FMCG компания обменивается с другой (такие как заказ на поставку, счёт-фактура, план отгрузок, запрос о наличии товара) могут быть переданы при помощи EDI, если обе стороны провели необходимую для этого подготовку.

    Стандарт EDI разработан в Американском национальном институте стандартов (ANSI). Наряду с EDI существуют и другие стандарты для электронного обмена данными. Например, EDIFACT широко используется в Европе и в автомобильной промышленности. HIPPA (закон об учете и безопасности медицинского страхования) разработан специально для соответствия деятельности учреждений здравоохранения законодательству. Траснслятор EDI, который Вы выбираете, должен поддерживать все стандарты.

    - Почему EDI?
    EDI значительно отличается от обычной электронной почты, при использовании которой информация передается в неструктурированном формате. В чем разница? К примеру, вам нужно доставить заказ на поставку в виде электронного письма, вы, вероятно, сначала напечатаете документ, а затем, внесете информацию в другую программу (бухгалтерского учёта или управления складским хозяйством). EDI же имеет структурированный формат. Использование EDI для обмена электронными документами гарантирует его понимание всеми участниками этого процесса.

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

    - В чём заключаются преимущества EDI?

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

    - Как работает EDI?
    Предположим, закупщик посылает поставщику заказ

    • Скорее всего, информация о заказе находится в компьютерном приложении (например, программном пакете бухучёта) в персональном компьютере закупщика. Пока возможен импорт и экспорт файлов из приложения, необходимая информация может быть извлечена, и преобразована в файл для программы перевода EDI
    • Транслятор EDI проводит согласование и проверяет, чтобы преобразованный файл удовлетворял стандартам EDI и руководству торговых партнёров по внедрению систем. После этого он переводит сообщение уже в формат EDI.
    • Устанавливается коммуникационное соединение для передачи EDI - заказа на поставку. Программное обеспечение EDI контролирует коммуникационное программное обеспечение.
    • Файл отправляется либо в почтовый ящик, либо на сайт FTP, либо напрямую получателю AS2 по протоколу HTTP
    • Компьютерная программа, которая получает EDI-заказ на поставку, форматирует поступающую информацию и готовит её к переводу в файлы существующего приложения. Например, заказ на поставку, полученный через EDI, может быть переведён и загружен в модуль регистрации заказа.

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

    - Какую систему передачи данных выбрать?
    Один из важнейших аспектов EDI – выбор пути, которым информация будет передана из одного места в другое, напрямую или через VAN. В большинстве случаев способ определяют сами торговые партнёры.

    VAN (Value Added Network) – Сеть с дополнительными услугами
    Его часто называют «электронный почтовый сервис». VAN – третий участник процесса. Посредник, который передаёт и хранит информацию в электронном почтовом ящике, пока она не будет получена одной из сторон. Поскольку EDI-сообщение содержит адрес, VAN направляет сообщение в ящик получателя. До последнего времени, этот способ передачи информации считался самым безопасным.

    Прямое соединение
    В отличие от VAN, прямое соединение позволяет Вам передавать данные получающей стороне напрямую. Виды прямых соединений включают VPN (Virtual Private Network – Вирутальную Частную Сеть), FTP (File Transfer Protocol – протокол обмена файлами), и EDIINT (EDI over the Internet – Электронный обмен данными через интернет). Обычно EDIINT осуществляется при участии программного обеспечения AS2, которое шифрует данные, прежде чем переслать их через интернет.

    - Интернет EDI или VAN EDI?
    Раньше VANы играли роль электронных почтовых служб для поставщиков и закупщиков, которым нужно было обмениваться данными. К примеру, компания А могла отправить электронную закупочную заявку в VAN и компания В могла зайти в VAN, чтобы эту заявку получить. Если компания В заявляла, что заявку не получила, VAN служил промежуточным звеном и подтверждал наличие или отсутствие заявки на месте. Это и были «дополнительные услуги», которые предоставляла эта сеть.

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

    С появлением лучшего и более приемлемого решения – обмена данными через интернет, компании – большие и маленькие – получили возможность общаться со своими торговыми партнёрами электронным способом. А бывшие службы VAN, такие как оповещения о местонахождении сообщений, теперь встроены в программные продукты.

    - Как работает Интернет EDI?
    Интернет EDI (EDI INT) состоит из двух утверждённых стандартов для безопасной передачи данных через интернет. Стандарты Интернет EDI – это AS1 и AS2.

    Стандарт AS1 позволяет надёжно передавать документы электронного обмена по интернету через протокол SMTP (e-mail).

    Стандарт AS2 служит для безопасной передачи EDI и XML документов по интернету через HTTP (проще говоря, это отправка документа напрямую через интернет, а не, скажем, через электронную почту)

    Первичные принципы, которые стоят за стандартами AS1 и AS2 – безопасность и безопасная передача данных через интернет. Четыре основы это:

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

    Аутентификация – удостоверение подлинности происходит через проверку электронной подписи отправителя

    Достоверность сообщения – достигается через использование MDN (оповещений о местонахождении сообщений) для контрольных сумм и полностью исключает возможность изменения документа без ведома получателя

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

    - Преимущества Интернет EDI
    Интернет EDI позволяет тысячам компаний во всём мире общаться и осуществлять безопасные бизнес-транзакции. Свободная передача информации через интернет позволяет организациям вести дела намного быстрее, чем при работе с бумагами. С появлением стандарта AS1, данные оперативно передаются через e-mail. Стандарт AS2 предоставляет возможность фактически непрерывной передачи данных, т.к. используются прямые HTTP передачи.

    Ниже резюме плюсов Интернет EDI:

    • Высокая скорость передачи информации
    • Сокращение расходов и трудозатрат/сокращение возможных ошибок
    • Данные вводятся лишь один раз
    • Экономия времени и ненужность бумажной работы
    • Стопроцентная безопасность электронной передачи данных
    • Никаких коммуникационных затрат

    - Что требуется для начала?
    Вот на что стоит обратить внимание, выбирая программу-решение для обмена различными бизнес-документами с деловыми партнёрами:

    • Низкая совокупная стоимость владения: есть ли у решения интегрированная база данных или же оно требует дополнительных затрат на программные продукты или разработки, такие как SQL-сервер или Oracle?
    • Гибкая связь : поддерживает ли решение все типы данных (EDI, XML, ebXML, TXT, GISB EDM, HL7 и т.д.) и виды их передачи (HTTP, FTP, E-mail, SMTP и т.п.)?
    • Безопасность соединения: Безопасно ли данное решение для передачи бизнес-данных при помощи стандартов AS1, AS2, безопасные ли HTTP/FTP протоколы, цифровые сертификаты, встроенное отслеживание данных и их хранение, отчёты
      - Предполагает ли данное решение безопасность и невозможность отрицания получения сообщения через использование электронной сертификации?
      - Использует ли данное решение SSL для безопасности?
    • Простота установки и настройки: автоматическая ли у данного решения программа установки (автоматическая установка всех необходимых компонентов и автоматическое создание директорий для входящих и исходящих документов)? Включает ли решение использование лёгкой в работе справки для пользователя, которая пошагово помогает, например, добавить торгового партнёра или настроить AS1/AS2?
    • Функциональная совместимость: поддерживает ли данное решение такие стандарты как AS1, AS2, FTP и т.п., позволяя Вам с лёгкостью связываться с множеством торговых партнёров и быстро понизить VAN-затраты?

    - Снова AS1/AS2
    AS1 и AS2 – отраслевые стандарты для обмена данными через интернет. Когда Вы выбирает решение, сертифицированное AS1 и AS2, то получаете возможность обмена данными через интернет со всеми своими торговыми партнёрами, которые используют такое же решение.

    Такие стандарты как AS1 и AS2 упрощают процесс связи, уменьшая число вовлечённых технологий, которые требуют поддержки и обслуживания. Если бы каждая крупная организация использовала свой стандарт передачи данных, электронный обмен информацией был бы неприемлемым для их более мелких партнёров. Стандарты AS1 и AS2 позволяют организациям выбирать одно решение для обмена данными со всеми бизнес-партнёрами, которые используют решения, основанные на этих стандартах.

    AS1 : Обеспечивает безопасность информации кодированием S/MIME (Secure/Multiporpose Internet Mail Extensions) через SMTP (Simple Mail Transfer Protocole) AS1 использует MDN (Message Disposition Notification) для проверки заявок.
    AS2 : Безопасность данных обеспечена S/MIME через HTTP (Hypertext Transfer Protocol) или HTTP/S (HTTP secure), так же с использованием MDN. В отличие от AS1, стандарт AS2 обеспечивает синхронную передачу данных в реальном времени с немедленными сообщениями о доставке.

    Как работает AS1?
    AS1 и AS2 - существующие в настояшее время спецификации, разработанные IETF для передачи данных между организациями через интернет. AS1 шифрует данные с помощью S/MIME (Secure/Multiporpose Internet Mail Extensions) через SMTP (Simple Mail Transfer Protocole), используя MDN (Message Disposition Notification) для проверки заявок.

    Кто использует AS2?
    Сегодня лидирующие торговые сети и производители находят ещё больше преимуществ стандарта AS2. Список компаний включает: Wal-Mart, Shaw`s, Target, Lowe`s, Wegmans, Procter & Gamble, Hershey Foods, Campbell`s и множество других. Многие из этих организаций привлекают своих торговых партнёров к использованию этой технологии для успешного ведения дел в торговом сообществе.

    EDI стандарт (Electronic Data Interchange) - часть старых, устоявшихся систем. Но мы постоянно видим, как EDI представляют, как современный стандарт. Так ли это? Надо ли нам рассматривать EDI в качестве базовой технологии для новых проектов?
    Давайте посмотрим на EDI с технической точки зрения, отбросив все остальное.

    Формат данных в EDI

    EDI использует delimited text формат . Он хорошо работает для плоских структур данных, таких как таблицы. Он не так хорош для представления иерархических структур данных. Вложенные объекты лучше сериализуются с помощью tagged форматов, таких, как XML и JSON.
    Очень странно, но так и не был создан язык описания (document definition) для EDI. Прошло столько лет с момента появления EDI и столько усилий было затрачено на него, но язык описания так и не создан. Язык описания позволяет автоматизировать обработку данных, а именно их генерацию, верификацию, преобразование, сериализацию, десериализацию. Для сравнения, для верификации XML данных мы берем схему данных (XML Schema, xsd) и парсер автоматически проверяет данные на соответствие этой схеме.
    Можно обойтись и без схемы, но тогда желательна разметка документа. XML и JSON документы могут быть десериализованны и без схемы, потому что сами данные содержат тэги (имена) элементов данных. EDI имеет тэги только для сегментов и не имеет тэгов для элементов. Элементы определяются позицией внутри сегмента. Универсальный EDI парсер сможет разобрать документ только на примитивные коллекции, потому что документ не содержит ни имен, ни типов для элементов данных.

    Давайте обратимся к деталям.

    EDI стандарт состоит из двух основных частей:

    • Envelope (пакетный?) формат (смесь стандартов сообщений (messaging))
    • Спецификации (форматы) документов (смесь индустриальных (domain) стандартов)

    Пакетный формат

    EDI определяет пакеты для наборов документов, групп документов и самих документов/транзакций (Interchange , Group and Transaction /Document) . Пакеты ограничиваются соответственно ISA/IEA, GS/GE, ST/SE парами сегментов.
    Замечание: Для иллюстрации я использую EDI X12 вариант стандарта, распространенный в Северной Америке. Другой вариант стандарта, EDIFACT, распространен в Европе и принципиально не отличается от X12.
    Здесь представлен пример самых первых сегментов всех трех пакетов: ISA, GS и ST. Пример взят отсюда :
    ISA*00* *00* *ZZ*RECEIVERID *12*SENDERID *100325*1113*U*00403*000011436*0*T*>~
    GS*FA*RECEIVERID*SENDERID*20100325*1113*24712*X*004030~
    ST*997*1136~

    Что мы видим в первом сегменте?
    Последние три символа сегмента ISA - это разделительные символы : "*>~": ‘~’ - символ разделения сегментов; ‘*’ - символ разделения элементов внутри сегмента; ‘>’ - символ разделения подэлементов внутри элемента. Изменяя эти символы мы по сути изменяем форматы пакетов и документов. В XML и JSON разделительные символы прописаны в стандарте, их нельзя изменить. Изменяемые разделительные символы - это рудименты эпохи, когда Unicode еще не был создан. Но даже в те времена делать разделительные символы изменяемыми было не очень хорошей идеей. Разделительные символы - очень важные символы. Если мы можем использовать любые символы в качестве разделителей, это не только именяет логику разбора пакетов на составляющие части, это сильно усложняет логику разбора текста внутри самих элементов.
    Еще в ISA сегменте мы видим элементы, определяющие форматы времени и дат . Они помогают нам использовать настраиваемые форматы дат и времён внутри документов. Это имело смысл в семидесятых годах, когда нам надо было сохранить несколько байт при кодировке дат и времён. Нужны ли эти элементы теперь, после того как мы побороли проблему «2000-ного года», после того как были созданы специализированные и очень подробные стандарты представления времени ?
    Мы видим в ISA сегменте элементы, определяющие отправителя и адресата . По сути это - адресная (routing ) информация. То есть стандарт упаковки объединен со стандартом адресации. Используя EDI, мы должны задавать отправителя и адресата внутри наших данных. В сегменте ISA есть еще и авторизационные элементы . Вся идея размещения этой авторизационной информации внутри самих сообщений когда-то была довольно прогрессивная, но сейчас она выглядит по меньшей мере наивной, а то и опасной. Сейчас мы понимаем, что авторизационная информация - много-много сложнее чем пара значений. То же самое можно сказать и про адресную информацию. EDI стандарт подталкивает нас к использованию этих элементов.
    Еще мы видим элемент запроса подтверждения (acknowledgement request ). То есть создатель документа задает стратегию использования подтверждений прямо в документе. Хорошая ли это идея? Мы можем использовать документы в разных сценариях. В некоторых из них подтверждения используются на уровне приложений, в других для повышения надежности используются другие протоколы. Политика надежности определяется не внутри самих данных, потому что надежность - это довольно сложная тема в передаче данных, определяемая многими участниками коммуникации.
    Еще внутри сегментов пакетов мы видим контрольные номера (Control Numbers ). Они нужны в сценариях, когда мы получаем набор документов, но часть набора потеряна или искажена по пути, и мы пытаемся восстановить как можно больше данных. Этот сценарий давно уже не используется, так как подобная проблема надежности как правило решается на нижних уровнях коммуникационных протоколов. Мы не встраиваем надежность коммуникаций на уровень приложений, так ведь?
    Другой элемент ISA сегмента, это EDI версия (Standard Identifier ). Это похоже на поддержку версионности, знакомую нам по сериализационным стандартам.
    В сегменте GS находится элемент, определяющий тип документа (Type of Document ). К примеру, это заказ или накладная. Ничего очень плохого в этом нет, хотя задавать тип документа проще внутри самого документа.

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

    EDI - это стандарт формата данных или протокол?
    EDI пытается быть протоколом, именно поэтому мы видим эти элементы адресации, авторизации и запроса подтверждения. Я не знаю, как эту информацию можно сопоставить с OSI protocol layer model.
    Но все же большая часть EDI стандарта посвящена форматам данных.
    Форматы документов
    Внутри пакетов мы видим сами документы. Но мы не найдем стандарта для универсального, обобщенного документа. Стандарт определяет многочисленные форматы для всевозможных типов документов: для заказов, для накладных, для описей вложения… вы найдете небольшую часть из громадного списка стандартизованных документов.
    EDI следует известному мифу: «Где-то там есть идеальный формат, который описывает все на свете сценарии. Мы обязательно найдем этот формат. Нам нужно просто добавлять новые сценарии и подстраивать старые.»
    Как результат EDI стандартные документы (спецификации) чрезмерно сложные.
    Возьмем один пример: Нам нужна накладная для небольшого местного книжного магазина. Мы нашли подходящую стандартную спецификацию, EDI 850, заказ на покупку (Purchase Order). На первый взгляд он выглядит чересчур детальным. Мы не будем покупать продукты питания, уголь, зерно, жидкие продукты, опасные продукты, медицинские препараты. Нам не нужны международные адреса. Мы не будем использовать службы срочной доставки. EDI спецификация описывает все эти возможные варианты, но в ней слишком много полей, которые мы никогда не будем использовать. Она чересчур сложна для нашего простого документа.
    Существует много индустриальных (domain) стандартов, которые используются как своеобразные хранилища знаний. Но эти стандарты не используются как стандарты передачи данных. (Посмотрите , описывающую проблему индустриальных стандартов.)
    Циклы (Loops) внутри документов
    Структура индивидуальных документов довольно проста. Документы составлены из серии сегментов, внутри которых находятся данные документов.
    Но оказывается, что сегменты могут объединяться в группы или в повторяющиеся группы, так называемые циклы (loops ). Пикантность в том, что эти циклы абсолютно никак не выделены в документе. О наличии цикла мы можем прочитать в спецификации данного конкретного документа. Сегменты одинакового типа (с одинаковыми тэгами) могут располагаться как независимо, так и внутри циклов. Создать парсер, распознающий циклы (которые, повторяю, никак не отмечаются в документе), это довольно нетривиальная задача.
    В XML и JSON такой проблемы не стоит, иерархические объекты или коллекции объектов любого уровня вложенности очень просто задаются с помощью открывающих и закрывающих тэгов, именованных или неименованных.
    EDI попытался усидеть на двух стульях. С одной стороны, его документный формат похож на формат csv и удобен для представления табличных данных. С другой стороны, он пытался описывать иерархические объекты, и попытка эта окончилась очень неубедительно. Конечно, мы понимаем это сейчас, когда имеем перед глазами JSON. Но давайте вспомним, что EDI был сделан не для передачи табличных данных, а именно для передачи документов, структура которых именно иерархическая.

    Нетехнический взгляд на EDI

    Для полной картины я все же перечислю некоторые из нетехнических особенностей EDI:
    • EDI стандарт не бесплатный . Это выглядит довольно странно по сравнению с другими стандартами.
    • Спецификации EDI стандарта чрезмерно детальны . EDI спецификации настолько сложны, что компании должны нанимать специалистов, знакомых с конкретной спецификацией. Эти специалисты общаются с помощью специальных EDI терминов, это почти EDI язык, который никак не связан с бизнесом. Посмотрите на EDI соглашения (agreements) между компаниями. Эти соглашения полны специфических требований, определяемый EDI стандартом, но далекими от требований бизнеса.
    • EDI стандарт не стабилен . Специальный комитет выпускает модификации EDI стандарта каждые полгода. Каждая из этих версий привносит новые уточнения. Развитие стандарта не следует запросам пользователей, скорее оно просто следует календарному плану. Предположительно это происходит не из-за очень высоких требований к стандарту, а потому что комитету нужно показать результаты своей работы.
    • EDI был создан, чтобы экономить биты и делать документы как можно более компактными. Это требование до сих пор существует, но оно вряд ли используется для передачи документов. Каждый ребенок сейчас владеет телефоном, который перекачивает гигабайты видео. На дворе уже не эпоха мэйнфреймов и телетайпов. И довольно странно читать отчеты, которые совершенно серьезно обсуждают экономию ресурсов из-за перехода с бумажного документооборота на использование EDI.
    • Для экономии памяти EDI использует коды для представления данных где только возможно. В результате документы выглядят зашифрованными, что создает дополнительную проблему обмена кодовыми таблицами.
    • EDI стандарт был создан для передачи наборов (batches) документов из-за того, что коммуникации и компьютеры стоили дорого и работали медленно. С тех пор многое изменилось, коммуникации и компьютеры стали быстрыми и дешевыми. Данные сейчас передаются маленькими сообщениями или потоками, и эти маленькие сообщения являются основой распределенных систем. Наборы документов еще используются, но не из-за медленного оборудования, а потому что это требуют бизнес-процессы.
    • Не существует стандарта на язык описания EDI . Это означает, что мы не можем создать универсальный парсер для обработки EDI документов. Парсеры должны содержать описания тысяч существующих EDI спецификаций с огромным количеством деталей. (К примеру, Microsoft предоставляет около 7 тысяч XML схем для EDI документов как часть BizTalk Server.) Имеющиеся EDI парсеры стоят дорого. Для работы с EDI документами нам скорее всего придется преобразовать EDI документы в формат XML и использовать XML Schema вместе с XML парсером для обработки EDI документов: для проверки, преобразования, сериализации, десериализации, создания. Что и делается в BizTalk Server.
    • Из-за отсутствия стандартного языка описания EDI документы описываются с помощью… многостраничных инструкций. Разработчики EDI парсеров трактуют эти инструкции по-разному, и из-за этого различные EDI парсеры несовместимы .
    • EDI стандарт создавался во времена, когда разработка программ, протоколов и форматов данных была чрезвычайно дорога и длилась очень долго. Создание стандарта для универсального формата документов было оправдано. Сейчас форматы данных генерируются на лету и наши программы как правило не используют каких-то универсальных стандартов, а создают разные форматы под конкретные случаи. EDI спецификации включают максимально возможное количество деталей , чтобы удовлетворить всех пользователей. Современные программы включают в спецификации передаваемых данных только те данные, которые необходимы. Количество элементов в EDI спецификации, ненужных в вашем конкретном случае всегда будет очень большим.
    • EDI смешивает два типа стандартов: стандарты для коммуникаций и стандарты для форматирования бизнес данных. Современные тенденции прямо противоположны: стандарты должны быть независимы друг от друга (ортогональны), что позволяет смешивать их в любых сочетаниях.

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

    Сфера применения

    В современных условиях даже небольшая коммерческая фирма «пропускает» через себя огромное количество коммерческих и финансовых документов.
    Использование традиционных схем бумажной или даже электронной (посредством e-mail) работы с документами существенно ограничивает потенциал развития бизнеса из-за присущих этим схемам недостатков.

    Типовая схема оформления торговых сделок предполагает следующие действия:

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

    На основе информации из документов генерируются новые бумажные документы и передаются в иные ведомства.

    Что плохо

    Можно сформулировать основные негативные стороны такой схемы работы:

    • использование различных форматов однотипных документов (каждая фирма может использовать свой формат) – сложность извлечения полезной информации;
    • чрезмерная степень применения ручного труда при оформлении или обработке документов («человеческий» фактор) – возможность внесения ошибок в документы и необходимость в дальнейшем их поиска и исправления;
    • низкая скорость (производительность) выполняемых операций при оформлении и обработке документов (ручное преобразование и перенос информации из документов в учетную систему и обратно);
    • отсутствие гарантий качества работы и контроля за передачей сообщений по общедоступным каналам доставки документов /сообщений (факс, электронная почта);
    • отсутствие гарантий конфиденциальности передаваемой информации;
    • необходимость создания и поддержания индивидуального способа обмена документами с каждым партнером;
    • экспоненциальное нарастание проблем при увеличении количества партнеров и интенсивности коммуникаций при взаимодействии с каждым партнером индивидуально.

    Также применение традиционных схем работы с документами существенно ограничивает (или делает практически невозможным) внедрение новых активно развивающихся бизнес-процессов и новейших технологий, таких как VMI (Vendor Managed Inventory – запас, управляемый поставщиком) и CPFR (Collaborative Planning, Forecasting & Replenishment – совместное планирование, прогнозирование и пополнение), которые позволяют существенно увеличить оборот между партнерами и повысить их конкурентноспособность на рынке.

    Где же выход?

    Существует решение, которое позволяет преодолеть все названные ограничения и предоставить новые возможности. Это система электронного обмена данными – EDI (Electronic Data Interchange).

    Что это такое?

    EDI – это технология автоматизированного обмена электронными сообщениями в стандартизированных форматах между бизнес-партнерами.

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

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

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

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

    Как устроен EDI?

    Базовые принципы:

    • Стандартизованность
    • Структурированность

    Практика электронной коммерции, основанной на системах EDI насчитывает уже более 30 лет и обобщается в стандартах выполнения торговых операций и представлении структурированных деловых документов.

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

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

    Стандарты

    EDI базируется на следующих основных стандартах:

    • UN/EDIFACT – United Nations Electronic Data Interchange for Administration, Commerce and Transport — «Правила ООН электронного обмена документами для гос. управления, торговли и транспорта» – основополагающий глобальный избыточный стандарт, содержащий наиболее общие справочники международных кодов и форматов сообщений, расширенных для удовлетворения всех возможных запросов пользователей.
    • (UN/CEFACT) – адаптированный Центром ООН по упрощению процедур международной торговли и электронному бизнесу (CEFACT) стандарт UN/EDIFACT
      GS1 EANCOM – подмножество EDIFACT для розничной торговли — разработан международной ассоциацией GS1 и дополнен использованием ключевых идентификаторов системы GS1.
    • GS1 XML – современный формат сообщений, используемых при обмене данными в цепях поставок в системе GS1.
    • Система GS1 – это международная глобальная многоотраслевая система стандартов, охватывающая более 100 стран.
    • Система GS1 является самой широко используемой международной системой стандартов в цепях поставок. В настоящее время свыше миллиона компаний в мире используют стандарты GS1. Национальные ассоциации GS1 обеспечивают поддержку системы в своих странах и поддержку национальных языков в системе GS1.

    В основе архитектуры системы GS1 лежат ключевые идентификаторы, основными из которых являются:

    • GTIN (Global Trade Item Number)– глобальный номер торговой единицы (предмета торговли) –уникальный идентификационный номер торговой единицы в системе GS1. Этот идентификатор представлен в виде символа штрихового кода на упаковке товара.
    • GLN (Global Location Number) – глобальный номер места нахождения – уникальный номер в системе GS1 для идентификации участников цепи поставки и их материальных, функциональных или юридических объектов (подразделений) (филиалы/офисы/склады/рампы и т.д.). Используется главным образом в EDI для эффективной идентификации всех объектов, касающихся поставок.
    • SSCC (Serial Shiping Container Code) – серийный код транспортной упаковки (СКТУ) – уникальный идентификатор логистической (транспортной) единицы. SSCC очень удобен для маркировки грузов, подлежащих танспортировке.

    Ключевые идентификаторы системы GS1 являются:

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

    Зачем нужен GLN?

    Номер GLN – это глобальный уникальный цифровой код , идентифицирующий участника в цепи поставок (контрагента или его структурное подразделение или объект).

    Присвоение идентификационных номеров GLN регулируется стандартами системы GS1 для того, чтобы гарантировать уникальность каждого отдельного номера во всем мире. Для получения GLN-номера предприятие должно стать членом национальной ассоциации GS1(в РФ такой организацией является GS1 Russia – ГС1 РУС.).

    Идентификационные номера GLN ежедневно широко используются более чем 200.000 компаний, занимающихся различными видами предпринимательской деятельности

    Преимущества идентификационных номеров GLN

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

    При полном соблюдении стандартов GS1 по номеру GLN становится возможным извлечение из глобального регистра участников системы GS1 (GEPIR) следующей информации:

    • тип объекта (производственный центр, складское помещение, торговый офис, офис компании и т.д.);
    • регион;
    • почтовый адрес;
    • номер телефона, факса;
    • контактное лицо;
    • информация о банковских реквизитах;
    • требования и ограничения доставки и пр.

    Основные виды сообщений

    Основными считаются следующие сообщения EDI:

    • COMDIS – коммерческая дискуссия,
    • PRICAT – прайс-лист,
    • ORDER – заказ,
    • ORDRRSP – подтверждение заказа,
    • DESADV – уведомление об отгрузке,
    • RECADV – уведомление о приемке,
    • INVOICE – счет,
    • SLSRPT – отчет о продажах,
    • INVRPT – отчет об инвентаризации.

    Технология работы

    Технология EDI предполагает использование единого способа идентификации товаров и контрагентов на базе стандартов GS1: идентификация товарных позиций ведется с использованием кодов GTIN (штриховых кодов), идентификация контрагентов ведется с использованием GLN-номеров. Присвоение кодов GTIN и GLN номеров осуществляет национальная ассоциация GS1 (в РФ — Ассоциация Автоматической Идентификации ЮНИСКАН/ГС1 РУС).

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

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

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

    Типичная цепочка взаимодействия контрагентов при использовании EDI выражается следующей схемой:

    1. Покупатель высылает поставщику заказ;
    2. Поставщик автоматически загружает заказ в свою учетную систему;
    3. Поставщик после корректировки по реальным остаткам на складе отсылает подтверждение заказа и формирует внутреннюю накладную на отгрузку;
    4. Поставщик после отгрузки одним нажатием формирует и отсылает покупателю уведомление об отгрузке;
    5. Покупатель после приемки по уведомлению об отгрузке автоматически формирует и высылает поставщику уведомление о приемке;
    6. Поставщик на основании уведомления о приемке автоматически формирует расходную накладную;
    7. Поставщик выгружает покупателю электронный вариант расходной накладной;
    8. Покупатель загружает в свою учетную систему расходную накладную поставщика.

    При этом все сообщения передаются максимально оперативно и с уведомлениями о гарантированной доставке.

    В настоящее время доступны два варианта подключения (интеграции) к EDI:

    • Полная интеграция учетной системы партнера с платформой провайдера. При этом предполагается автоматическая обработка входящих и генерация исходящих сообщений в учетной системе предприятия. Для интеграции необходимо разрабатывать и согласовывать форматы экспорта – импорта информации и технологию передачи сообщения в систему провайдера. При таком варианте возможно использовать преимущества EDI в полной мере.
    • Второй вариант – частичная интеграция — использование Web-EDI. Взаимодействие с платформой EDI осуществляется через Web-браузер или специализированный Web-клиент, без непосредственной интеграции с учетной системой. Такой вариант работы не ведет к максимальному повышению эффективности, так как требует участия человека в приеме и передаче документов (ручной перенос данных из системы EDI в информационную систему и обратно), однако, характеризуется предельной экономичностью внедрения и использования.

    Гарантии достоверности и конфиденциальности

    Провайдер обеспечивает достоверность, конфиденциальность, оперативность и гарантированность передачи сообщений.

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

    Достоверность – использованием технологий передачи сообщений, исключающих возможность коррекции документа в процессе передачи (проверка контрольных сумм сообщений на каждом участке и т.д.).

    Гарантированность доставки – механизмом оповещений о местонахождении сообщений и автоматическим оповещением отправителя о доставке сообщения.

    Удобство и выгоды

    Основные преимущества технологии:

    • прямое снижение накладных расходов по ведению документооборота (объем первичных бумажных документов, трудозатраты персонала,
    • курьерская служба, почтовые расходы, оплата услуг электросвязи и пр.),
    • упрощение контроля операционной деятельности (товародвижение),
    • упрощение взаимодействия с контрагентами,
    • существенное увеличение скорости оборота и снижение объемов складских запасов,
    • повышение рентабельности оборотного капитала,
    • упрощение и увеличение эффективности внедрения средств (терминалов сбора данных) и технологий автоматизации учета,
    • возможность внедрения новых технологий взаимодействия участников цепей поставок — VMI и CPFR,
    • оптимизация и повышение эффективности бизнеса.

    Преимущества появляются за счет:

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

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

    Наиболее восприимчивые области применения:

    • Дистрибуция,
    • Ритейл,
    • Управление складами,
    • Транспорт,
    • Банковская сфера и управление денежными потоками
    • и т.д.

    Чтобы начать обмениваться документами по EDI необходимо:

    • получить номер GLN;
    • выбрать вариант подключения (полная интеграция или Web-EDI),
    • выбрать авторизованного провайдера EDI,
    • осуществить подключение,
    • начать работать.

    Для более детального знакомства с технологией EDI и практикой ее применения приглашаем посетить наш семинар «Электронный обмен данными (EDI)»



    Похожие статьи

    © 2024 my-kross.ru. Кошки и собаки. Маленькие животные. Здоровье. Лекарство.