Один залишок для складу, сайту й маркетплейсів

Як було

Спочатку актуальний залишок був в обліковій системі. На сайт і маркетплейси дані потрапляли окремо, частково файлами: коли додалися Rozetka і Prom, картки, ціни й кількості туди заливали вивантаженням раз на день, у кращому випадку.

Через це між продажем товару й оновленням каналу виникало вікно, коли маркетплейс ще дозволяв купити те, чого вже немає. Далі або дзвінок «вибачте, закінчилось», або скасування, а скасування б'є по рейтингу продавця.

Альтернатива була теж поганою — навмисно занижувати доступний залишок «про всяк випадок» і не продавати товар, який фактично є.

Окремо жили ціни: у прайсі одна, на сайті інша, на маркетплейсі третя, бо файл заливали в різні дні.

Як автоматизував

Облікова система стала джерелом кількості й ціни.

Зміни передаються в канали. Резерв теж враховується, щоб одна й та сама одиниця не була доступна для двох замовлень.

Якщо канал не прийняв оновлення, система повідомляє про помилку — відсутність відповіді не вважається успішною синхронізацією.

Новий канал підключається тим самим шляхом: правила ціни й наявності для нього описуються окремо, джерело лишається одне.

Як стало

Кількість на складі, на сайті й на маркетплейсах однакова. Файли лишились на крайній випадок, а не як щоденна робота.

Що це дало

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

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

Що буде іншим у вашій компанії

Канал може бути сайтом, Rozetka, Prom, іншою торговою точкою або складом партнера. Потрібен доступний спосіб обміну даними — API, фід чи інший підтримуваний інтерфейс.

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

Показати схожий процес

Технічні деталі

Python, API облікової системи, API сайту та маркетплейсів, черга оновлень, сповіщення про збої