Электронный обмен данными

редактировать

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

EDI существует по крайней мере с начала 70-х годов, и существует множество стандартов EDI (включая X12, EDIFACT, ODETTE и т. Д.), некоторые из которых отвечают потребностям конкретных отраслей или регионов. Это также относится конкретно к семейству стандартов. В 1996 году Национальный институт стандартов и технологий определил электронный обмен данными как «обмен между компьютерами строго отформатированными сообщениями, которые представляют документы, отличные от денежных инструментов. EDI подразумевает последовательность сообщений между двумя сторонами., любой из которых может выступать в качестве отправителя или получателя. Отформатированные данные, представляющие документы, могут передаваться от отправителя к получателю по телекоммуникациям или физически переноситься на электронных носителях ". Он отличал простую электронную связь или обмен данными, указывая, что «в EDI обычная обработка полученных сообщений осуществляется только компьютером. Вмешательство человека в обработку полученного сообщения обычно предназначено только для ошибок, для проверки качества и для специальных Например, передача двоичных или текстовых данных не является EDI, как определено здесь, если только данные не обрабатываются как один или несколько элементов данных EDI-сообщения и обычно не предназначены для интерпретации человеком в рамках онлайн-обработки данных ». Короче говоря, EDI можно определить как передачу структурированных данных в соответствии с согласованными стандартами сообщений из одной компьютерной системы в другую без вмешательства человека.

Содержание

  • 1 История
  • 2 Стандарты
  • 3 Протоколы передачи
    • 3.1 Интернет
  • 4 Технические характеристики
  • 5 Передача: Direct EDI и VAN
    • 5.1 Direct EDI: одноранговая -peer
    • 5.2 Сети с добавленной стоимостью
    • 5.3 Затраты, компромиссы и внедрение
  • 6 Интерпретация данных
  • 7 Преимущества перед бумажными системами
  • 8 Препятствия на пути внедрения
  • 9 Подтверждение
  • 10 См. Также
  • 11 Ссылки
  • 12 Дополнительная литература
  • 13 Внешние ссылки

История

Как и многие другие ранние информационные технологии, EDI был вдохновлен разработками в военной логистике. Сложность воздушной перевозки Берлина 1948 года потребовала разработки концепций и методов для обмена, иногда более 300 бод телетайпа модемом, огромными объемами данных и информации о перевозимых товарах. Эти первоначальные концепции позже сформировали первые стандарты TDCC (Координационного комитета по транспортным данным) в США. Среди первых интегрированных систем, использующих EDI, были Freight Control Systems. Одной из таких систем реального времени была Схема EDP для грузовых перевозок в лондонском аэропорту (LACES) в аэропорту Хитроу, Лондон, Великобритания, в 1971 году. Реализуя метод прямого ввода данных трейдером (DTI), она позволяла экспедиторам вводить информацию непосредственно в система таможенной обработки, сокращающая время на оформление. Рост морских перевозок и проблемы на таможне, аналогичные тем, которые имели место в аэропорту Хитроу, привели к внедрению систем DTI в отдельных портах или группах портов в 1980-х годах.

Стандарты

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

Документы EDI обычно содержат ту же информацию, которую обычно можно найти в бумажном документе, используемом для той же организационной функции. Например, заказ на отправку со склада EDI 940 используется производителем, чтобы сообщить складу о необходимости отгрузки продукта розничному продавцу. Обычно он имеет адрес доставки, адрес получателя счета и список номеров продуктов (обычно UPC ) и количества. Другим примером является набор сообщений между продавцами и покупателями, например запрос предложения (RFQ), предложение в ответ на запрос предложения, заказ на покупку, подтверждение заказа на покупку, уведомление о доставке, получение совета, счет-фактура и платеж. совет. Однако EDI не ограничивается только бизнес-данными, связанными с торговлей, но охватывает все области, такие как медицина (например, записи пациентов и результаты лабораторных исследований), транспорт (например, информация о контейнерах и видах транспорта), проектирование и строительство и т. Д. EDI будет использоваться для создания нового потока бизнес-информации (раньше это не было бумажным потоком). Так обстоит дело с расширенным уведомлением об отправке (ASN), которое было разработано для информирования получателя об отправке, о товарах, которые должны быть получены, и о том, как товары упакованы. Это дополнительно дополняется использованием посылкой транспортных этикеток, содержащих штрих-код GS1-128, указывающий на номер отслеживания отправления.

