Полезное

Типы edi сообщений. Что такое EDI? Степень риска при пользовании системой

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

Для чего предназначена такая форма связи?

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

Преимущества EDI

Система заказов EDI обладает рядом преимуществ:

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

Что гарантирует подлинность документации?

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

Пример расчета эффективности использования EDI

Каков же уровень эффективности EDI системы? Примеры расчета служат наглядным подтверждением.

Легко уточнить, какую численность разных соглашений по обмену надо заключить участвующим в конкретном случае:

Для шести участников применяется следующий расчет: N = 6 x (6-1)/2 = 15.
Для 100 сотрудничающих людей применим расчет: N = 100 x (100-1)/2 = 4450.

С возрастанием количества участников рост цифры возрастает экспоненциально.

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

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

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

Провайдеры EDI в России

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

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

Основной задачей ECR-Rus является применение технологий системы EDI не только в сфере среднего и малого бизнеса.

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

Обязательства провайдеров

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

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

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

Отличие отечественной модели пользования системой от европейской

EDI — система электронного обмена данными. Как работает эта схема в России? Пользование EDI в нашей стране в корне отличается от европейской и американской модели. В этих странах форма появилась в 70-е годы прошлого столетия, а у нас она внедрилась 20 лет спустя. Поэтому провайдерами предлагаются разные системы подключения, которые находятся в зависимости от уровня ИТ в компании, объема пересылаемой документации и коммуникативных средств. Это позволяет каждой компании решить свои проблемы оптимальным путем. Следует провести интеграцию своей учетной системы и стать обладателем веб-интерфейса, который обеспечит обмен документацией с партнерами по бизнесу.

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

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

Основные требования к сервисным провайдерам

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

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

Клиентские требования могут быть значительно шире, нежели основные положения, установленные ECR-Rus.

К примеру, для больших компаний нужны гарантии продолжительности обработки и доставки сообщений, которые исчисляются не минутами, а секундами. Предполагается, что одно сообщение будет отсылаться не более чем за 10—20 сек.

Основные требования к услугам провайдеров включают:

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

Степень риска при пользовании системой

Даже при наличии надежного поставщика услуг в сфере EDI, возможны некоторые внутренние изменения. К примеру, многие российские компании используют внутренние коды, не прибегая к употреблению GLN-кода.

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

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

Стоимость EDI

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

Что включено в инфраструктуру?

Инфраструктура включает dial-up, кабельные линии, сети. Интернет при развитии электронной сферы предлагал множество сетей открытого типа (BITNET, др.) и внутрикорпоративные специализированные сети (EDI-Express General Electric, IBM Information Exchange Network). Большое распространение получили сети Backbone, которые отличались высотой скорости.

Схема передачи

Транспортировка осуществляется посредством e-mail, соединения Telnet и HTTP. Остальными распространенными протоколами являются SMTP, POP3 (ISP), IMAP, HTML.

EDI может обеспечить транзакции и без использования общепринятых протоколов. В европейских странах прямыми средствами соединения стали FTP (File Transfer Protocol) и EDIINT (EDI over the Internet), а также сети с дополнительными услугами VANs (Value-added Networks).

Также созданы два стандарта: AS1, позволяющий передавать EDI-документы через протокол стандарт AS2, служащий для передачи через HTTP.

Основные принципы применения системы EDI в Интернете посредством стандартов AS1 и AS2:

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

Основы XML

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

Как же было проведено реформирование системы? XML EDI был утвержден в начале 1998 года международной организацией W3C в качестве новой спецификации.

XML (Extensible Markup Language) стал основой для создания новых языков. Появилось и множество Web-серверов, использующих технологию XML для организации хранящейся на них информации.

Посредством XML можно дать описание целому классу объектов данных, которые получили название документов, ориентированных на конкретную предметную область. Система дает возможность определить, допустимо ли набирать тэги и их атрибуты.

XML дал возможность привлечь на электронный рынок клиентов среднего и малого бизнеса. Существующие в современном мире системы EDI стоят дорого (от 10 000 до 100 000 тыс долларов). Многим мелким компаниям они просто не по карману.

Представление и стандарты

Этот уровень подразумевает определение структуры данных посредством синтаксиса и семантики. Важный вопрос — создание стандартов при структуризации данных при помощи широко известных стандартов ANSI X.12, используемых в США, UNECE EDIFACT, применяемых в странах Европы и Азии.

ОАО "Режевской хлебокомбинат"

Раиса Рахимьянова, главный бухгалтер

Системой EDI.Контур мы стали пользоваться с марта 2014 года. Для нас было очень важным полноценное внедрение системы, т.к объем поставок за 2013 год составил 11714 тонн, что предполагает большую загрузку специалистов и внушительный объем документооборота. Прием заказов по EDI существенно облегчил труд, особенно это девочки ощущали, когда происходил сбой по какой либо причине (однажды сбой случился в одной торговой сети).

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

