Администрирование

Типы edi сообщений. Что такое EDI. Основные преимущества технологии

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

ORDERS (Purchase Order)

ORDERS - сообщение «Заказ на поставку», которое заказчик отправляет поставщику, содержащее перечень заказываемых товаров (услуг), количество, цены, даты и адреса доставки. Данное сообщение могут использовать торговые сети, производители, склады, поставщики сырья, перевозчики и др.

ORDRSP (Order Response)

ORDRSP - сообщение «Ответ на заказ», при помощи которого поставщик подтверждает или не подтверждает поставку той или иной товарной позиции. Использовать данное сообщение может как поставщик торговой сети, так и дистрибьютор, обменивающийся документами EDI с производителем.

DESADV (Despatch Advice)

DESADV - сообщение «Уведомление об отгрузке», содержащее полную информацию об отгрузке: размер, вес, параметры транспортного средства, количество и наименование товара, данные грузополучателя и грузоотправителя, уникальный номер отгрузки и др. Внедрение DESADV даёт возможность запланировать приёмку товара.

RECADV (Receiving Advice)

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

INVOIC

INVOIC - сообщение «Счёт-фактура», содержащее информацию для автоматического формирования электронного счёта-фактуры (ЭСФ) в формате ФНС. При подписании ЭСФ электронной цифровой подписью документ становится юридически значимым.

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

Преимущества от внедрения электронного обмена данными

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

Для внедрения EDI необходимо, чтобы все предприятия-участники торговли имели международный идентификационный номер – GLN , а каждый товар должен иметь глобальный номер GTIN в международной системе EAN (GS1).

GTIN (Global Trade Item Number , раньше EAN) — международный код (штрихкод) маркировки и учёта товара, например, товар, упаковка, оригинальная паллета.

Типы документов (EDI-сообщения)

ORDERS (ЗАКАЗ НА ПОСТАВКУ ТОВАРА) — электронное сообщение, которое является аналогом заказа на поставку продукции. Формируется и отправляется покупателем поставщику.

ORDRSP (ПОДТВЕРЖДЕНИЕ ЗАКАЗА) — электронное сообщение, в котором поставщик подтверждает, корректирует или отклоняет поставку по каждой товарной позиции. Отправляется поставщиком покупателю.

DESADV (УВЕДОМЛЕНИЕ ОБ ОТГРУЗКЕ) — электронное сообщение, которое является аналогом накладной. Данное сообщение формируется в момент (или до) отправки товара поставщиком. В данном сообщении указывается фактическое (отгруженное) количество и ассортимент товара поставляемого покупателю.

RECADV (УВЕДОМЛЕНИЕ О ДОСТАВКЕ) — электронное сообщение, в котором содержится информация о фактически принятом товаре, так же в нем может содержаться информация о причинах не приемки товара. Данное сообщение формируется на момент (или после) приемки товара покупателем.

INVOIC (СЧЕТ-ФАКТУРА) — электронное сообщение, которое является аналогом бумажной счет-фактуры.

PRICAT (КАТАЛОГ ТОВАРОВ) — электронное сообщение, которое содержит информацию о товарах и их ценовых характеристиках. Данное сообщение формируется поставщиком при изменении цены, ассортимента.

PROINQ (ЗАПРОС ПРАЙС-ЛИСТА) — электронное сообщение, которое содержит информацию о поставщике и/или товарах, по которым необходимо получить информацию (прайс-лист). Отправляется покупателем по мере необходимости получения информации о товарах.

COACSU (АКТ СВЕРКИ ВЗАИМОРАСЧЕТОВ) — электронное сообщение, которое является аналогом бухгалтерского документа "Акт сверки взаимных расчетов".

COMDIS (КОММЕРЧЕСКАЯ ДИСКУССИЯ) — электронное сообщение, которое содержит информацию о несоответствии количества, цен, ставок НДС. Отправляется покупателем при обнаружении в счёт-фактуре (INVOIC) несоответствий.

SLSRPT (ОТЧЕТ О ПРОДАЖАХ) — электронное сообщение, которое содержит информацию о проданных товарах. Отправляется покупателем по мере необходимости получения информации о проданных товарах.

INVRPT (ОТЧЕТ ОБ ОСТАТКАХ) — электронное сообщение, которое содержит информацию об остатках товара у покупателя. Отправляется покупателем при необходимости получения информации об остатках товара.

Что такое электронная цифровая подпись?

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

Использование цифровой подписи позволяет осуществить:

контроль целостности передаваемого документа,
защиту от изменений (подделки) документа,
невозможность отказа от авторства,
доказательное подтверждение авторства документа.

(включая 1С-Такском) На сайте, кроме общих фраз и слов, я ничего интересного не нашел – нет никакой документации или статьи о сущности нового стандарта. Можно просто догадываться, что у них есть база потенциальных покупателей, которые они называют торговыми партнерами или торговыми сетями. На языке CRM -систем это Лид (lead, целевой лид ) - потенциальный клиент, тем или иным образом отреагировавший на маркетинговую коммуникацию) Эти Лиды, каким- то непонятным образом передают на сервер сайта информацию об ассортименте и точках доставки. Как Лиды обмениваются с сервером сайта мне не понятно и никакой информации сайт не предоставляет посетителям.

Для поставщиков разработали интеграционный модуль Электронного документооборота 1EDI.RU (далее 1EDI-ЭДО) для платформы 1С предприятие 8.2 в виде внешней обработки, которая соединяется с сервером сайта и могут получить заказы электронным путем от лидов сайта (торговые партнеры по терминологии сайта). Я не знаю, разработаны ли подобные интеграционные модули для прикладных решений 1С на платформе 8.3? . Об этом на сайте ничего не говорится.

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

Для работы с этой обработкой (или с интеграционным модулем 1EDI-ЭДО на платформе 8.2) , на компьютере должен быть установлен Microsoft Core XML Services (MSXML) 6.0. Скачать дистрибутив можно, например, по ссылке: https://www.microsoft.com/en-us/download/details.aspx?id=3988

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

На картинке показана форма настройки торговых партнеров. В данном окне необходимо настроить две колонки:

Работает – работаете ли вы с данным торговым партнёром
Организация 1С – необходимо выбрать от имени какой организации будет вестись документооборот.

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

Самое утомительное – это синхронизация номенклатуры базы данных поставщика с номенклатурой торгового партнера, с которым поставщик работает. Форма синхронизации номенклатуры вызывается при нажатии кнопки «Сопоставлять объекты»

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

В этом новом объявленном стандарте EDI -ЭДО, поставщик может обрабатывать следующие документы EDI

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

Документ EDI «Ответ на заказ» – Электронное сообщение, которое отправляется поставщиком торговому партнеру (покупателю). Ответ на заказ может содержать полное согласие с заказом, частичное согласие с заказом (можно уменьшить количественную часть номенклатуры), в отдельных случаях ответ на заказ помимо прочего содержит цены номенклатуры для данного покупателя. Этот документ EDI «Ответ на заказ» является полным отражением документа 1С который был создан на основание Документа EDI «Заказ»

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

ЗАКЛЮЧЕНИЕ

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

Судя по обработке для УТ 10-3, не используются при обмене все виды основных документов. – накладные и счета фактуры. Кроме того, не используется электронная подпись.

Разработка систем связи

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 по-прежнему широко используется.
В следующей части мы постараемся найти этому причины. Скорее всего они будут не технического характера.

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