Інтеграція інтернет-магазину зі складом має пов’язувати не дві таблиці, а весь цикл замовлення: публікацію товару, перевірку доступності, резерв, комплектування, відвантаження, скасування та повернення. Якщо передавати лише загальний залишок раз на добу, сайт усе одно може продати товар, уже зарезервований менеджером або заблокований для перевірки.
Надійна схема починається з визначення власника кожного виду даних. Складський контур відповідає за фізичний і доступний залишок, сайт — за дії покупця та склад кошика, а єдиний контур виконання — за резерв і стан замовлення. Інтеграція переносить зміни між ними та підтверджує приймання кожної операції.
Розділіть залишок на зрозумілі стани
Фрази «на складі 12» недостатньо. Частина одиниць може бути пошкоджена, зарезервована, перебувати на перевірці після повернення або бути недоступною в потрібній точці. На вітрині можна обіцяти лише кількість, яку реально виділити новому покупцеві.
| Показник | Що означає | Де використовується |
|---|---|---|
| Фізичний залишок | Фактично є в місцях зберігання | Складські операції та інвентаризація |
| Резерв | Виділений під прийняті замовлення | Захист від повторного продажу |
| Недоступний залишок | Брак, карантин, повернення на перевірці | Не публікується як доступний |
| Доступно до продажу | Фізичний залишок мінус резерви й обмеження | Вітрина та перевірка кошика |
Формулу доступності погоджують до розробки. До неї можна додати підтверджене найближче надходження, якщо бізнес свідомо продає очікуваний товар. Але не можна автоматично вважати доступним усе, що замовлено постачальнику: дата або кількість можуть змінитися.
Призначте єдине джерело для кожного поля
Конфлікти виникають, коли ціну, назву чи залишок незалежно змінюють і на сайті, і в обліковій системі. Останнє збереження випадково перезаписує правильні дані. Для кожного поля потрібне авторитетне джерело та дозволений напрям передавання.
| Дані | Рекомендоване джерело | Напрям |
|---|---|---|
| SKU, одиниця виміру, базова назва | Каталог або ERP | До інтернет-магазину |
| Опис, SEO та контент вітрини | Інтернет-магазин | Зазвичай не повертається в облік |
| Ціна та правила знижок | Затверджений ціновий контур | До каналів продажу |
| Доступний залишок | Складський контур | До інтернет-магазину |
| Замовлення й контакти покупця | Інтернет-магазин | До контуру виконання |
| Резерв, комплектування, відвантаження | Складський контур | На сайт і менеджеру |
Не покладайтеся лише на нічне вивантаження
Великий каталог можна звіряти пакетами, але критичні зміни потрібно передавати подіями. Нове замовлення, скасування, відвантаження або коригування залишку змінює обіцянку покупцеві зараз. Такі події надсилають одразу або через коротку надійну чергу з повтором після тимчасової помилки.
Періодична повна звірка теж потрібна: вона знаходить пропущені події та розбіжності після збоїв. Практична схема поєднує оперативні події з контрольним порівнянням, а не обирає лише один спосіб.
Що має відбутися під час оформлення
- Сайт повторно перевіряє ціну й доступність перед підтвердженням.
- Створює замовлення зі стабільним зовнішнім ідентифікатором.
- Контур виконання приймає його один раз, навіть якщо запит повторився.
- Товар резервується, а сайт отримує підтвердження.
- Комплектування та відвантаження оновлюють стан і фізичний залишок.
- Скасування звільняє резерв; повернення не стає доступним до перевірки.
Ідентифікатор операції та ідемпотентність захищають від дублів. Якщо сайт не отримав відповідь і повторив запит, система має повернути попередній результат, а не створити друге замовлення.
Зіставляйте значення статусів, а не їхні назви
На сайті може бути статус «обробляється», а на складі — «очікує комплектування», «збирається» і «перевірено». Покупцеві не потрібні всі внутрішні кроки, але кожен зовнішній статус має відповідати визначеному стану виконання.
| Подія | Дія складу | Стан у каналі продажу |
|---|---|---|
| Замовлення прийнято | Створено резерв | Підтверджено |
| Комплектування розпочато | Завдання призначено | Обробляється |
| Відвантаження підтверджено | Товар списано з місця зберігання | Передано в доставку |
| Замовлення скасовано | Резерв знято | Скасовано |
| Повернення перевірено | Оприбутковано або переміщено в карантин | Повернення оброблено |
Контролюйте помилки як бізнес-відхилення
Повідомлення «обмін завершено з помилкою» не пояснює, який об’єкт втрачено, на якому етапі, чи можна повторити операцію та хто має втрутитися. Невідомий SKU, конфлікт ціни, неправильний склад і нестача доступного товару потребують різних дій.
Потрібні журнал обміну, черга повторів, відповідальний за винятки та щоденна звірка кількості замовлень, сум, резервів і відвантажень. Успішна технічна відповідь ще не доводить виконання бізнес-операції.
Перевірка перед запуском
- призначити майстер-джерело кожного поля;
- затвердити формулу доступного залишку;
- описати створення, зміну, скасування та повернення;
- зіставити статуси двох систем;
- перевірити повторний запит без дублів;
- випробувати недоступність кожної сторони;
- налаштувати звірку залишків і замовлень;
- призначити власника черги помилок.
Інтеграція готова не тоді, коли дані один раз успішно передалися, а коли процес витримує повтори, затримки, скасування та часткові збої без ручного відновлення кожної операції. Контур каталогу Business Reactor може бути спільною основою для товару, доступності та виконання замовлення в різних каналах після погодження правил обміну й відповідальності.
