EDI-сообщения: ORDERS, DESADV, RECADV, INVOIC и другие форматы поставки

Торговая сеть прислала заказ, вы отправили товар, сеть его приняла. Звучит просто, но в электронном обмене это не один документ, а целый набор: ORDERS, ORDRSP, DESADV, RECADV. Каждое сообщение — свой этап цикла, свой формат, свои грабли. Разбираем, что отправляет кто и в какой момент, что внутри каждого сообщения, и как читать ошибки, когда что-то пошло не так.

Коротко о главном

EDI-сообщения — это стандартные электронные документы, которые ходят между поставщиком и сетью на каждом этапе поставки. Сеть шлёт заказ (ORDERS), вы подтверждаете его (ORDRSP), отправляете уведомление об отгрузке (DESADV), сеть уведомляет о приёмке (RECADV). Вдобавок ходят ценовые листы (PRICAT), уведомления об отгрузке алкоголя (ALCRPT) и счета (INVOIC).

Все эти форматы — не выдумка Контура, а международные стандарты ООН, которые Россия адаптировала под свои нужды. Любой EDI-провайдер (Контур.EDI, Диадок, СБИС и другие) подерживает один и тот же набор сообщений. Разница только в интерфейсе и в том, кого вы считаете своим провайдером.

Главное: сообщение — не значит можно игнорировать. Если ошибка в формате, сеть её не примет, и товар зависнет на складе. Если опоздали с отгрузкой, сеть видит это по датам в DESADV. Ошибка в штрихкоде или количестве в RECADV — претензия претензией, но в системе это уже фиксируется. Мусор в EDI = мусор в учёте сети.

В этой статье

Как устроен цикл поставки в EDI
Что такое ORDERS, ORDRSP, DESADV, RECADV
Таблица сообщений и этапов поставки
Ценовые листы и прочие форматы
Типовые ошибки в сообщениях
Как читать статусы и ошибки от сети
Практические советы по внедрению

Цикл поставки: как это работает в EDI

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

Вот как это выглядит по времени:

День 1. Заказ (ORDERS). Сеть отправляет заказ: товары, количества, дата требуемой доставки. Вы получаете его в своей системе или в личном кабинете EDI-провайдера. На этом этапе данные читают системы, автоматизируют подбор товара.
День 1. Подтверждение (ORDRSP). Вы подтверждаете, что можете отправить товар в требуемый срок, или уведомляете об отсрочке. Это необходимо, чтобы сеть поняла: товар едет или нет.
День 2–3. Отгрузка (DESADV). Товар загружен в машину. Вы отправляете DESADV: что именно отправили, в каких количествах, какой номер документа отгрузки, дата отправки, номер машины, водителя. Сеть видит, что товар в пути.
День 4–5. Приёмка (RECADV). Товар приехал, сеть его разгрузила и проверила. Отправляет RECADV: подтверждение количеств, информация о повреждённых коробках или недостачах. Это уже факт: товар на складе у сети, и вы можете выставлять счёт.

Вдобавок к этим четырём — ценовые листы (PRICAT), счета (INVOIC), уведомления об отгрузке алкоголя (ALCRPT). Каждое сообщение — свой формат, свои обязательные поля, свои грабли.

Сообщение	Этап поставки	Отправитель	Что означает
ORDERS	Заказ	Сеть → Поставщик	Сеть отправляет заказ: товары, количества, адрес доставки, требуемая дата. Это запрос, не подтверждение.
ORDRSP	Подтверждение заказа	Поставщик → Сеть	Вы подтверждаете, что товар есть и будет отправлен в указанный срок, или сообщаете об отсрочке. Без этого сеть не знает, готов ли товар.
DESADV	Отгрузка	Поставщик → Сеть	Товар загружен и отправляется. Здесь указаны точные количества по SKU, номер накладной, дата отправки, адрес доставки, реквизиты машины. Это уведомление, что товар в пути.
RECADV	Приёмка	Сеть → Поставщик	Товар приехал и принят (или не принят полностью). Сеть подтверждает факт получения и количества. На основе RECADV вы можете выставлять счёт.
PRICAT	Ценовой лист	Поставщик → Сеть	Текущие розничные цены и скидки. Отправляют периодически или при изменении цены. Сеть использует для расчётов и маркетинга.
ALCRPT	Отгрузка алкоголя	Поставщик → Сеть	Специальное сообщение только для алкогольной продукции (вино, пиво, спиртные напитки). Обязательно согласно требованиям ЕГАИС и торговых сетей.
INVOIC	Счёт	Поставщик → Сеть	Счёт-фактура или счёт за отгруженный товар. В некоторых сетях INVOIC идёт как электронный документ, в других параллельно выставляется УПД через Диадок.
COMDOC	Коммерческий документ	Поставщик ↔ Сеть	Служебные сообщения, вроде уведомлений об отмене заказа или о возврате товара. Не во всех сетях используется активно.

Лайфхак из практики: сети требуют не все сообщения. Магнит и Лента в обязательном порядке хотят ORDERS, ORDRSP, DESADV, RECADV и PRICAT. Дикси добавляет ALCRPT для алкоголя. Метро может потребовать INVOIC в виде EDI-сообщения, а не как УПД отдельно. Перед интеграцией с новой сетью спросите их техподдержку: «какие сообщения вы требуете» — это экономит неделю дебага.

ORDERS: заказ от сети

ORDERS — это заказ, который инициирует сеть. Товар, количество, дата требуемой доставки, адрес склада, номер договора. Это не предложение, это обязательство сети: товар должен быть доставлен в указанную дату, иначе пени.

Что внутри ORDERS:

Номер заказа (у сети есть свой, вы отслеживаете по нему)
Дата и время приёма заказа
Требуемая дата и время доставки
Адрес доставки (может отличаться от основного склада сети)
Список товаров: каждый по своему SKU/артикулу, с количеством в единицах или в упаковках
Особые требования (если есть): палетирование, укладка, сроки хранения
Контакты ответственного в сети

Главная грабля: SKU в заказе может не совпадать с вашим артикулом. Сеть генерирует свой SKU, и вам нужно понять, какой ваш товар имеется в виду. Если картировка SKU сделана неправильно, вы отправите не то, что просят. Контур.EDI и другие провайдеры помогают с картировкой, но проверить нужно вам.

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

ORDRSP: подтверждение заказа

ORDRSP — ваш ответ на заказ. Вы говорите сети: «Да, всё есть, отправлю в указанный срок» или «Нет, отправлю на день позже». Это критическое сообщение для синхронизации: сеть видит по ORDRSP, готов ли товар.

В ORDRSP вы указываете:

Номер заказа сети (повторяется из ORDERS)
Статус подтверждения: полное, частичное или отказ
Подтверждённые количества по каждому SKU (может быть меньше, чем в заказе)
Планируемая дата и время отгрузки
Если отсрочка — причина (нет товара, техсбой, другое)

Типичная ошибка: не отправить ORDRSP вообще. Бухгалтер вручную обработал заказ, товар ушёл, а подтверждение забыл. Сеть видит ORDERS, но не видит ORDRSP — в системе сети остаётся «ожидание подтверждения». Дальше получится рассинхрон: вы думаете, заказ закрыт, сеть ждёт подтверждения.

Вторая ошибка: указали в ORDRSP большие количества, а потом в DESADV отправляете меньше. Это не прямой запрет, но сеть может засчитать это как нарушение, и следующие заказы она будет дозировать.

DESADV: уведомление об отгрузке

DESADV (Despatch Advice) — уведомление об отгрузке. Товар уже в машине, и вы говорите сети: вот что в машине, когда приедет, как его узнать. Это не накладная, а предварительное уведомление, чтобы сеть не ждала сюрпризов на складе.

Что обязательно в DESADV:

