EDI стандарт. Технический обзор
Формат данных в EDI
EDI использует delimited text формат. Он хорошо работает для плоских структур данных, таких как таблицы. Он не так хорош для представления иерархических структур данных. Вложенные объекты лучше сериализуются с помощью tagged форматов, таких, как XML и JSON.
Очень странно, но так и не был создан язык описания (document definition) для EDI. Прошло столько лет с момента появления EDI и столько усилий было затрачено на него, но язык описания так и не создан. Язык описания позволяет автоматизировать обработку данных, а именно их генерацию, верификацию, преобразование, сериализацию, десериализацию. Для сравнения, для верификации XML данных мы берем схему данных (XML Schema, xsd) и парсер автоматически проверяет данные на соответствие этой схеме.
Можно обойтись и без схемы, но тогда желательна разметка документа. XML и JSON документы могут быть десериализованны и без схемы, потому что сами данные содержат тэги (имена) элементов данных. EDI имеет тэги только для сегментов и не имеет тэгов для элементов. Элементы определяются позицией внутри сегмента. Универсальный EDI парсер сможет разобрать документ только на примитивные коллекции, потому что документ не содержит ни имен, ни типов для элементов данных.
Давайте обратимся к деталям.
Пакетный формат
ISA*00* *00* *ZZ*RECEIVERID *12*SENDERID *100325*1113*U*00403*000011436*0*T*>
’ — символ разделения сегментов; ‘*’ — символ разделения элементов внутри сегмента; ‘>’ — символ разделения подэлементов внутри элемента. Изменяя эти символы мы по сути изменяем форматы пакетов и документов. В 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?
Ускоряйте обработку заказов и подписание закрывающих документов
Увеличивайте оборот и быстрее получайте оплату за счет сокращения числа ошибок
Формируйте электронные юридически значимые документы
Экономьте на доставке, хранении и печати бумажных документов
Снижайте риск получить штраф от заказчика за недопоставку или поставку не в срок
Все партнеры — в одном сервисе
Торговые сети
Снижайте риск получения штрафов, увеличивайте оборот за счет автоматизации процесса и оперативно обрабатывайте заказы от сетей.
Факторинговые компании
Отправляйте документы по поставке сети и фактору одновременно, чтобы сразу получить оплату.
Несетевая розница
Загружайте прайс в сервис, чтобы вся несетевая розница региона видела ваши позиции. Сокращайте расходы на торговых представителей и получайте новых клиентов.
Производители
Получайте заказы от торговых сетей и дистрибьюторов и расширяйте каналы сбыта.
HoReCa
Поставляйте товары в кафе и рестораны, чтобы охватить новые сегменты рынка.
Собственные юрлица
Переведите внутренний документооборот в электронный вид, чтобы ускорить подписание документов между юрлицами.
Дистрибьюторы
Отправляйте заказы производителю и поставляйте товары заказчику в одном и том же сервисе
Поставщики услуг
Получайте закрывающие документы за услуги связи и ЖКХ.
Цепочка электронного взаимодействия
Торговые сети сами определяют цепочки электронного взаимодействия, поэтому в зависимости от требований ТС, цепочки могут различаться. Также цепочки могут различаться в зависимости от категории товара поставщика и схемы работы: с НДС или без НДС.
Торговые сети сами определяют цепочки электронного взаимодействия, поэтому в зависимости от требований ТС, цепочки могут различаться. Также цепочки могут различаться в зависимости от категории товара поставщика и схемы работы: с НДС или без НДС.
Как работает сервис
EDI (Electronic data interchange — электронный обмен данными) — стандартизированные форматы сообщений для передачи коммерческой информации между организациями.
GLN — это уникальные 13-значные числовые идентификаторы юридических лиц или их подразделений, они являются ссылочными ключами для извлечения из базы данных следующей информации:
Для получения GLN необходимо обратиться в «GS1». Наши менеджеры всегда готовы объяснить, как пройти процедуру получения, и помогут заполнить заявление.
PRICAT — ценовой лист, содержит информацию о перечне товаров с указанием цен, отправляется поставщиком.
ORDERS — заказ, формируется в учетной системе торговой сети, направляется EDI-сообщением и автоматически выгружается в учетную систему поставщика.
ORDRSP — подтверждение заказа, в ответ на заказ поставщик может направить EDI-сообщение ORDRSP, в котором уточнить фактурную часть и время поставки.
DESADV — уведомление об отгрузке, аналог товаросопроводительных документов (ТТН), передается в момент отгрузки и содержит актуальную информацию об отгрузке товара со склада поставщика.
ALCRPT — дополнительное сообщение по поставке алкопродукции, содержит информацию об алкогольной продукции, отправляется вместе с DESADV
RECADV — уведомление о приемке, содержит информацию о фактически принятом товаре (с указанием причины неприемки. Позволяет сразу после приемки сформировать корректный счет-фактуру).
В рамках действующего законодательства все виды EDI-сообщений не являются юридически значимыми.
Модули можно установить для следующих версий:
Также мы разработали принципиально новый универсальный модуль для 1С 7.7 — Custom Tools. Это настоящий конструктор, который адаптируется к различным конфигурациям учетной системы.
Для владельцев любых учетных систем (SAP, MS Dynamics, Oracle) предусмотрена простая интеграция через API.
Для пользователей 1С было разработано специальное коробочное решение, которое позволит получать заказы и оформлять поставки непосредственно внутри учетной записи.
Также всем клиентам доступна удобная и функциональная веб-версия.
Для работы в 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 – выбор пути, которым информация будет передана из одного места в другое, напрямую или через 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:
— Что требуется для начала?
Вот на что стоит обратить внимание, выбирая программу-решение для обмена различными бизнес-документами с деловыми партнёрами:
— Снова 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 обеспечивает синхронную передачу данных в реальном времени с немедленными сообщениями о доставке.
Кто использует AS2?
Сегодня лидирующие торговые сети и производители находят ещё больше преимуществ стандарта AS2. Список компаний включает: Wal-Mart, Shaw`s, Target, Lowe`s, Wegmans, Procter & Gamble, Hershey Foods, Campbell`s и множество других. Многие из этих организаций привлекают своих торговых партнёров к использованию этой технологии для успешного ведения дел в торговом сообществе.
СОДЕРЖАНИЕ
История
Стандарты
EDI обеспечивает техническую основу для автоматизированных коммерческих «разговоров» между двумя организациями, внутренними или внешними. Термин EDI охватывает весь процесс электронного обмена данными, включая передачу, поток сообщений, формат документа и программное обеспечение, используемое для интерпретации документов. Однако стандарты EDI описывают строгий формат электронных документов, а стандарты EDI были разработаны, первоначально в автомобильной промышленности, чтобы быть независимыми от коммуникационных и программных технологий.
Документы EDI обычно содержат ту же информацию, которую обычно можно найти в бумажном документе, используемом для той же организационной функции. Например, заказ на отправку со склада EDI 940 используется производителем, чтобы сообщить складу о необходимости отгрузки продукта розничному продавцу. Обычно он имеет адрес доставки, адрес получателя счета, а также список номеров продуктов (обычно UPC ) и количества. Другим примером является набор сообщений между продавцами и покупателями, таких как запрос предложения (RFQ), предложение в ответ на запрос предложения, заказ на покупку, подтверждение заказа на покупку, уведомление о доставке, получение совета, счет-фактура и уведомление об оплате. Однако EDI не ограничивается только бизнес-данными, связанными с торговлей, но охватывает все области, такие как медицина (например, записи пациентов и результаты лабораторных исследований), транспорт (например, информация о контейнерах и видах транспорта), проектирование и строительство и т. Д. EDI будет использоваться для создания нового потока деловой информации (раньше это не было бумажным потоком). Так обстоит дело с расширенным уведомлением об отправке (ASN), которое было разработано для информирования получателя об отправке, о товарах, которые должны быть получены, и о том, как товары упакованы. Это дополнительно дополняется использованием посылкой транспортных этикеток, содержащих штрих-код GS1-128, указывающий на номер отслеживания посылки.
Некоторые основные наборы стандартов EDI:
Стандарт EDI предписывает обязательную и необязательную информацию для конкретного документа и дает правила для структуры документа. Стандарты подобны строительным нормам. Подобно тому, как две кухни могут быть построены « для программирования », но выглядят совершенно по-разному, два документа EDI могут соответствовать одному стандарту и содержать разные наборы информации. Например, пищевая компания может указать срок годности продукта, а производитель одежды может отправить информацию о цвете и размере.
Протоколы передачи
EDI может передаваться с использованием любой методологии, согласованной отправителем и получателем, но по мере того, как все больше торговых партнеров начали использовать Интернет для передачи, появились стандартизированные протоколы.
Это включает в себя множество технологий, в том числе:
Интернет
По мере того, как все больше организаций подключались к Интернету, в конечном итоге большая часть или все EDI были перенесены на него. Первоначально это было через специальные соглашения, такие как незашифрованный FTP текстовых файлов ASCII в определенную папку на определенном хосте, разрешенный только с определенных IP-адресов. Однако IETF опубликовал несколько информационных документов («Заявления о применимости»; см. Ниже в разделе « Протоколы» ), описывающих способы использования стандартных Интернет-протоколов для EDI.
С 2002 года Walmart продвинул AS2 для EDI. Из-за своего значительного присутствия в глобальной цепочке поставок AS2 стал общепринятым подходом для EDI.
Характеристики
Организации, которые отправляют или получают документы между собой, в терминологии EDI называются «торговыми партнерами». Торговые партнеры договариваются о конкретной информации, которая будет передаваться, и о том, как ее следует использовать. Это делается в удобочитаемых спецификациях (также называемых Руководством по реализации сообщений). Хотя стандарты аналогичны строительным нормам и правилам, спецификации аналогичны чертежам. (Спецификацию также можно назвать «сопоставлением», но термин «сопоставление» обычно зарезервирован для конкретных машиночитаемых инструкций, передаваемых программному обеспечению перевода). Более крупные торговые «хабы» имеют существующие Руководства по реализации сообщений, которые отражают их бизнес-процессы для обработки EDI. и они обычно не желают изменять свою бизнес-практику EDI для удовлетворения потребностей своих торговых партнеров. Часто в крупных компаниях эти руководящие принципы EDI должны быть достаточно общими для использования различными филиалами или подразделениями и, следовательно, будут содержать информацию, не необходимую для конкретного обмена бизнес-документами. Для других крупных компаний они могут создавать отдельные руководящие принципы EDI для каждого филиала / подразделения.
Передача: прямой EDI и VAN
Торговые партнеры могут использовать любой метод передачи документов (как описано выше в разделе «Протоколы передачи»). Далее они могут взаимодействовать напрямую или через посредника.
Прямой EDI: одноранговый
Торговые партнеры могут напрямую подключаться друг к другу. Например, производитель автомобилей может поддерживать модемный пул, к которому должны подключаться все его сотни поставщиков для выполнения EDI. Однако, если поставщик ведет бизнес с несколькими производителями, ему может потребоваться приобрести другой модем (или устройство VPN и т. Д.) И другое программное обеспечение для каждого из них.
По мере развития EDI и веб-технологий появились новые программные технологии EDI для облегчения прямого (также известного как точка-точка) EDI между торговыми партнерами. Современное программное обеспечение EDI может способствовать обмену с использованием любого количества различных протоколов передачи файлов и стандартов документов EDI, снижая затраты и препятствуя доступу.
Сети с добавленной стоимостью
VAN могут эксплуатироваться различными организациями:
Затраты, компромиссы и реализация
Важно отметить, что существуют ключевые компромиссы между VAN и Direct EDI, и во многих случаях организации, обменивающиеся документами EDI, могут фактически использовать их совместно для различных аспектов своей реализации EDI. Например, в США большинство обменов документами EDI используют AS2, поэтому прямая настройка EDI для AS2 может иметь смысл для организации, расположенной в США. Но добавление возможностей OFTP2 для связи с европейским партнером может быть трудным, поэтому VAN может иметь смысл для обработки этих конкретных транзакций, в то время как прямой EDI используется для транзакций AS2.
Во многих отношениях VAN действует как поставщик услуг, упрощая большую часть настройки для организаций, желающих инициировать EDI. В связи с тем, что многие организации, впервые начинающие с EDI, часто делают это для удовлетворения требований клиентов или партнеров и, следовательно, не имеют собственного опыта в области EDI, VAN может быть ценным активом.
Однако использование VAN может быть связано с высокими затратами. VAN обычно взимают плату за транзакцию за документ или даже за транзакцию за каждую позицию для обработки транзакций EDI как услуги от имени своих клиентов. Это основная причина, по которой многие организации также внедряют программное решение EDI или в конечном итоге переходят к нему для некоторых или всех своих EDI.
Другие трудоемкие задачи EDI включают общение с торговыми партнерами, устранение ошибок EDI и тестирование EDI.
Чтобы помочь в решении этих проблем, многие организации с менее надежными ИТ-командами или без ИТ-специалистов работают с поставщиком полного спектра услуг EDI. Поставщики полного спектра услуг EDI берут на себя управление требованиями EDI и обеспечение постоянного соответствия.
Интерпретация данных
Для «исходящего» документа процесс интегрированного EDI заключается в экспорте файла (или чтении базы данных) из информационных систем компании и преобразовании файла в формат, подходящий для переводчика. Программное обеспечение для перевода затем «проверит» отправленный файл EDI, чтобы убедиться, что он соответствует стандарту, согласованному торговыми партнерами, преобразует файл в формат «EDI» (добавив соответствующие идентификаторы и управляющие структуры) и отправит файл в торговый центр. партнер (используя соответствующий протокол связи).
Еще одним важным компонентом любого программного обеспечения для перевода EDI является полный «аудит» всех шагов по перемещению деловых документов между торговыми партнерами. Аудит гарантирует, что любая транзакция (которая на самом деле является бизнес-документом) может быть отслежена, чтобы гарантировать, что они не потеряны. В случае, если розничный торговец отправляет заказ на поставку поставщику, если заказ на поставку «утерян» где-то в бизнес-процессе, эффект будет разрушительным для обоих предприятий. Для поставщика они не выполняют заказ, поскольку он не получил его, что приводит к потере бизнеса и нарушению деловых отношений со своим розничным клиентом. Для розничного торговца они испытывают перебои с товарными запасами, а это приводит к потере продаж, сокращению обслуживания клиентов и, в конечном итоге, к снижению прибыли.
В терминологии EDI «входящий» и «исходящий» относятся к направлению передачи EDI-документа по отношению к конкретной системе, а не к направлению товаров, денег или других вещей, представленных в документе. Например, документ EDI, который сообщает складу о необходимости выполнения исходящей отгрузки, является входящим документом по отношению к компьютерной системе склада. Это исходящий документ в отношении производителя или дилера, передавшего документ.
Преимущества перед бумажными системами
EDI и другие аналогичные технологии экономят деньги компании, предоставляя альтернативу или заменяя информационные потоки, которые требуют большого взаимодействия человека и бумажных документов. Даже когда бумажные документы хранятся параллельно с обменом EDI, например, распечатанные грузовые декларации, электронный обмен и использование данных из этого обмена снижает затраты на сортировку, распространение, систематизацию и поиск бумажных документов. EDI и аналогичные технологии позволяют компании воспользоваться преимуществами хранения и обработки данных в электронном виде без затрат на ручной ввод. Еще одним преимуществом EDI является возможность уменьшить или устранить ошибки ручного ввода данных, такие как ошибки доставки и выставления счетов, поскольку EDI устраняет необходимость повторного ввода ключей документов на стороне назначения. Одним из очень важных преимуществ EDI перед бумажными документами является скорость, с которой торговый партнер получает и включает информацию в свою систему, значительно сокращает время цикла. По этой причине EDI может быть важным компонентом оперативных производственных систем.
Препятствия на пути к реализации
Подтверждение
Ниже приведены общие подтверждения EDI
