Как настроить обмен электронными документами (ЭДО и EDI) с торговыми сетями в 1С:УПП?

← На главную

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

Главное отличие: EDI против ЮЗДО (ЭДО)

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

EDI (Electronic Data Interchange — электронный обмен данными):
Это оперативный, технологический обмен сообщениями, сопровождающий цепочку поставки от момента заказа до фактического получения товара на складе покупателя. Документы EDI в России, как правило, юридически не значимы. Они передаются в виде стандартных XML-файлов (международный стандарт EDIFACT) без использования электронной подписи (КЭП). Эти документы нужны для того, чтобы информационные системы поставщика и покупателя понимали друг друга мгновенно и без ручного ввода данных. Сюда входят сообщения:
- ORDERS — заказ на поставку от торговой сети;
- ORDRSP — подтверждение заказа от поставщика (что и в каком объеме мы готовы привезти);
- DESADV — уведомление об отгрузке со склада поставщика (содержит информацию о машине, водителе и конкретных товарных позициях);
- RECADV — уведомление о приемке товара на складе торговой сети (в нем фиксируются расхождения, вычерки и излишки).
ЮЗДО (Юридически значимый документооборот, часто называемый просто ЭДО):
Это обмен официальными первичными документами, которые принимаются Федеральной налоговой службой (ФНС) для подтверждения расходов и вычетов по НДС. Здесь используются исключительно утвержденные форматы ФНС, документы подписываются квалифицированной электронной подписью (КЭП) и передаются строго через сертифицированных операторов электронного документооборота (СЭД). Ключевой документ здесь — УПД (Универсальный передаточный документ) или связка ТОРГ-12 и Счет-фактура.

Стандартный сервис 1С-ЭДО, встроенный в типовую конфигурацию 1С:УПП, предназначен исключительно для ЮЗДО. Он отлично подходит для обмена актами, договорами или УПД с обычными контрагентами (поставщиками услуг, материалов). Однако он абсолютно не умеет работать с логистическими EDI-сообщениями (такими как ORDERS или DESADV), которые являются обязательным условием работы практически любой крупной торговой сети (X5 Group, Магнит, Лента, Ашан).

Почему встроенный функционал 1С-ЭДО не подходит для работы с ритейлом

Выделим основные причины, по которым использовать штатную кнопку ЭДО в 1С:УПП при работе с розничными сетями нецелесообразно и технически сложно:

Отсутствие поддержки EDI-стандартов: В типовой конфигурации 1С:УПП нет объектов для хранения и обработки сообщений ORDERS, ORDRSP, DESADV. Нам просто некуда загрузить заказ покупателя из XML-формата сети без написания собственной сложной подсистемы.
Проблема производительности при высоких нагрузках: Крупный поставщик может отправлять и принимать сотни и тысячи пакетов документов в сутки. Встроенный механизм ЮЗДО в УПП не рассчитан на массовую автоматическую отправку и подписание документов в фоновом режиме ("роботом") без непосредственного участия пользователя.
Сложный процесс обработки расхождений: При приемке товара сеть часто делает вычерки (например, из-за боя или недовоза). В этот момент возникает необходимость оперативного выставления корректировочных документов (УКД). Штатный механизм требует ручного создания документов исправления, что парализует работу операторов при больших объемах.

Технологические вызовы: Ограничения 1С:УПП, МЧД и маркировка

Помимо архитектурных особенностей EDI, при внедрении интеграции в 1С:УПП необходимо учитывать несколько критических внешних факторов:

Прекращение поддержки конфигурации 1С:УПП: Фирма «1С» официально заявила о прекращении поддержки УПП в апреле 2027 года. Это означает, что инвестировать огромные ресурсы в разработку собственного уникального функционала EDI внутри УПП экономически нецелесообразно. При переходе на современные ERP-решения (например, 1С:ERP) весь этот самописный код придется выкинуть. Логичнее использовать внешние отчуждаемые решения.
Машиночитаемые доверенности (МЧД): Согласно законодательству РФ, сотрудники организации, подписывающие документы от лица компании своей личной КЭП физического лица, обязаны прикладывать к пакету документов МЧД в формате XML. Устаревшая платформа УПП требует регулярного обновления Библиотеки электронного документооборота (БЭД) для корректной работы с МЧД. Внешние модули операторов берут работу с МЧД на себя, избавляя программистов от необходимости постоянно обновлять код конфигурации.
Маркировка «Честный Знак»: Если вы поставляете маркированный товар (молоко, вода, легкая промышленность), коды маркировки должны бесшовно передаваться внутри XML-файла УПД через оператора ЭДО. Внешние интеграционные модули EDI-провайдеров уже содержат встроенные инструменты сканирования, агрегации и сопоставления кодов маркировки с информационной системой ГИС МТ.

Как работают внешние модули интеграции от EDI-провайдеров

Для решения описанных проблем ведущие EDI-провайдеры (такие как Контур, СБИС/Тензор, Корус Консалтинг) предлагают готовые внешние интеграционные модули для 1С:УПП. Эти модули представляют собой внешние обработки (иногда с минимальным внедрением в конфигурацию в виде расширений или дополнительных регистров), которые реализуют концепцию "Единого окна".

Рассмотрим по шагам типичный автоматизированный бизнес-процесс работы через такой модуль:

Получение заказа (ORDERS): Модуль по расписанию обращается к серверу EDI-провайдера, забирает XML-файл заказа от торговой сети, автоматически сопоставляет номенклатуру сети (по штрихкоду GTIN или артикулу) с вашей номенклатурой в 1С:УПП и создает документ ЗаказПокупателя в статусе "Согласован".
Подтверждение заказа (ORDRSP): Менеджер склада проверяет наличие остатков на складе. Модуль анализирует заполнение заказа и автоматически формирует ответ ORDRSP, отправляя его обратно в сеть. Ритейлер заранее знает, какие позиции приедут, а каких не будет.
Уведомление об отгрузке (DESADV): При проведении документа РеализацияТоваровУслуг в 1С:УПП модуль считывает данные о фактической отгрузке (веса, объемы, паллеты, данные водителя и машины) и отправляет в сеть сообщение DESADV. На его основе сеть готовит свои склады к приемке.
Приемка и фиксация расхождений (RECADV): Когда машина приезжает в сеть, товар сканируется. Покупатель отправляет сообщение RECADV. Модуль в вашей 1С загружает это сообщение и автоматически сопоставляет его с исходной реализацией. Если есть вычерки, модуль сразу подсвечивает расхождения.
Юридический документ (УПД): На основании подтвержденных данных из RECADV модуль позволяет в один клик сформировать чистый УПД без расхождений, автоматически подписывает его КЭП с прикреплением МЧД и отправляет его через ЮЗДО. Сеть мгновенно принимает этот документ на баланс.

Реализация сопоставления номенклатуры в 1С:УПП (Пример кода)

Для того чтобы внешние модули EDI могли автоматически создавать документы в вашей системе, критически важно настроить сопоставление номенклатуры покупателя с номенклатурой вашей базы. Сети обычно оперируют международными кодами GTIN. Рассмотрим пример функции, которая позволяет найти внутреннюю номенклатуру и характеристику в 1С:УПП по входящему штрихкоду GTIN:


Функция НайтиНоменклатуруПоGTIN(Знач ТекущийGTIN) Экспорт
    
    // Проверим корректность входных данных
    Если ПустаяСтрока(ТекущийGTIN) Тогда
        Возврат Неопределено;
    КонецЕсли;
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ РАЗРЕШЕННЫЕ
        |	Штрихкоды.Владелец КАК Номенклатура,
        |	Штрихкоды.ХарактеристикаНоменклатуры КАК Характеристика
        |ИЗ
        |	РегистрСведений.Штрихкоды КАК Штрихкоды
        |ГДЕ
        |	Штрихкоды.Штрихкод = >IN";
    
    Запрос.УстановитьПараметр("GTIN", СокрЛП(ТекущийGTIN));
    
    РезультатЗапроса = Запрос.Выполнить();
    
    Если Не РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        
        СтруктураНоменклатуры = Новый Структура;
        СтруктураНоменклатуры.Вставить("Номенклатура", Выборка.Номенклатура);
        СтруктураНоменклатуры.Вставить("Характеристика", Выборка.Характеристика);
        
        Возврат СтруктураНоменклатуры;
    КонецЕсли;
    
    Возврат Неопределено;
    
КонецФункции

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