Номер заказа (привязка к ORDERS)
Номер отгрузочного документа (например, номер накладной вашей компании)
Дата и время отгрузки
Планируемая дата и время доставки (может отличаться от требуемой в заказе)
Адрес доставки
Реквизиты машины: марка, номер, водитель, номер мобильного водителя
Точное количество по каждому SKU, которое в машине (вплоть до единиц)
Штрихкод упаковки или палеты (если система этого требует)
Серийные номера или сроки годности (если товар специфический)

Лайфхак: дату и время в DESADV выставляйте реальные, когда товар уходит со склада. Если вы напишете, что товар отправлен завтра, а отправляете сегодня, сеть в статусе будет видеть «товар отправится завтра». Сеть звонит логисту и выясняет, что товар уже еду, — потом претензия вам за неправильные данные.

Вторая грабля: количества в DESADV должны совпадать с тем, что в машине на самом деле. Если вы там указали 100 коробок, а в машине 95, сеть это обнаружит при разгрузке и отправит RECADV с недостачей. Претензия не обязательна, но в системе это фиксируется.

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

RECADV: уведомление о приёмке

RECADV (Receiving Advice) — это уведомление от сети, что товар приехал и принят (или не совсем). Это факт: товар физически на складе сети, и теперь вы можете выставлять счёт.

В RECADV сеть пишет:

Номер заказа и номер DESADV (привязка к исходному заказу)
Дата и время приёмки
Подтверждённые количества по каждому SKU
Недостачи, если есть (какой SKU и сколько не хватает)
Повреждённые товары (если сеть нашла при разгрузке)
Замечания: товар хранился правильно, даты годности в норме и т. д.

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

Главная ошибка: выставить счёт раньше, чем пришёл RECADV. Теоретически можно, но практически это создаёт рассинхрон. Сеть может найти недостачу при разгрузке, отправить RECADV с «-5 коробок», а вы уже счёт выбили на полное количество. Дальше вопрос: кредит-нота или возврат денег? Лучше подождать RECADV, чем потом разбираться с рассинхроном.

Второй подвох: некоторые сети отправляют RECADV на день-два позже физической приёмки. Это нормально, просто нужно понимать, что счёт может идти не день в день с доставкой.

PRICAT: ценовой лист

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

PRICAT обычно отправляют:

Один раз в месяц (плановая передача)
Внепланово, если произошло изменение цены
Перед началом акции

Что в PRICAT:

SKU товара
Розничная цена (может быть несколько категорий)
Минимальный объём закупки для скидки
Процент скидки или цена со скидкой
Дата начала и конца действия цены
Валюта (обычно рубли)

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

ALCRPT: отгрузка алкоголя

ALCRPT (Alcohol Report) — специальное сообщение для алкогольной продукции. Обязательно для вина, пива, спиртных напитков. Требуется большинством крупных сетей из-за нормативных требований.

В ALCRPT указывают:

SKU алкогольного товара
Крепость и объём бутылки
Количество единиц и ящиков
Номер лицензии поставщика на производство/распространение алкоголя
Дата выпуска (для вина — дата урожая)
Номер партии
Прочие реквизиты, если требует сеть

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

INVOIC и COMDOC: прочие форматы

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

Важно: если в договоре с сетью требуется УПД, INVOIC не заменяет УПД. УПД — юридически значимый документ (её через Диадок), а INVOIC — просто EDI-сообщение для синхронизации систем.

COMDOC (Commercial Document) — это служебные сообщения типа отмены заказа, возврата товара, корректировки отправки. Не во всех сетях активно используется, но те, кто использует, требуют его при специфических сценариях.

Пример: вы отправили DESADV, но в пути отломали коробку. Вы отправляете COMDOC об изменении количества, и сеть понимает, что товара на один меньше.

Типовые ошибки в EDI-сообщениях

EDI-провайдер проверяет сообщения перед отправкой, но пропускает не все ошибки. Вот что чаще всего ломает интеграцию:

Неправильная картировка SKU. Ваш артикул 12345, а у сети это SKU 987654. Если в DESADV вы напишете свой артикул, сеть его не узнает. Нужна картировка в системе: каждому вашему товару — соответствующий SKU сети.
Пропущены обязательные поля. Например, в ORDRSP не указан статус подтверждения. Система отправить даст, но сеть не поймёт, подтверждаете вы заказ или нет.
Неверная дата и время. Если в DESADV написано, что товар отправлен 5 июля, а сейчас 3 июля, система будет жаловаться. Даты должны быть реальные, в правильном формате (обычно ISO 8601: YYYY-MM-DD HH:MM).
Несовпадение количеств. В ORDERS 100 коробок, в DESADV вы пишете 110. Сеть увидит расхождение и будет ждать объяснения.
Грязные символы в названиях. Если в SKU или описании товара есть символы, которые система не поддерживает, сообщение может не отправиться или отправиться с ошибкой.
Забыли ORDRSP на заказ. Классика: заказ пришёл, вы его обработали, товар отправили, но подтверждение забыли. В системе сети остаётся зависание.
Разные единицы измерения. Вы отправляете в штуках, сеть требует в упаковках. Или наоборот. Если картировка не совпадает, количество будет в 10 раз больше или меньше.
Истёкшая или неправильная подпись (для INVOIC). Если счёт отправляется подписанным, сертификат должен быть валидным и соответствующим реквизитам компании.

Предупреждение от бывалого: половина проблем с EDI — не из-за ошибок в форматах, а из-за рассинхрона с 1С. Бухгалтер создал счёт в 1С, система автоматически отправила DESADV, но при отправке сбилось количество. Потом RECADV приходит с недостачей, и никто не понимает, где истина. Совет: если интегрируете EDI с 1С, на первой неделе проверьте все отправки вручную. Малейший сбой в коннекторе — и весь документооборот летит.

Как читать статусы и ошибки от сети

Когда вы отправляете сообщение (ORDERS, DESADV и др.), EDI-система каждого сообщения присваивает статус. Эти статусы видны в личном кабинете провайдера.

Основные статусы:

Отправлено (Sent). Сообщение уехало в систему сети. Это не значит, что сеть его принял, просто вы его отправили. Статус может быть такой, пока сеть его обрабатывает.
Принято (Received). Сеть получил сообщение и начал его обрабатывать. Хороший знак.
Обработано (Processed). Сеть полностью обработал сообщение, занёс данные в свою систему. Готово.
Ошибка (Error). Сеть не смог обработать сообщение. Часто вместе со статусом идёт код ошибки и описание. Примеры: «Invalid SKU», «Missing required field», «Date format error».
Частично обработано (Partial). Сеть принял часть данных из сообщения, но некоторые строки он отклонил. Нужно смотреть детали: какие SKU прошли, какие отклонены.

Что делать, если ошибка:

Шаг 1. Посмотрите текст ошибки. В личном кабинете EDI-провайдера обычно есть сообщение об ошибке с кодом. Иногда это достаточно, чтобы понять, что не так.

Шаг 2. Проверьте данные в исходном сообщении. Если ошибка про SKU, проверьте картировку. Если про дату, проверьте формат. Если про количество, пересчитайте.

Шаг 3. Если ошибка непонятна, обратитесь в поддержку EDI-провайдера. Техподдержка Контура или других провайдеров может глубже разобраться, почему сеть отклонил сообщение.

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

Лайфхак: если ошибка повторяется на несколько SKU одинаково, это системная ошибка в картировке или в коннекторе с 1С. Не надо исправлять каждый SKU отдельно — сначала найдите причину ошибки.

Когда и зачем это нужно

EDI-сообщения нужны каждому, кто работает с торговыми сетями. Если вы отправляете товар в Магнит, Ленту, X5, Метро, Дикси, Ашан — без EDI не обойтись. Многие сети требуют обязательный обмен ORDERS, ORDRSP, DESADV, RECADV, и если вы его не делаете, сеть может наложить штрафы за нарушение договора.

