Звідки беруться розбіжності
Сценарій майже завжди однаковий. Товар продали в офлайн-точці або через Instagram, на сайті кількість лишилася старою, покупець оформив замовлення на позицію, якої немає. Далі буде дзвінок із вибаченнями, повернення грошей і мінус до репутації.
Причина не в неуважності. Причина в тому, що кількість товару зберігається одночасно в кількох місцях і кожне з них вважає себе правим: сайт, таблиця складу, голова власника, іноді ще й маркетплейс.
Синхронізація вирішує рівно одну задачу: зробити так, щоб залишок був однією цифрою, а не чотирма схожими.
Правило нуль: одне джерело правди
Перед будь-якою технічною роботою треба відповісти на питання, яка система веде кількість. Варіантів насправді два.
Облік веде кількість, сайт відображає. Це нормальний варіант для більшості: продажі йдуть різними каналами, а склад один. Сайт отримує залишок і не змінює його самостійно.
Сайт веде кількість. Працює, тільки якщо магазин є єдиним каналом продажу. Щойно зʼявляється офлайн-точка або продаж у месенджері, схема ламається.
Найгірший варіант, коли залишок можна редагувати з обох боків. Тоді розбіжність не питання «чи», а питання «коли».
Що саме синхронізувати
Різні сутності їдуть у різні боки, і це варто розділяти від початку.
- Товари й категорії: з обліку на сайт. Створювати картку двічі немає сенсу; це також рятує від дублів, про які ми писали в матеріалі про те, як скласти каталог товарів.
- Залишки: з обліку на сайт, в один бік і часто.
- Ціни: з обліку на сайт, але обережно: ціна на маркетплейсі зазвичай відрізняється через комісію.
- Замовлення: із сайту в облік. Це єдиний потік, який іде назад.
- Статуси доставки: від перевізника в облік і далі покупцю.
Окремо про варіації: залишок живе на рівні варіанта, а не моделі. Якщо в обліку розмір і колір заведені як варіації, а на сайті як окремі товари, синхронізація або не зійдеться, або доведеться підтримувати мапінг вручну. Як правильно розділити одне й інше, розібрано в матеріалі про варіації товару.
Три способи звести системи
1. Готовий плагін. Найшвидший шлях, якщо у вас WooCommerce. Ставиться, підключається ключем, працює. Мінус у тому, що ви обмежені тим, що вміє плагін.
2. REST API. Універсальний варіант: система обліку й магазин обмінюються даними напряму за токеном. Потрібен розробник або готова інтеграція, але немає стелі за можливостями. У WooCommerce це wc/v3, ключі генеруються в WooCommerce → Settings → Advanced → REST API з правами read, write або read-write.
3. Файловий обмін. Вивантаження прайсу у форматі YML і завантаження його майданчиком за розкладом. Так працюють Rozetka і Prom. Це не синхронізація в реальному часі: Rozetka оновлює дані з фіда приблизно щогодини, а Prom оновлює ключові поля на кшталт ціни й наявності кілька разів на день.
Опитування чи вебхуки
Є два способи дізнатися, що на сайті зʼявилося нове замовлення.
Опитування: облік раз на N хвилин запитує магазин: «щось нове є?». Просто в реалізації, але або створює затримку, або навантажує сайт зайвими запитами.
Вебхук: магазин сам стукає в облік у момент події. WooCommerce має це з коробки: WooCommerce → Settings → Advanced → Webhooks, дванадцять базових подій виду order.created, product.updated, customer.created. Кожна доставка підписується заголовком X-WC-Webhook-Signature, тож приймальна сторона може перевірити, що запит справді від вашого магазину.
Одна деталь, яка з часом усіх кусає: якщо вебхук пʼять разів поспіль не доставився, WooCommerce його вимикає. Мовчки. Тому в будь-якій інтеграції має бути перевірка «а чи приходили події за останню добу».
Доставка: де тут місце перевізника
Третій шматок пазла становить логістика. Ручне створення накладних це не лише час, а й помилки в адресах, які потім перетворюються на повернення.
У Нової Пошти є API, через яке накладну можна створити просто з системи обліку, а статус посилки підтягувати автоматично. Деталі, ключі й обмеження описано в окремому матеріалі про API Нової Пошти.
ПРРО: що вимагає закон, а що ні
Тут варто чітко розділити дві речі, які постійно змішують.
Застосовувати ПРРО є обовʼязком, який залежить від способу оплати:
- оплата карткою через інтернет-еквайринг: ПРРО потрібен;
- переказ на реквізити картки ФОП: потрібен;
- переказ на поточний рахунок за IBAN, який покупець робить сам як повну передоплату: не потрібен (пільга п. 2 ст. 9 Закону № 265/95-ВР);
- накладений платіж: чек видає перевізник; якщо він перераховує кошти на ваш поточний рахунок, ПРРО не застосовується;
- ФОП 1 групи звільнена в будь-якому разі (п. 296.10 ПКУ).
Закон прямо згадує інтернет: обовʼязок видати розрахунковий документ поширюється й на операції, замовлення або оплата яких здійснюється з використанням мережі Інтернет.
Інтегрувати магазин із ПРРО не є обовʼязком. У законі такої вимоги немає: ДПС дає безкоштовне ПЗ, і чек можна пробивати вручну. Інтеграція потрібна вам для швидкості, а не для перевірки. Що обрати і скільки коштує, ми розбирали в матеріалі ПРРО чи РРО для ФОП.
Скільки коштує розбіжність у залишках
Цифру легко недооцінити, бо вона розмазана по дрібницях. Порахуймо на звичайному магазині з 300 замовленнями на місяць.
Якщо 3% замовлень оформлені на товар, якого фактично немає, це 9 випадків на місяць. Кожен із них означає дзвінок і вибачення (15 хвилин), повернення оплати, а приблизно в половині випадків ще й втрачений клієнт. Плюс негативний відгук, який коштує наступних покупців.
Зворотний бік такий самий дорогий: товар є на складі, але на сайті стоїть нуль. Тут ви навіть не дізнаєтеся про втрачений продаж, бо покупець просто піде до конкурента. Саме ці втрати ніколи не потрапляють у звіти.
Як часто оновлювати залишки
Відповідь залежить від того, наскільки швидко у вас обертається товар.
Якщо позиції унікальні або їх по одній штуці (вінтаж, ручна робота, техніка з рук), синхронізація має бути практично миттєвою, інакше два покупці куплять ту саму річ. Тут вебхуки не розкіш, а необхідність.
Якщо товару на складі десятки й сотні одиниць, оновлення раз на 15-30 хвилин зазвичай достатньо. А для маркетплейсів вибору й немає: майданчик забирає фід за власним розкладом, і швидше він не стане.
Практичний компроміс: страховий залишок. Якщо на складі 3 штуки, показуйте на сайті 2. Це прибирає більшість конфліктів на дистанції між оновленнями і коштує дешевше за будь-яку доробку інтеграції.
Що перевірити перед запуском
- Мапінг товарів. За яким полем система звіряє позиції: за артикулом, ID чи назвою. Назва для цього не годиться.
- Що робити з невідомим товаром. Якщо замовлення містить позицію, якої немає в обліку, інтеграція має не мовчати.
- Резервування. Чи зменшується залишок у момент оформлення замовлення чи в момент оплати. Обидва варіанти робочі, але треба обрати один.
- Скасування й повернення. Найчастіше забутий сценарій: товар має повернутися в залишок.
- Журнал обміну. Без логів пошук причини розбіжності перетворюється на ворожіння.
Хто це робить: своїми силами, підрядник чи готове рішення
Три варіанти, і всі три робочі за різних умов.
Готове рішення. Плагін або вбудована інтеграція. Підходить, якщо ваш сценарій типовий: WooCommerce, один склад, одна валюта. Запускається за годину, підтримується вендором.
Підрядник під ключ. Має сенс, коли систем більше двох або є нестандартна логіка, наприклад, резервування під передзамовлення. Головний ризик тут не ціна розробки, а підтримка: інтеграція живе рівно доти, доки хтось оновлює її після змін API з обох боків.
Своїми силами через API. Найгнучкіше і найдешевше на старті, найдорожче в супроводі. Перед тим як обирати цей шлях, чесно спитайте себе, хто виправлятиме обмін о девʼятій вечора в пʼятницю.
Незалежно від варіанта, домовтеся заздалегідь, хто відповідає за журнал обміну і хто отримує сповіщення, коли синхронізація зупинилася. Найдорожчі розбіжності це не ті, що виникли, а ті, які помітили через тиждень.
З чого почати, якщо все зараз у таблиці
Спершу порядок у номенклатурі, потім інтеграція, а не навпаки. Синхронізація безжально розмножує будь-який безлад: дублі в каталозі перетворяться на дублі на сайті, а різні одиниці виміру дадуть залишки, які неможливо зіставити.
Практичний порядок: привести каталог до єдиного вигляду, визначити джерело правди, підключити товари й залишки, потім замовлення, і лише в кінці доставку. Технічну частину переїзду з таблиць описано в гайді про облік товарів і залишків на складі.