С техподдержкой (горячей линией) мы еще особо не сталкивались, а вот ребята из внедрения и наш менеджер просто умнички!

Максим Коржавин, руководитель отдела ИТ

Наш переход на ЭДО обусловился не какими-то выгодами, а жизненной необходимостью: федеральные сети трактуют свои условия игры. Только в процессе работы приходит понимание того, что ЭДО — это хороший помощник в бизнес-процессе. Чтобы действительно ощутить всю прелесть и мощь этого инструмента, надо провести интеграцию своей учетной системы с ЭДО. В нашей организации это пока невозможно в связи с переходом на новую учетную систему 1С. Потому мы довольствуемся веб-платформой. Так как ЭДО — сфера новая в России, мы можем участвовать в улучшении и доработке платформы. Но уже сейчас вырисовывается удобный инструмент для коммуникации с нашими партнерами. Перед тем, как прийти в Контур, наша дорожка прошла через других провайдеров ЭДО. Не будем о них ничего говорить. Скажем, что конечная наша остановка — EDI от СКБ Контур. И мы этим довольны. Активно работать с СКБ Контура по ЭДО начали в середине 2013 года. К концу года переключили всех наших партнеров (торговые сети) с других провайдеров на EDI.Контур. А после стали подключать новые ТС. Нам предстоит еще интеграция с 1С. Потому работать и работать. А Контур с помощью своих специалистов умеет делать эту работу довольно приятной и комфортной (за что им человеческое «спасибо»).

В самом начале был намечен план работ, и в течение всего времени мы четко следовали ему. Все проблемы решались на ходу и быстро. Все это делает СКБ Контур безоговорочным лидером среди других провайдеров. Специалисты СКБ Контур больше нас заинтересованы, чтобы у нас все работало, как часы. Ну и, конечно, цены на услуги Контура самые низкие (причем в разы).
Контур научит не бояться новшеств! Потому мы с большим интересом готовы дальше плодотворно сотрудничать с ними и быть первыми в использовании их новых продуктов.

Все отзывы
Торговая компания "Кредос"

Евгений Петренко, заместитель директора по развитию систем и технологий управления

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

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

В целом, я доволен взаимодействием с компанией СКБ Контур и результатами проекта по смене провайдера.

Дмитрий Нефедов, руководитель отдела ИТ

Посредством EDI.контур удалось автоматизировать обработку заказов и перейти на обмен юридически значимыми документами.
В нашей компании учет ведется в программе 1С. Важной при внедрении EDI была настройка адаптера 1С для прямой загрузки из EDI в 1С. Мы работали с несколькими провайдерами по EDI, и у нас были проблемы в настройке адаптера 1С. При первом знакомстве с предложением СКБ Контур мы довольно скептически отнеслись к заявленной автоматизации. Адаптер 1С мы получили бесплатно, тогда, как другие компании взимали за это отдельную плату. Поэтому мы решили к одной из торговых сетей подключиться через СКБ Контур. Результат нас очень порадовал.

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

Хочу отметить, что нам понравилась система работы с клиентами в СКБ. Можно позвонить своему менеджеру с любым вопросом. Менеджер всегда либо сам помогает, либо перенаправляет заявку другому специалисту. Также нас радует обратная связь. При закрытии любой заявки специалисты Контура всегда интересуются, все ли нас устраивает. Хочу сказать отдельное спасибо менеджеру Наталье Буториной.

ОАО "ПурагроУК"

Сергей Бурко, системный администратор

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

Надо сказать, у нас были свои «хотелки», которых не было в типовом варианте. Сотрудники СКБ Контур пошли нам навстречу и воплотили в жизнь все, о чем мы просили для удобства в работе. Более того, насколько я знаю, после эти доработки были включены в типовое решение, а значит пригодились не только нам. Отмечу, что специалисты по внедрению достаточно оперативно реагировали на мои просьбы.

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

Дмитрий Мамонтов, руководитель отдела внедрения бизнес систем

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

Сейчас СКБ Контур активно работает с поставщиками — за несколько месяцев уже более 10% неподключенных ранее поставщиков присоединились к EDI обмену. Удерживая такой темп, мы планируем в ближайшей перспективе полностью перевести на EDI все заказы магазинов Касторама.

Торговая сеть "Красное & Белое"

Яна Кокорина, руководитель департамента автоматизированных информационных систем

« Красное и Белое» с марта 2015 года работает с провайдером СКБ Контур, который предоставляет услуги в работе с электронным документооборотом.

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

Так же хотелось бы отметить оперативность решения запросов как организационных так и технических.

Медведева Анастасия, руководитель отдела по работе с клиентами