Некоторые основные наборы стандартов EDI:

  • UN -рекомендуется UN / EDIFACT является единственным международным стандартом и преобладает за пределами Северной Америки.
  • Стандарт США ANSI ASC X12 (X12) является
  • GS1 EDI набор стандартов разработал GS1, преобладающий в глобальной цепочке поставок
  • Стандарт TRADACOMS, разработанный ANA ( Ассоциация товарных номеров, известная теперь как), преобладает в Великобритании розничной торговле.
  • Стандарт ODETTE, используемый в европейской автомобильной промышленности
  • Стандарт VDA, используемый в европейской автомобильной промышленности. промышленность в основном в Германии
  • HL7, стандарт семантической совместимости, используемый для данных здравоохранения.
  • HIPAA, Закон о переносимости и подотчетности медицинского страхования (HIPAA), требует миллионов Медицинские организации, которые передают данные в электронном виде для использования EDI в стандартном формате HIPAA.
  • , IATA Cargo-IMP означает процедуры обмена сообщениями грузовой ассоциации Международной ассоциации воздушного транспорта. Это стандарт EDI, основанный на EDIFACT, созданный для автоматизации и стандартизации обмена данными между авиакомпаниями и другими сторонами.
  • NCPDP Script, SCRIPT - стандарт, разработанный и поддерживаемый Национальным советом по программам рецептурных препаратов (NCPDP). Стандарт определяет документы для электронной передачи медицинских рецептов в Соединенных Штатах.
  • Edig @ s (EDIGAS) - это стандарт, касающийся торговли, транспортировки (по трубопроводу или контейнерам) и хранения газа.

Многие из этих стандартов впервые появились в начале-середине 1980-х годов. Стандарты предписывают форматы, наборы символов и элементы данных, используемые при обмене бизнес-документами и формами. Полный список документов X12 включает все основные бизнес-документы, включая заказы на поставку и счета-фактуры.

Стандарт EDI предписывает обязательную и необязательную информацию для конкретного документа и дает правила для структуры документа. Стандарты подобны строительным нормам. Подобно тому, как две кухни могут быть построены «с кодом », но выглядеть совершенно по-разному, два документа EDI могут соответствовать одному стандарту и содержать разные наборы информации. Например, пищевая компания может указать срок годности продукта, а производитель одежды может отправить информацию о цвете и размере.

Протоколы передачи

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

Сюда входят различные технологии, в том числе:

  • mModem (асинхронный и синхронный)
  • FTP, SFTP и FTPS
  • Электронная почта
  • HTTP
  • AS1
  • AS2
  • AS4
  • OFTP (и OFTP2)
  • Mobile EDI
  • И другие технологии

Когда некоторые люди сравнивали модемы с синхронным протоколом 2400 бит / с, CLEO устройства и сети с добавленной стоимостью, используемые для передачи документов EDI для передачи через Интернет, они приравнивали неинтернет-технологии к EDI и ошибочно предсказывали, что сам EDI будет заменен вместе с неинтернет-технологиями. Интернет-технологии. В большинстве случаев эти методы передачи, не связанные с Интернетом, просто заменяются Интернет-протоколами, такими как FTP, HTTP, telnet и электронная почта, но сами документы EDI по-прежнему остаются.

В 2002 г. IETF опубликовал RFC 3335, предлагающий стандартизированный безопасный метод передачи данных EDI по электронной почте. 12 июля 2005 г. рабочая группа IETF ратифицировала RFC4130 для передачи HTTP EDIINT (также известного как AS2 ) на основе MIME, а IETF подготовила аналогичный RFC для передачи по FTP (также известный как AS3 ). EDI через веб-службы (также известный как AS4 ) также стандартизирован органом стандартизации OASIS. Хотя некоторая передача 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, снижая затраты и препятствуя доступу.

Сети с добавленной стоимостью

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

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 получит файл (либо через сеть с добавленной стоимостью, либо напрямую с использованием таких протоколов, как FTP или AS2), примет полученный файл EDI (обычно называемый «конвертом») и подтвердить, что торговый партнер, отправляющий файл, является действительным торговым партнером, что структура файла соответствует стандартам EDI и что отдельные поля информации соответствуют согласованным стандартам. Обычно переводчик либо создает файл фиксированной длины, переменной длины или формата с тегами XML, либо «распечатывает» полученный документ EDI (для неинтегрированных сред EDI). Следующим шагом является преобразование создаваемого переводчиком файла в формат, который можно импортировать во внутренние бизнес-системы, приложения или ERP компании. Это может быть выполнено с помощью специальной программы, встроенного проприетарного «преобразователя» или интегрированного основанного на стандартах графического «преобразователя» с использованием стандартного языка преобразования данных, такого как XSLT. Последний шаг - импортировать преобразованный файл (или базу данных) во внутреннюю систему компании.

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

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

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

