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

По данным материала, за последние два месяца спрос на сторонний фулфилмент вырос в 10 раз год к году.
⠀
👉 Главная проблема начинается после ухода с маркетплейса
Нужно связать сразу несколько систем: сайт, CRM, склад, доставку, платежи и Честный знак.

В одном из проектов Оси бизнеса интернет-магазин на WooCommerce связали с Бета ПРО, Яндекс Доставкой и системой маркировки.

Все данные пришлось вести через один портал. Иначе разные сервисы начинали хранить разные версии одного заказа.
⠀
👉 Даже поле «количество» может работать по-разному
На складе Бета ПРО одна строка заказа означала одну физическую единицу товара.

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

Это оказалось важно и для Честного знака: каждой единице нужен собственный код маркировки.
⠀
👉 С доставкой возникла другая проблема
Если после создания заявки происходил сбой, повторный запрос мог создать еще одну заявку.

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

Финальный статус поэтому оставили под контролем менеджера.
⠀
👉 Главный урок
Своя логистика дает продавцу больше независимости от маркетплейса, но требует хорошо связать между собой все сервисы.

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

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

Подробнее

Логистика вне маркетплейса: как селлеру не потерять заказы

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

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

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

Пять систем, одна версия данных

Рассмотрим реальный пример связки от интегратора «Ось бизнеса»: интернет-магазин на WooCommerce, склад фулфилмента «Бета ПРО», доставка через «Яндекс Доставку» и маркировка «Честный знак». В процессе участвуют пять независимых систем:

Сайт — точка входа для покупателя.

Внутренний портал, или CRM, — управляет заказами, чеками, статусами и кодами маркировки.

Склад фулфилмента — хранит товар и выполняет сборку и отгрузку.

Служба доставки — формирует заявки, генерирует этикетки и трек-номера.

«Честный знак» — контролирует оборот маркированных товаров через ОФД.

Первоначально команда проекта попыталась использовать промежуточное звено между системами, но это привело к появлению двух параллельных версий данных о заказе. В результате стало сложно определить, какой статус является актуальным. От такой прослойки отказались и создали иное архитектурное решение: все внешние коммуникации идут через один портал, а не через отдельный коннектор. То есть портал выступает единым диспетчером.

Два API склада: почему интеграции нужна гибкость

Приступая к интеграции с «Бета ПРО», столкнулись с тем, что в компании есть два поколения API.

Основной REST API /grh/api с Basic-авторизацией и старый XML-сервис /wsrv. Авторизация там устроена иначе: логин и пароль передаются в теле запроса, а ответ содержит признак state: 0 — успех, -1 — ошибка с полным откатом. Необходимо было изучить оба и подобрать нужный.

Трактовка количества

Одна из важных несостыковок возникла из-за различий в понимании поля «количество» и связана с особенностью модели данных фулфилмента. В систему отправлялась позиция с артикулом и количеством «2 шт.». Склад в своем интерфейсе показывал заказ как две единицы, но физически отгружал только одну.

Выяснилось, что в заданиях «Бета ПРО» атрибут количества игнорируется: каждая строка всегда соответствует одной товарной единице. Если нужно отгрузить четыре штуки, необходимо создать четыре отдельные строки. Это важно и для дальнейшего получения кода маркировки на каждую единицу товара.

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

Заявки-призраки в доставке

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

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

Возвраты, о которых портал не узнает

Возврат — это самостоятельный объект учета. И когда заказ возвращался на склад, оператор оформлял отдельный документ возврата в своей системе, и портал не связывал его с заказом на доставку. Заказ продолжал числиться доставленным.

Потребовалось доработать складской API для регулярного опроса на наличие документов возврата.

В интеграции было предусмотрено, что любой промежуточный возвратный статус от «Яндекс Доставки» автоматически переводит заказ в состояние «Возвращается». При этом автоматическая установка финального статуса «Возврат» была отключена.

Причина связана с реальной операционной практикой. Менеджер может принять решение не принимать возвращенную посылку на склад, а сразу отправить замену за счет компании. В таком случае заказ должен оставаться в статусе «Возвращается», пока человек не примет окончательное решение. Автоматический перевод в статус «Возврат» нарушал бы ручное управление процессом.

Когда оплата прошла, но система об этом не узнала

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

При переходе на продакшн-ключи нужно было проверить не только сами ключи, но и все настройки колбэков. Иначе платёж пройдёт, но портал никогда не получит подтверждение.

Маркировка: почему коды нужно проверять до отгрузки

Коды «Честного знака» приходят от склада вместе с отгрузочными документами — строго по одному коду на каждую товарную единицу. Портал должен проверить их полноту и передать данные в чек через ОФД.

Здесь правило «одна строка — один код» имеет решающее значение: без разбивки позиций с количеством больше одной единицы чек не пройдет фискализацию.

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

Что нужно выяснить у фулфилмент-оператора до старта

Опыт проекта позволяет сформулировать контрольный список вопросов для любого фулфилмент-оператора:

— какие API-интерфейсы доступны и не используются ли устаревшие версии для критически важных операций;

— как обрабатывается количество товара в заказе: поддерживается ли несколько единиц в одной позиции;

— в каком формате передаются коды маркировки: в ответе метода, отдельном файле или через личный кабинет;

— как система информирует о возвратах: через событие или через периодический опрос списка документов;

— кто управляет итоговыми статусами доставки — автоматика или менеджер, и возможен ли ручной оверрайд;

— что происходит при повторном запросе: создается новый объект или возвращается уже существующий.

Эти вопросы помогают избежать большинства проблем, которые обычно проявляются на первом живом заказе.

Интеграция — это согласование разных моделей данных

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

У «Бета ПРО» — эволюционная архитектура с двумя API. У «Яндекс Доставки» — собственная логика статусов. У «Честного знака» — строгие правила передачи данных. У WooCommerce — своя модель заказа.

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