После перехода на EDI.Контур мы подключали одну сеть за другой. И нас устраивает уровень работы данного решения. Что касается уровня сервиса компании СКБ Контур, то я им довольна, поэтому систематически передаю на сопровождение наших ключевых клиентов.
Если говорить о преимуществах, то одно из первых — это то, что Контур быстрее, чем конкуренты настроил интеграцию в нашей 1С. Второе, не менее важное, — оперативность в решении наших вопросов. Третье — это клиентоориентированность Контура. За время нашего сотрудничества провайдер реализовали в своем модуле функции, которые были необходимы только нам. Четвертое — самостоятельность. Большая часть корректировок производится силами контуровских сотрудников с минимальным привлечением нашего IT -отдела.

Поэтому работу с Контуром я оцениваю на 5 из 5!

Концерн "Русский Холод"

В. А. Стойко, директор по ИТ ГК "Русский холод"

Хочу поблагодарить компанию ЗАО «ПФ «СКБ Контур» за оперативное внедрение EDI.Контур в филиалах нашей компании. Особенно хочу отметить профессиональный уровень подготовки коллектива и отдельно выразить благодарность менеджеру Владимиру Владимировичу Порохонько, который всегда откликается на обращения и успешно решает любой наш вопрос.

МПЗ "Доброгост"

Константин Стариков, системный администратор

В системе EDI мы работаем с торговыми сетями «Монетка», «X5 Retail Group », «Кировский», «Мегамарт», «Лента».

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

ООО ТД "Сыробогатов"

Куприянов Константин, программист 1С

Стоимость предоставляемых Контуром услуr ниже в сравнении с другими провайдерами, а гибкая тарифная сетка позволяет выбрать для каждой торговой сети подходящий тариф, исходя из объема документооборота. В данном сотрудничестве мы чувствуем баланс между универсальностью, скоростью и стабильностью работы модуля интеграции с товароучетной системой основанной на платформе 1С Предприятие 7.7. Любые возникающие вопросы, как при внедрении, так и при эксплуатации решаются максимально оперативно сотрудниками СКБ Контур, ни один вопрос не остается без ответа.

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 стандарт состоит из двух основных частей:

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

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

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~

EDI - это стандарт формата данных или протокол?

Форматы документов

Циклы (Loops) внутри документов

Нетехнический взгляд на 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 смешивает два типа стандартов: стандарты для коммуникаций и стандарты для форматирования бизнес данных. Современные тенденции прямо противоположны: стандарты должны быть независимы друг от друга (ортогональны), что позволяет смешивать их в любых сочетаниях.

Переход торговых организаций на электронный обмен данными при взаимодействии со своими контрагентами по поставке товара и его реализации имеет ряд неоспоримых преимуществ. Но при большом количестве контрагентов (по нашим оценкам - более 50 - 70) реализация механизмов электронного взаимодействия по схеме Peer-to-Peer (когда необходимо установить отдельный канал обмена с каждым из своих поставщиков/покупателей) силами самого торгово-сервисного предприятия требует значительных вложений в технические и организационные решения.

Сервис "1С:Сеть" позволяет предприятию использовать готовое решение и построить такую систему "под ключ" практически без первичных вложений. Сервис 1С:Сеть состоит из центра обработки данных - сертифицированного EDI-провайдера "1С:Сеть" - и механизмов электронного взаимодействия, поставляемых с типовыми торговыми конфигурациями. (аббревиатура EDI расшифровывается как Electronic Data Interchange - электронный обмен данными).

EDI-провайдер "1С:Сеть" адаптирован к российской бизнес-практике. С этой целью фирма "1С" использовала результаты работы межрегиональной общественной организации "Стандартизация Обмена Деловой Информацией" (СОДИ), собравшей крупнейших российских представителей розничного бизнеса, которая формализовала обычные для России бизнес-процессы обмена.

"1С:Сеть" поддерживает обмен документами для четырех бизнес-процессов:

обмен данными о товаре;
обмен коммерческими предложениями;
заказ товара, акцепт заказа;
поставка товара, накладная, акцепт накладной.

Подробно о подключении к сервису "1С:Сеть" см. .

Инфраструктура

Инфраструктура сервиса "1С:Сеть" включает несколько компонентов. Ее основа - Центр Обработки Данных (ЦОД), отвечающий высоким требованиям отказоустойчивости и производительности.

ЦОД размещен у одного из провайдеров связи первого уровня и снабжен:

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

Программное ядро ЦОД взаимодействует с клиентской частью при помощи Web-сервисов.

Оно осуществляет маршрутизацию сообщений EDI в формате CommerceML EDI между абонентами "1С:Сеть", реализует протокол гарантированной доставки и гарантирует последовательность доставки сообщений.

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

Преимущества EDI

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

Уменьшение числа ошибок, сокращение времени получения информации

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

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

Прямая экономия затрат

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

Низкие затраты при организации обмена с новым партнером

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

Возможность использования современных схем взаимодействия в цепочках поставок

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