Преимущества по сравнению с бумажными системами

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

Согласно отчету Абердина 2008 г. «Сравнение возможностей поставщиков по всему миру», передаются только 34% заказов на поставку. в электронном виде в Северной Америке. В EMEA 36% заказов передаются электронным способом, а в APAC 41% заказов передаются в электронном виде. Они также сообщают, что средняя заявка на заказ бумаги обходится компании в 37,45 долларов в Северной Америке, 42,90 долларов в странах Европы, Ближнего Востока и Африки и 23,90 долларов в Азиатско-Тихоокеанском регионе. При заказе EDI-заявки затраты снижаются до 23,83 долларов в Северной Америке, 34,05 долларов в странах Европы, Ближнего Востока и Африки и 14,78 долларов в Азиатско-Тихоокеанском регионе.

Препятствия на пути внедрения

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

Еще одно существенное препятствие - это затраты времени и денег на первоначальную настройку. Предварительные затраты и время, связанные с внедрением, настройкой и обучением, могут быть дорогостоящими. Важно выбрать правильный уровень интеграции, соответствующий бизнес-требованиям. Для бизнеса с относительно небольшим количеством транзакций с партнерами на основе EDI может иметь смысл внедрять недорогие решения «скопировать и прочитать», когда формат EDI распечатывается в удобочитаемой форме, а люди - а не компьютеры - реагируют на транзакцию. Другой альтернативой являются аутсорсинговые решения EDI, предоставляемые EDI "Service Bureaus". Другим предприятиям может потребоваться внедрение интегрированного решения EDI, поскольку увеличение объемов торговли, вызванное EDI, вынуждает их заново внедрять свои бизнес-процессы обработки заказов.

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

Подтверждение

Ниже приведены общие подтверждения EDI

  • Состояние связи - Укажите, что передача завершена
  • MDN (Уведомление об отправке сообщения) - Только в AS2 укажите, что сообщение доступно для чтения
  • Функциональное подтверждение - обычно «997» в ANSI или «CONTRL» в EDIFACT, что указывает на то, что содержимое сообщения проверяется по его шаблону, и сообщает, размещена ли транзакция в электронной системе получателя.
  • Подтверждение бизнес-уровня - последний индикатор показывает, принята ли транзакция получателем или нет.

См. Также

Протоколы
  • HTTP / HTTPS
  • POP3 / SMTP
  • OFTP / OFTP2
  • SOAP
  • WebDAV
  • X.400
  • Рабочая группа EDIINT:
    • EDIINT AS1 (расширение для почтового транспорта)
    • EDIINT AS2 (на основе транспорта HTTP)
    • EDIINT AS3 (базовый ed на FTP-транспорте)
    • EDIINT AS4 (на основе WebServices)
Форматы
  • ANSI X.12
  • XML
  • Tradacoms
  • EDIFACT
  • Cefic - Химическая промышленность
  • GS1 EANCOM - Розничная торговля
  • EDIBDB - Строительство
  • EDIFICE - Высокотехнологичная промышленность
  • EDIFURN - Мебель
  • EDILEKTRO - Electro
  • EDILIBE - Книги
  • EDITEC - Санитарно-гигиеническое
  • EDITEX - Fashion
  • EDIFOR / EDITRANS - Транспорт и логистика
  • EDIWHEEL - Колеса Шины
  • ETIS - Телекоммуникации
  • STAR - Стандарты технологий в автомобильной рознице
  • SPEC2000 (авиационная промышленность) (внешняя ссылка )
  • FORTRAS - Транспорт и логистика
Форматы фиксированной длины
  • EURITMO
Форматы разделителей

Ссылки

Дополнительно чтение

  • Генгешвари, К. и Абу Бакар Абдул Хамид (2010). «Интеграция электронного обмена данными: обзор», Jurnal Kemanusiaan, ISSN 1675-1930

Внешние ссылки

Последняя правка сделана 2021-05-18 11:35:32
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте