EDI-сообщения: ORDERS, ORDRSP, DESADV, RECADV, INVOIC и порядок обмена

·12 мин чтения· обновлено
EDI-сообщения: ORDERS, ORDRSP, DESADV, RECADV, INVOIC и порядок обмена
Содержание 12

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

Что такое EDI-сообщение#

Это не письмо и не файл с таблицей произвольной формы. EDI-сообщение — структурированный набор полей, оформленный по стандарту, установленному организацией GS1. В нём нет свободного текста: товар идентифицируется кодом, партнёр — идентификатором, количество и цена — числами в отведённых полях.

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

Пяти основным сообщениям соответствуют пять этапов поставки.

Пять основных сообщений#

СообщениеЭтапЧто содержит
ORDER или ORDERSЗаказ на поставкуСписок товаров, их количество, цены, сроки и адрес доставки. Формирует покупатель — например, торговая сеть — и отправляет поставщику
ORDRSPОтвет на заказПоставщик подтверждает заказ, отказывает от него, предлагает аналог или вносит корректировки
DESADVУведомление об отгрузкеАналог товарно-транспортной накладной. Количество отгруженного, цена, отправитель, получатель
RECADVСообщение о приёмке товараПокупатель сообщает, что принял. Фактически принятый товар и расхождения, если часть не принята
INVOICE или INVOICСчётОкончательные данные по поставке, цены и суммы к оплате

Порядок, в котором они идут#

Цепочка стандартная, и её стоит знать наизусть — по ней видно, на каком шаге обмен встал.

ШагЧто происходитСообщение
1Покупатель высылает поставщику заказORDER
2Поставщик корректирует заказ по реальным остаткам на складе и подтверждаетORDRSP
3После отгрузки поставщик уведомляет покупателяDESADV
4Покупатель принимает товар и сообщает, что принял, а что нетRECADV
5Поставщик на основании приёмки формирует счётINVOICE

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

Ещё две особенности, которые видны из цепочки.

ORDRSP — не формальность. Ответ на заказ может содержать отказ или замену на аналог, если нужного товара нет на складе. В этом сообщении решается, состоится поставка или она сдвинется.

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

RECADV — почему его ищут чаще всего#

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

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

Понять, зачем оно нужно, проще всего на примере. Сеть заказала 100 единиц. Поставщик отгрузил 100, из них 6 оказались с повреждённой упаковкой. Без RECADV поставщик узнает об этом только из акта сверки или вообще не узнает. С ним — расхождение фиксируется в момент, когда товар принят, и является основанием для счёта по факту.

Почему приёмку принимают почти все торговые сети. Приёмка есть в любой поставке — без неё не закрывается ни одна сделка. Сообщение об отгрузке тоже нужно большинству сетей, а вот прайс-лист или график поставок некоторым не нужны вовсе. По опубликованной таблице наборов сообщений приёмку принимают METRO, Лента, Магнит, «О’КЕЙ» и Золотое Яблоко — пять сетей из шести. Единственная в списке без приёмки — Ozon, а это маркетплейс, где приёмка организована иначе.

Не путайте RECADV с отказом. Отказ — это когда товар не принят и покупатель сообщает об отказе от части заказа. RECADV шире: в нём фиксируется, что именно принято, а что нет. Это разные ситуации с разными последствиями для расчётов.

Написание сообщений у разных сетей различается#

Это деталь, которая регулярно ставит в тупик, и она неочевидна.

В одном и том же справочнике типы названы ORDER и INVOICE, а в таблице по торговым сетям — уже ORDERS и INVOIC. Это не опечатка. Названия идентификаторов закреплены за каждой сетью, и смысл у них один, а написание разное.

Ниже — таблица наборов сообщений по шести сетям из справочной базы Контур.EDI.[1] Это не исчерпывающий перечень: у каждой сети своя схема, и у крупных их больше, чем здесь указано.

СетьТипы сообщений
METROPRICAT, ORDERS, DESADV, RECADV, INVOIC
ЛентаORDERS, DESADV, INVOIC, RECADV, COINVOIC, RETANN
МагнитPRICAT, ORDERS, DESADV, INVOIC, RECADV, COINVOIC
«О’КЕЙ»ORDERS, DESADV, RECADV, INVOIC
Золотое ЯблокоORDERS, ORDRSP, DESADV, RECADV
OzonORDERS, ORDRSP, INVOIC, COINVOIC

Что видно из таблицы, чего не видно из общего списка:

СообщениеГде встречается в этом списке
ORDERSВсе шесть
DESADVПять из шести
RECADVПять из шести
INVOICПять из шести
ORDRSPДва из шести
PRICATДва из шести
COINVOICТри из шести
RETANNОдно — только Лента

Три практических вывода.

Сверяйте написание с той сетью, с которой идёт обмен. Настроенная схема под METRO не сработает для сети, у которой закреплено INVOICE, и наоборот.

ORDER и ORDRSP есть не у всех. У METRO, Ленты, Магнита и «О’КЕЙ» в списке нет ORDRSP — то есть подтверждения заказа в их схеме не предусмотрено. Планировать процесс подтверждения надо под конкретного партнёра.

RETANN у Ленты — единичный случай. Сообщение возврата, по которому в таблице опубликована только одна сеть. Рассчитывать на него как на универсальный нельзя.

Что бывает, кроме пяти основных#

Перечень дополнительных сообщений, который можно настроить под свои нужды:[1]

  • Уведомление о возврате и приёмка возврата. Обратный процесс: товар едет назад, и это тоже оформляется сообщением
  • Сообщение об отгрузке алкоголя. Отдельный тип, связанный с подакцийными документами
  • Сведения о местах доставки. Адреса, по которым развозить
  • Прайс-лист. Условия и цены
  • График поставок. Когда и что привозить
  • Отчёт о продажах. Данные о реализации в сети

PRICAT и COINVOIC отдельно стоит назвать, потому что их регулярно ищут.

PRICAT — сообщение с прайс-листом, передаваемым в сторону поставщика, чтобы тот знал актуальные цены. Встречается в списке только у METRO и Магнита, то есть это не универсальное сообщение, а особенность отдельных сетей. Искать его в общем списке бессмысленно: если ваша сеть его не использует, настраивать нечего.

COINVOIC — совместный или комбинированный счёт. Встречается у Ленты, Магнита и Ozon. Смысл в том, что счёт формируется не поставщиком в одиночку, а с участием обеих сторон. Там, где он есть, пятый шаг цепочки выглядит иначе: поставщик не присылает свой INVOIC, а стороны формируют общий счёт.

От сообщения к документу#

Отдельно надо сказать, где заканчивается EDI и начинается электронный документооборот.

На основе INVOIC формируются электронные документы: счёт-фактура или универсальный передаточный документ. Здесь граница проходит по юридической значимости.

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

Одно уточнение, важное с 1 января 2026 года. Электронный формат товарной накладной по форме ТОРГ-12 и электронный формат акта выполненных работ прекратили применяться: приказ ФНС России от 20.01.2025 № ЕД-7-26/28@ признал утратившими силу приказ от 30.11.2015 № ММВ-7-10/551@ и приказ от 30.11.2015 № ММВ-7-10/552@, и приказ вступает в силу с 1 января 2026 года.[2] Значит, в электронном обороте отгрузочный документ — это УПД, а не накладная. Бумажные формы накладной и акта при этом действуют.

Практический смысл. Если вы работаете с маркированным товаром, то документом на основе INVOIC будет УПД с кодами маркировки, и его передача идёт уже в другой системе — через оператора электронного документооборота либо через бесплатный сервис в системе маркировки.[3] То есть один и тот же пятый шаг цепочки заканчивается либо счётом-фактурой, либо УПД с кодами идентификации, и какой именно документ получится, зависит от товара.

Что даёт приём заказов через EDI#

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

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

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

Ответы на частые вопросы#

RECADV — что это? Сообщение о приёмке товара, которое покупатель отправляет продавцу. Содержит фактически принятый товар и расхождения, если часть не принята. Основание для расчётов по поставке.

INVOICE — что это в EDI? Счёт. Окончательные данные по поставке, цены и суммы к оплате. Формируется поставщиком на основании фактической приёмки. На его основе в системе электронного документооборота создаются счёт-фактура или УПД.

PRICAT — что это? Сообщение с прайс-листом, передаваемым поставщику. Встречается у отдельных сетей, в частности у METRO и Магнита, и не является универсальным.

ORDERS и ORDER — одно и то же? По смыслу да, по написанию нет. Разные сети закрепили за заказом разные идентификаторы. Настраивать нужно тот, который закреплён за вашей сетью.

DESADV — это накладная? Это сообщение об отгрузке, аналог товарно-транспортной накладной по содержанию, но не документ. Юридической силы у него нет.

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

Итог#

EDI-сообщение — структурированный набор полей по стандарту GS1, который читает система, а не человек. В нём нет свободного текста, и в этом его сила.

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

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

RECADV ищут чаще всего, и это не случайно: приёмка есть в любой поставке, её принимают пять сетей из шести опубликованных. Единственная без приёмки — Ozon, где приёмка организована иначе.

Написание у сетей различается. ORDERS и ORDER, INVOIC и INVOICE — один смысл, разные идентификаторы. Сверять надо с конкретной сетью.

Не все сообщения универсальны. ORDRSP нет у четырёх сетей из шести, PRICAT встречается у двух, RETANN — у одной. COINVOIC означает, что счёт формируется с участием обеих сторон, и там пятый шаг выглядит иначе.

Пятый шаг заканчивается документом: из INVOIC формируется счёт-фактура или УПД. Для маркированного товара это будет УПД с кодами маркировки, и он пойдёт уже через электронный документооборот. Электронной товарной накладной ТОРГ-12 в этом перечне с 1 января 2026 года нет — её формат отменён.


Ещё по теме#

Источники#

  1. 1

    Справочная база Контур.EDI, статья «Отличие EDI от ЭДО»: типы EDI-сообщений с описанием состава каждого — заказ на поставку с перечнем сведений, ответ на заказ с вариантами подтверждения, отказа, аналога и корректировок, уведомление об отгрузке как аналог товарно-транспортной накладной, сообщение о приёмке товара со сведениями о фактически принятом и расхождениях, счёт с формированием на его основе электронных документов; типовая цепочка обмена из пяти сообщений; указание, что цепочку можно дополнить другими сообщениями в зависимости от договорённостей партнёров и бизнес-процессов, с перечислением дополнительных сообщений — возврат и приёмка возврата, отгрузка алкоголя, сведения о местах доставки, прайс-лист, график поставок, отчёт о продажах; таблица торговых сетей с наборами сообщений, включая написание ORDERS, INVOIC, COINVOIC и RETANN; пояснение, что заказ формируется прямо в учётной системе покупателя и поэтому не содержит ошибок и опечаток; вывод о том, что EDI-сообщения не являются юридически значимыми и служат основой для формирования закрывающих документов. Подсчёт частоты сообщений в таблице шести сетей выполнен по данным этой таблицы.

    ↩
  2. 2

    Приказ ФНС России от 20.01.2025 № ЕД-7-26/28@ «О признании утратившими силу приказов ФНС России от 30.11.2015 № ММВ-7-10/551@… и от 30.11.2015 № ММВ-7-10/552@…», опубликован на официальном сайте налоговой службы. Пункт 1 признаёт утратившими силу два приказа: от 30.11.2015 № ММВ-7-10/551@ «Об утверждении формата представления документа о передаче товаров при торговых операциях в электронной форме», зарегистрированный Минюстом России 25.12.2015 под регистрационным номером 40258, и от 30.11.2015 № ММВ-7-10/552@ «Об утверждении формата представления документа о передаче результатов работ (документа об оказании услуг) в электронной форме», зарегистрированный Минюстом России 25.12.2015 под регистрационным номером 40288. Пункт 2 дословно: «Установить, что настоящий приказ вступает в силу с 01.01.2026». Формат универсального передаточного документа приказом не затронут.

    ↩
  3. 3

    Обзор сервиса ЭДО Лайт государственной системы маркировки, раздел руководства пользователя о составе документов: УПД и УКД как форматы, утверждаемые налоговой службой, и их исправленные версии; счёт-фактура с первичным документом; первичный документ; состав документов, передаваемых сервисом.

    ↩
  4. 4

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

    ↩