EDI решает две проблемы:

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

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

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

Практические советы по внедрению

1. Согласуйте со своим EDI-провайдером, что требует сеть. Не начинайте интеграцию вслепую. Позвоните сети или EDI-провайдеру, узнайте: ORDERS обязателен? PRICAT? INVOIC? Какой формат даты и времени? Это сэкономит дни переделок.

2. Настройте картировку SKU один раз и хорошо. Это основа всего. Каждому вашему артикулу должен соответствовать SKU сети. Проверьте вручную на 10–20 товарах, потом автоматизируйте.

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

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

5. Заведите процесс мониторинга ошибок. Если сообщение не отправилось или пришла ошибка, это должно быть видно кому-то в компании. Поставьте ежедневную сводку по ошибкам в EDI или настройте уведомления.

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

Часто задаваемые вопросы

Что будет, если я не отправлю ORDRSP на заказ?

Заказ останется в статусе «ожидание подтверждения» в системе сети. Сеть может считать это нарушением договора и наложить штраф. Минимум — рассинхрон: вы думаете, заказ обработан, сеть ждёт подтверждения. ORDRSP нужно отправлять обязательно.

Что такое SKU и почему это важно?

SKU (Stock Keeping Unit) — это уникальный код товара в системе сети. Он может отличаться от вашего артикула. Это важно, потому что сеть ориентируется именно на SKU при обработке заказов и отправок. Если картировка неправильная, сеть получит не тот товар.

Когда я могу выставить счёт — сразу после DESADV или после RECADV?

Обязательно после RECADV. RECADV — это подтверждение, что товар реально доставлен и принят сетью. Если вы выставите счёт раньше, а потом придёт RECADV с недостачей, разбирательство будет неприятным. Дождитесь RECADV, проверьте количества, потом счёт.

Какой EDI-провайдер выбрать?

Сеть часто сама определяет, через какого провайдера работать. Контур.EDI, Диадок, СБИС, Такском — все поддерживают одинаковые форматы. Различия в интерфейсе, скорости поддержки, наличии коннекторов к 1С. Спросите у сети, кого они требуют, и выбирайте.

Сеть требует INVOIC как EDI-сообщение. Это вместо счёта-фактуры или параллельно?

Обычно параллельно. INVOIC — это служебное сообщение для синхронизации систем сети и вашей системы (цена, сумма, налоги). Счёт-фактура или УПД отправляется отдельно, через Диадок или другой канал. Если договор требует УПД, он обязателен независимо от INVOIC.

Что если я опоздал с DESADV и отправил его раньше, чем товар ушёл?

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

Обязательно ли отправлять PRICAT каждый месяц?

Обычно да. Сеть использует PRICAT для маркетинга и расчётов. Если вы не отправляете месяц, у сети остаются старые цены, и может быть недопонимание при расчётах. Минимум — отправляйте один раз в месяц, даже если цены не менялись. Максимум — отправляйте при каждом изменении цены (акция, повышение, скидка).

Итог

EDI-сообщения — это язык, на котором говорят торговые сети и поставщики. ORDERS, ORDRSP, DESADV, RECADV — это основная четвёрка, которая покрывает весь цикл поставки. Вдобавок идут PRICAT (цены), ALCRPT (алкоголь), INVOIC (счета) и служебные COMDOC.

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

Если вы работаете с крупными сетями — без EDI не обойтись. Если вы только собираетесь начать, согласуйте требования с сетью и провайдером, настройте картировку SKU, протестируйте на тестовом сервере, и потом запускайте. Первый месяц будет суетливо, потом система срастётся, и вы почувствуете экономию времени и ошибок.

Главное: не закрывайте глаза на ошибки в EDI. Если сообщение не прошло, это не куда-то улетело, а остановилось в системе. Мониторьте статусы, ловите ошибки, исправляйте данные. Это скучнее, чем писать письма контрагентам, но надёжнее в разы.