Заказы сетей, EDI и маркетплейсы: как дистрибьютору связать каналы с учётом

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

EDI и ЭДО — не одно и то же

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

Цепочка сообщений с сетью

Конкретный набор сообщений определяет регламент сети, но основа у большинства одинаковая и строится на международном стандарте EANCOM (подмножество EDIFACT).

Дополнительно сети могут использовать сообщения с каталогом и ценами (PRICAT), счётом (INVOIC) и другие. Требования к срокам ответа, к наличию DESADV с SSCC при поставке на распределительный центр и штрафы за невыполнение заказа прописываются в договоре и регламенте сети — прочитайте их до подключения, а не после первого штрафа.

EDI-провайдер и интеграция

С сетями работают через EDI-провайдеров — на российском рынке это, например, Контур.EDI, СФЕРА (Корус), Saby EDI и другие. Сеть может работать с ограниченным списком провайдеров, поэтому выбор начинают с вопроса «через кого работают наши сети». У провайдеров есть веб-интерфейс для ручной работы и модули или API для интеграции с учётной системой.

• Типовая 1С и несколько сетей: обычно достаточно модуля интеграции провайдера для 1С.
• Своя CRM или складская система, много сетей, кросс-докинг: интеграция через API провайдера, где заказы сетей попадают в общий контур заказов, а не живут отдельно. Такие связки мы делаем как API-интеграцию на заказ.
• Несколько провайдеров: если сети работают у разных, нужен единый слой, который приводит сообщения к одному виду внутри компании.

Маркетплейсы: три схемы, три разных учёта

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

При FBS ключевое — скорость передачи остатков. Если площадка видит 50 штук, а вы уже продали 45 сети, заказы на маркетплейсе придётся отменять, и это сказывается на рейтинге продавца. Для маркированных товаров площадки требуют передавать коды маркировки по отправлениям; порядок у каждой свой и описан в документации их API. Как устроена выгрузка товаров, цен и остатков, описано на странице выгрузка на маркетплейсы.

Один остаток на все каналы

Ядро всей схемы — единый свободный остаток и правила его распределения. Без этого каналы конкурируют за один и тот же товар вслепую.

1. Единая точка резерва. Заказ из любого канала — агент, портал, сеть, маркетплейс — ставит резерв в одной системе. Обычно это учётная или складская система, а не CRM.
2. Квоты по каналам для дефицита. Например, на ходовую позицию сетям — не больше заданного объёма в день, на маркетплейс — неснижаемый остаток. Правило задаёт коммерческий директор, система его исполняет.
3. Приоритет при нехватке. Кого урезать первым, если пришёл крупный заказ сети, а остатка не хватает: сеть со штрафами за недопоставку, маркетплейс или независимую розницу.
4. Быстрая выгрузка изменений во все каналы, где покупатель сам видит остаток: маркетплейсы, B2B-портал, приложение агентов.
5. Ночная сверка выгруженных остатков с фактическими.

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

Цены и условия в разных каналах

У сети цена фиксирована в спецификации к договору, и ORDERS с другой ценой — повод для ORDRSP с исправлением, а не молчаливого согласия. На маркетплейсе цена меняется часто, и её надо выгружать вместе с остатками. У независимой розницы — прайс по типу клиента и персональные скидки. Если цены живут в трёх местах, через месяц они разъедутся. Храните их в одном справочнике с видом цены по каналу, а площадкам и сетям выгружайте оттуда. Подробнее о прайсах и бонусах — в статье прайс-листы, акции и ретробонусы.

Разбор расхождений после приёмки

Деньги в работе с сетями часто теряются после доставки. Сеть приняла меньше, чем отгружено, прислала RECADV и корректировку, а у вас в учёте висит полная сумма. Через три месяца при сверке взаиморасчётов выясняется, что разница списана, а кто виноват — уже не понять.

• RECADV автоматически сопоставляется с DESADV и УПД по строкам.
• Расхождение создаёт задачу ответственному с суммой и сроком разбора.
• Корректировочный документ формируется по результатам разбора, а не по умолчанию.
• Отчёт по расхождениям по каждой сети: где теряется товар — при сборке, в дороге или на приёмке.

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