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

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

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

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

Лариса Викторовна Белоусова, главный бухгалтер

К системе обмена электронными документами наша компания подключилась в ноябре этого года по требованию клиента — торговой сети «Монетка». При помощи специалистов Контура модуль EDI достаточно быстро был интегрирован в нашу товаро-учетную систему (1С).

Работа с модулем оказалась интуитивно понята и проста. Также сотрудники Контур. Ритейла доступно объяснили, как работать с модулем.

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

Все отзывы

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

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

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

Торговая марка "Кубанский молочник" (ОАО "Трест Южный сахар")

А. А. Прокопьев, начальник департамента ИТ

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

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

Со своей стороны надеемся на продолжение взаимовыгодного и эффективного сотрудничества с СКБ Контур.

Светлана Егорова, координатор проектов отдела по работе с клиентами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кафе-пекарня "Поль Бейкери"

Станислав Барышев, директор

С СКБ Контур по электронному документообороту мы работаем с декабря 2013. Не смотря на то, что пока подключено только несколько сетей, оценить результаты от перехода на электронные документы мы уже успели. Для максимально полной автоматизации всех бизнес-процессов представители провайдера предложили нам помощь в реализации интеграции с товароучетной системы SAP. Мы благодарны компании СКБ Контур и ее сотрудникам за плодотворное сотрудничество и высокое качество оказываемых услуг!

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

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

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

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

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

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

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

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

Я желаю компании СКБ Контур охватить все торговые сети, желающие взаимодействовать с поставщиками посредствам EDI!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EDI определяет пакеты для наборов документов, групп документов и самих документов/транзакций (Interchange , Group and Transaction /Document) . Пакеты ограничиваются соответственно ISA/IEA, GS/GE, ST/SE парами сегментов.
Замечание: Для иллюстрации я использую EDI X12 вариант стандарта, распространенный в Северной Америке. Другой вариант стандарта, EDIFACT, распространен в Европе и принципиально не отличается от X12.
Здесь представлен пример самых первых сегментов всех трех пакетов: ISA, GS и ST. Пример взят отсюда :

ISA*00* *00* *ZZ*RECEIVERID *12*SENDERID *100325*1113*U*00403*000011436*0*T*>~
GS*FA*RECEIVERID*SENDERID*20100325*1113*24712*X*004030~
ST*997*1136~

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

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

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

EDI пытается быть протоколом, именно поэтому мы видим эти элементы адресации, авторизации и запроса подтверждения. Я не знаю, как эту информацию можно сопоставить с OSI protocol layer model.
Но все же большая часть EDI стандарта посвящена форматам данных.

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

Внутри пакетов мы видим сами документы. Но мы не найдем стандарта для универсального, обобщенного документа. Стандарт определяет многочисленные форматы для всевозможных типов документов: для заказов, для накладных, для описей вложения… вы найдете небольшую часть из громадного списка стандартизованных документов.
EDI следует известному мифу: «Где-то там есть идеальный формат, который описывает все на свете сценарии. Мы обязательно найдем этот формат. Нам нужно просто добавлять новые сценарии и подстраивать старые.»
Как результат EDI стандартные документы (спецификации) чрезмерно сложные.
Возьмем один пример: Нам нужна накладная для небольшого местного книжного магазина. Мы нашли подходящую стандартную спецификацию, EDI 850, заказ на покупку (Purchase Order). На первый взгляд он выглядит чересчур детальным. Мы не будем покупать продукты питания, уголь, зерно, жидкие продукты, опасные продукты, медицинские препараты. Нам не нужны международные адреса. Мы не будем использовать службы срочной доставки. EDI спецификация описывает все эти возможные варианты, но в ней слишком много полей, которые мы никогда не будем использовать. Она чересчур сложна для нашего простого документа.
Существует много индустриальных (domain) стандартов, которые используются как своеобразные хранилища знаний. Но эти стандарты не используются как стандарты передачи данных. (Посмотрите , описывающую проблему индустриальных стандартов.)

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

Структура индивидуальных документов довольно проста. Документы составлены из серии сегментов, внутри которых находятся данные документов.
Но оказывается, что сегменты могут объединяться в группы или в повторяющиеся группы, так называемые циклы (loops ). Пикантность в том, что эти циклы абсолютно никак не выделены в документе. О наличии цикла мы можем прочитать в спецификации данного конкретного документа. Сегменты одинакового типа (с одинаковыми тэгами) могут располагаться как независимо, так и внутри циклов. Создать парсер, распознающий циклы (которые, повторяю, никак не отмечаются в документе), это довольно нетривиальная задача.
В XML и JSON такой проблемы не стоит, иерархические объекты или коллекции объектов любого уровня вложенности очень просто задаются с помощью открывающих и закрывающих тэгов, именованных или неименованных.
EDI попытался усидеть на двух стульях. С одной стороны, его документный формат похож на формат csv и удобен для представления табличных данных. С другой стороны, он пытался описывать иерархические объекты, и попытка эта окончилась очень неубедительно. Конечно, мы понимаем это сейчас, когда имеем перед глазами JSON. Но давайте вспомним, что EDI был сделан не для передачи табличных данных, а именно для передачи документов, структура которых именно иерархическая.

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

Для полной картины я все же перечислю некоторые из нетехнических особенностей EDI:

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

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

Контент страницы

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

X5 Retail Group - лидер отечественного ритейла по внедрению электронного обмена данными. Применение EDI в работе ускоряет процесс поставки товаров в торговые сети.

X5 - лидер в области EDI

