Интеграция интернет-магазина со складом должна связывать не две таблицы, а весь цикл заказа: публикацию товара, проверку доступности, резерв, комплектацию, отгрузку, отмену и возврат. Если передавать только общий остаток раз в сутки, сайт продолжит продавать товар, который уже зарезервирован менеджером или находится в проблемной поставке.
Рабочая схема начинается с определения владельца каждого вида данных. Складская система отвечает за физический и доступный остаток, сайт — за действия покупателя и состав корзины, а единый контур заказов — за резерв и статус исполнения. Интеграция передаёт изменения между ними и подтверждает, что каждое изменение принято.
Сначала разделите остаток на понятные состояния
Число «на складе 12» недостаточно. Две единицы могут быть повреждены, четыре — зарезервированы под оформленные заказы, одна — ожидать решения по возврату. Для сайта доступно только то количество, которое действительно можно пообещать новому покупателю.
| Показатель | Что означает | Где используется |
|---|---|---|
| Физический остаток | Фактически находится в местах хранения | Инвентаризация и складские операции |
| Резерв | Выделен под принятые заказы | Защита от повторной продажи |
| Недоступный остаток | Брак, карантин, возврат на проверке | Не публикуется как доступный |
| Доступно к продаже | Физический остаток минус резервы и ограничения | Витрина и проверка корзины |
Формулу доступности утверждают до разработки. Например: физический остаток минус активные резервы минус карантин плюс подтверждённое количество ближайшего прихода, если бизнес действительно продаёт ожидаемый товар. Нельзя молча добавлять к доступности всё, что заказано поставщику: срок поставки может измениться.
Определите единственный источник для каждого поля
Конфликты появляются, когда цену, название или остаток можно независимо изменить и на сайте, и в учётной системе. Последнее сохранение случайно перезаписывает корректные данные. Для каждого поля нужен мастер-источник и разрешённое направление передачи.
| Данные | Рекомендуемый источник | Направление |
|---|---|---|
| SKU, единица измерения, базовое название | Каталог или ERP | В интернет-магазин |
| Описание, SEO, контент витрины | Интернет-магазин | Обычно не возвращается в учёт |
| Цена и правила скидок | Утверждённый ценовой контур | В каналы продаж |
| Доступный остаток | Складской контур | В интернет-магазин |
| Заказ и контакты покупателя | Интернет-магазин | В контур исполнения |
| Резерв, комплектация, отгрузка | Складской контур | На сайт и менеджеру |
Не ждите ночной полной выгрузки
Каталог на десятки тысяч позиций можно сверять пакетно, но критические изменения должны передаваться событиями. Новый заказ, отмена, отгрузка и корректировка остатка влияют на обещание покупателю сейчас. Их следует отправлять сразу или короткой очередью с повторной доставкой при временной ошибке.
Полная сверка всё равно нужна: она находит пропущенные события и расхождения после сбоев. Практичная комбинация — оперативные события плюс периодическая контрольная синхронизация, а не выбор только одного подхода.
Что должно происходить при оформлении заказа
- Сайт повторно проверяет цену и доступность перед подтверждением.
- Создаёт заказ с уникальным внешним идентификатором.
- Складская система принимает заказ один раз, даже если запрос повторился.
- Товар резервируется, а сайт получает подтверждение резерва.
- Комплектация и отгрузка меняют статус заказа и уменьшают физический остаток.
- Отмена освобождает резерв; возврат не становится доступным до проверки.
Уникальный идентификатор и идемпотентность защищают от дублей. Если сайт не получил ответ и повторил запрос, система должна вернуть результат уже созданного заказа, а не создать второй.
Сопоставьте статусы, а не копируйте их названия
На сайте может быть статус «обрабатывается», а на складе — «ожидает комплектации», «собирается» и «проверен». Покупателю не нужны все внутренние этапы, но каждому внешнему статусу должно соответствовать определённое состояние исполнения.
| Событие | Действие со складом | Что видит канал продаж |
|---|---|---|
| Заказ принят | Создан резерв | Заказ подтверждён |
| Комплектация начата | Задание назначено сотруднику | Заказ обрабатывается |
| Отгрузка подтверждена | Товар списан из места хранения | Передан в доставку |
| Заказ отменён | Резерв снят | Отменён |
| Возврат принят и проверен | Остаток возвращён либо помещён в карантин | Возврат обработан |
Контролируйте ошибки как бизнес-события
Запись «обмен завершён с ошибкой» бесполезна без ответа на четыре вопроса: какой объект не передан, на каком этапе, можно ли повторить операцию и кто должен вмешаться. Ошибки цены, неизвестного SKU, отсутствия склада и недоступного товара требуют разных действий.
Для контроля нужны журнал обмена, очередь повторов, уведомление ответственному и сверка контрольных показателей: число заказов за период, сумма, количество резервов и отгрузок. Успешный HTTP-ответ ещё не доказывает, что бизнес-операция выполнена корректно.
Проверка перед запуском
- назначить мастер-источник каждого поля;
- утвердить формулу доступного остатка;
- описать создание, изменение, отмену и возврат заказа;
- сопоставить статусы двух систем;
- проверить повторную отправку без дублей;
- провести тесты при недоступности одной стороны;
- настроить ежедневную сверку остатков и заказов;
- назначить владельца очереди ошибок.
Интеграция считается готовой не тогда, когда данные однажды успешно передались, а когда процесс выдерживает повторы, задержки, отмены и частичные сбои без ручного восстановления каждой операции. В контуре каталога Business Reactor связь товара, доступности и исполнения заказа может использоваться как единая основа для каналов продаж; до подключения важно зафиксировать правила обмена и ответственности.
