Синхронизация остатков интернет-магазина: как не продавать то, чего уже нет

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

Деньги нужно возвращать, заказ отменять, покупателю — объяснять ситуацию.

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

Почему это происходит

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

Например, на складе осталось три единицы.

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

Чем выше продажи, тем опаснее такая задержка.

Остаток на складе и доступный остаток — не одно и то же

Допустим, физически на складе лежит 20 товаров.

Но пять уже зарезервированы под оформленные заказы.

Значит, продавать можно только 15.

Если сайт получает просто число «20», часть уже зарезервированных товаров снова попадает в продажу.

Поэтому нормальная синхронизация должна учитывать не только склад, но и резервы.

Нужен один главный источник данных

Самая неприятная ситуация — когда остаток можно менять сразу в нескольких местах.

Менеджер исправил количество на сайте.

Через минуту учётная система вернула старое значение.

Потом маркетплейс прислал ещё одно обновление.

В итоге никто не понимает, какая цифра правильная.

Лучше заранее определить, где хранится основной остаток: в учётной системе, ERP, WMS или самом интернет-магазине.

Остальные каналы должны получать данные оттуда.

Важны артикулы и варианты товара

Ошибки возникают не только из-за задержек.

Представим футболку в трёх размерах и двух цветах. Это шесть разных вариантов с разными остатками.

Если внешняя система знает только общий артикул модели, она может обновить не тот размер или цвет.

Поэтому у каждой продаваемой комбинации должен быть понятный и уникальный идентификатор.

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

Что делать при сбое

Интеграция тоже может временно перестать работать.

Не отвечает складская система, недоступен API или произошёл сетевой сбой.

Такие ошибки нельзя просто терять.

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

Полезно также видеть время последней успешной синхронизации.

Если обмен остановился несколько часов назад, лучше узнать об этом раньше покупателей.

Как проверить свою систему

Возьмите несколько товаров и проведите простой тест:

Оформите заказ на сайте.

Оформите заказ через другой канал.

Отмените один заказ.

Верните товар на склад.

Временно отключите обмен.

После каждого действия сравните остатки.

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

Как это работает с PrestaShop

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

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

В магазинах Ewonta на базе PrestaShop такие процессы можно связывать с внешними учётными системами и каналами продаж через интеграции.

Синхронизация остатков — это не просто передача цифры «сколько товара осталось».

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

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