Кейс сложности интеграции интернет-магазина со всеми сервисами от Бета ПРО

Кейс сложности интеграции интернет-магазина со всеми сервисами от Бета ПРО

Рост тарифов, штрафов и рисков на маркетплейсах заставляет продавцов искать альтернативу: собственные интернет-магазины, нишевые площадки и независимый фулфилмент. По данным материала, за последние два месяца спрос на сторонний фулфилмент вырос в 10 раз год к году.
⠀
Главная проблема начинается после ухода с маркетплейса
Нужно связать сразу несколько систем: сайт, CRM, склад, доставку, платежи и Честный знак. В одном из проектов Оси бизнеса интернет-магазин на WooCommerce связали с Бета ПРО, Яндекс Доставкой и системой маркировки. Все данные пришлось вести через один портал. Иначе разные сервисы начинали хранить разные версии одного заказа.
⠀
Даже поле «количество» может работать по-разному
На складе Бета ПРО одна строка заказа означала одну физическую единицу товара. Если покупатель заказал четыре одинаковых товара, системе нужно было передать четыре отдельные строки. Это оказалось важно и для Честного знака: каждой единице нужен собственный код маркировки.
⠀
С доставкой возникла другая проблема
Если после создания заявки происходил сбой, повторный запрос мог создать еще одну заявку. Поэтому идентификатор Яндекс Доставки стали сохранять сразу после успешного ответа, а не после завершения всей операции. С возвратами похожая история. Склад создавал отдельный документ возврата, а интернет-магазин мог продолжать считать заказ доставленным. Финальный статус поэтому оставили под контролем менеджера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: EcomHub