X5 Retail Group является лидером рынка розничной торговли по внедрению новых типов EDI-документов (электронный обмен данными) и ежедневному объёму электронного документооборота. Внедрение автоматического обмена счетами-фактурами стало ещё одним шагом к повышению качества взаимного сотрудничества, упрощению и увеличению скорости работы с поставщиками.

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

Сегодня в обмене электронными счетами-фактурами принимают участие EDI-провайдеры, подписавшие с X5 Retail Group «Соглашение об уровне сервиса по предоставлению услуг электронного обмена данными»: ООО «ФораПром» (платформа LERADATA), ООО «Сислинк» (платформа CISLink), ООО «Электронные Коммуникации» (платформа «EVOLUTION-3.0»), ООО «Корус Консалтинг СНГ» (платформа СФЕРА), ЗАО «ПФ «СКБ Контур» (платформа EDI.КОНТУР) и ООО «Эдисофт» (платформа EDISOFT). Провайдеры ООО «ООО «Электронные Коммуникации»» (платформа «EVOLUTION-3.0») и ООО «ФораПром» (платформа LERADATA) - сертифицированные ECR-Russia и уполномоченные Х5 Retail Group EDI-провайдеры, которые имеют партнёрские отношения с доверенными операторами электронного документооборота ФНС России - ООО «Калуга-Астрал» и ООО «Систем Групп Рус », которые позволят легитимно передавать электронные счета-фактуры (входящие и исходящие) от поставщиков в Х5 Retail Group и обратно.

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

Что EDI может предоставить поставщикам

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

Основные выгоды от внедрения системы электронного обмена данными:

№	Тип EDI документа	Выгоды от внедрения EDI документа
1	Уведомление об участнике обмена (PATRIN)	Ежедневное автоматическое уведомление об актуальных объектах Х5
2	Ценовые спецификации (PRICAT)	Автоматизированный процесс обмена юридически значимыми ценовыми спецификациями в электронном виде. Позволяют сократить время согласования цен, исключить задержки и ручные ошибки, обмен бумажными документами, их обработку и хранение
3	Заказ покупателя поставщику (ORDERS)	Оперативная и автоматизированная передача заказов Х5 поставщикам, техническая поддержка, контроль и мониторинг передачи заказов
4	Ответ поставщика на Заказ покупателя (ORDRSP)	Подтверждение поставщиком обязательств по поставке. Сокращение запасов и (или) дефицита товаров в магазинах сети. Учёт товара поставщика «в пути» - снижение риска перепоставок и (или) отказа в приемке товара
5	Уведомление поставщика об отгрузке поставки покупателю (DESADV) - электронная накладная	Ускорение процесса приёма (передачи) поставки в магазинах и в РЦ сети. Снижение ошибок ручного труда сотрудников Х5 и поставщиков во время приёмки и, в дальнейшем, во время оплаты: автоматическая идентификация поставки и SAP заказа Х5, автоматическая идентификация приёмки Х5 и ЭСФ поставщиков Информационное письмо и презентация проекта
6	Уведомление покупателя о приёмке (RECADV) - электронный акт приемки	Ускорение процесса формирования корректных счетов-фактур со стороны поставщиков. Снижение количества неотфактурованных поставок
7	Уведомление о возврате товара (RETDES) и уведомление о приёмке возврата (RETREC)	Оперативное и документальное подтверждение произведённого со стороны Х5 возврата товаров, ускорение процесса сверки бухгалтерских балансов, повышение прозрачности и контроля процессов возврата товаров
8	Акт сверки взаиморасчётов с контрагентами (COACSU)	Автоматизация и ускорение (своевременность, актуальность) процесса сверки дебиторской и кредиторской задолженности с поставщиками
9	Уведомление о выявленных недостатках, связанных с ненадлежащим качеством Товара	Автоматизация и ускорение (своевременность, актуальность) документооборота с поставщиками по штрафам ФРОВ. Т олько в случае, если Поставщик является Поставщиком ФРОВ.

Как присоединиться к обмену электронными документами с X5

В X5 Retail Group разработаны основные шаги, позволяющие поставщикам присоединиться к системе обмена электронными документами.

1-й шаг

Поставщику необходимо заключить с Х5 Retail Group дополнительное соглашение по EDI к договору поставки с обязательным заполнением Приложения к доп. соглашению - заявки на организацию обмена электронными документами между поставщиком и покупателем. Шаблоны документов можно получить в коммерческой дирекции Х5 Retail Group или у сотрудников договорного отдела Х5.

2-й шаг

Заключить договор на оказание услуг электронного обмена данными с EDI-провайдером. Компаниям, которые уже имеют договор с EDI, необходимо направить письмо своему EDI-провайдеру о необходимости организации электронного обмена с Х5 Retail Group. Получить от EDI-провайдера параметры доступа на его web-EDI-страницу или провести совместную интеграцию своей учётной системы и системы EDI-провайдера.

3-й шаг

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

4-й шаг

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

5-й шаг

Обратиться к EDI-провайдеру с письмом о проведении тестов и провести тестовые обмены EDI-документами.

Вебинары X5

30 августа 2017 года состоялся вебинар для поставщиков Х5, посвященный вопросам перехода с юридически-значимого документооборота бумажной версии ценовой спецификации на электронную (EDI PRICAT).

29 июня 2017 года состоялся вебинар, посвященный вопросам использования электронного УПД в юридически-значимом электронном документообороте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(включая 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, не используются при обмене все виды основных документов. – накладные и счета фактуры. Кроме того, не используется электронная подпись.