Один майстер цін на вісім вітрин: ціни, залишки й картки без ручної роботи

Коли магазин один, ціна живе в одному місці. Коли вітрин вісім, у кожної зʼявляється власна думка про те, скільки коштує товар і чи є він узагалі.

Клієнт бачить на сайті одну ціну. Менеджер по телефону називає іншу. Склад не має ні тієї, ні тієї - і спокійно збирає замовлення на позицію, якої вже немає.

Рішення нудне й правильне: одне джерело правди на ціну, одне на залишок і автоматика, яка регулярно зводить решту до них. Уся складність - у деталях цього «зводить».

Проблема: у кожної вітрини своя думка про ціну

Здається, що ціна - це просто число, яке треба скопіювати в кілька місць. Насправді кожен майданчик зберігає її по-своєму, і копіювати доводиться не число, а рішення.

Ручна робота тут росте не разом з каталогом, а разом з добутком: кожна зміна ціни множиться на кількість вітрин. Один товар подорожчав - вісім місць треба відкрити, знайти й виправити.

Оновлення цін колись було одним рядком серед інших дрібних автоматизацій. Саме з нього і виріс окремий контур: ручна робота росла швидше за каталог.

Як автоматизація це вирішує

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

Потоки навмисно розділені: ціна змінюється рідко й обдумано, залишок - постійно й механічно. Змішувати їх в один прогін означає або гальмувати залишки, або смикати ціни занадто часто.

Ефективна ціна, а не базова

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

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

Пишемо тільки різницю

Перед записом система порівнює нову ціну з тією, що стоїть на вітрині зараз. Якщо вони однакові, запису не відбувається взагалі.

Тому прогін, у якому нічого не змінилось, не залишає в магазині жодного сліду. Це і дешевше за лімітами чужих API, і чесніше: у журналі змін видно тільки справжні зміни.

Що це дало бізнесу

У компанії зʼявилась одна відповідь на питання «скільки це коштує». Ціна на всіх вітринах походить з одного місця, залишок - зі складу, і людина більше не переносить числа руками.

Окремим результатом стала разова частина. Перед запуском виявилось, що складська програма веде приблизно третину карток, а решта товарів заводилась повз неї - тобто половина каталогу для системи обліку просто не існувала.

Чесно про межі. Система свідомо вміє передавати менше, ніж могла б: якщо службова таблиця відповідностей застаріла, вона не розкладає залишки за здогадом, а віддає дані так, як отримала.

Це виглядає як недоробка, доки не побачиш альтернативу. Розкладений за старою мапою залишок - це товар, помічений у наявності там, де його немає, і продаж, який доведеться скасовувати.

Як це влаштовано всередині

Розгортання артикулів

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

Тому приймач розгортає кожен короткий код на всі відомі артикули майданчиків за таблицею з 9 451 пари і передає далі вже один пакет на 3 650 позицій. Сама таблиця відповідностей будується автоматично щоночі з вивантажень вітрин - її ніхто не веде руками.

Що робить система, коли не впевнена

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

Друге правило стосується відмов на чужому боці. Якщо CRM не відповідає, приймач повертає складській програмі код помилки, а не код успіху, щоб та повторила пакет наступним циклом. Це вже перевірено на живому інциденті: перший бойовий пакет упав, повтор приїхав сам.

Клас помилок, який трапився двічі

Автоматичне заведення товарів ламалось двічі, і обидва рази причина була одна - загублене поле у вивантаженні.

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

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

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

Кому це підходить

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

Побутова ознака, за якою легко перевірити, чи це про вас: якщо після зміни ціни хтось у компанії відкриває список місць, де її треба поправити, - так, це про вас. А якщо такого списку немає, то десь ціна вже стара, і ви про це ще не знаєте.

Синхронізація каталогу - це не про API. Це про те, щоб у компанії була одна відповідь на питання «скільки це коштує».