Доставка й накладений платіж — окремий контур: інтеграція з перевізниками.
Проблема не в сайті й не в обліку
Типова картина українського малого бізнесу: є сайт на готовій платформі, є магазин на маркетплейсі, є облік у бухгалтерській програмі й таблиця для складу. Кожна ланка працює. Не працює стик між ними.
Виглядає це так: замовлення з сайту менеджер переносить руками, залишки на маркетплейс вивантажують раз на день файлом, а склад живе своїм життям. Поки замовлень десять на день, це навіть зручно. На п’ятдесяти починаються продажі того, чого немає, і скасування, які псують рейтинг на майданчику.
Важливо розуміти: інтеграція — це не технічне завдання про обмін файлами. Це рішення про те, де живе правда про ваш товар. Усе інше — наслідки цього рішення.
Головне питання: хто володіє залишком
Одна система має бути джерелом істини щодо кількості товару. Не дві, не «звіряємо ввечері» — одна. Це найважливіше рішення в усьому проєкті, і ухвалити його треба до того, як хтось напише перший рядок коду.
Варіант перший: залишок веде облікова система. Сайт і маркетплейси отримують кількість від неї й ніколи не змінюють самостійно. Це правильний варіант для більшості компаній, бо фізичний товар лежить на складі, а не на сайті, і всі надходження, повернення та списання відбуваються саме в обліку.
Варіант другий: залишок веде платформа магазину. Має сенс лише тоді, коли ви торгуєте виключно онлайн, складу як такого немає, а товар їде від постачальника напряму до покупця.
Найгірший варіант — коли залишок ведуть обидві системи «та й звіряємо». Це гарантований конфлікт даних, і питання лише в тому, як швидко він проявиться.
Що синхронізувати, а що ні
Спокуса синхронізувати все обертається дорогим і крихким рішенням. Реально потрібні чотири потоки.
| Потік | Напрямок | Навіщо |
|---|---|---|
| Товари й ціни | Облік → магазин | Одна номенклатура, одна ціна, без ручного дублювання |
| Залишки | Облік → магазин | Не продавати те, чого немає |
| Замовлення | Магазин → облік | Менеджер не переносить руками |
| Статуси | Облік → магазин | Клієнт бачить, що замовлення зібрано й відправлено |
Що синхронізувати не варто: описи товарів, фотографії, SEO-тексти й відгуки. Це контент магазину, йому нема чого робити в обліковій системі. Спроба вести картки товару з описами й картинками в ERP — класична помилка, після якої проєкт роздувається вдвічі.
Маркетплейси змінюють картину
Якщо ви продаєте не лише на своєму сайті, а й на майданчиках, з’являється складність, про яку зазвичай не думають заздалегідь.
Один товар — кілька карток. На кожному майданчику своя картка зі своїм ідентифікатором. Зв’язок між вашим артикулом і кодом товару на майданчику треба десь зберігати, і це має бути система, а не таблиця відповідностей у когось на комп’ютері.
Резерв під кожен канал. Якщо на складі 100 одиниць і три канали продажу, показувати 100 у кожному — це запрошення до оверселінгу. Практика: або показувати всім єдиний реальний залишок із частим оновленням, або виділяти квоти під канали. Перше простіше й зазвичай працює краще, друге потрібне, коли за зрив замовлення майданчик карає рейтингом.
Повернення. На маркетплейсах їх помітно більше, ніж у власному магазині, і приходять вони із затримкою. Якщо повернення не оформлюються документом одразу, залишки почнуть розходитися — це одна з типових причин розбіжностей.
Як часто оновлювати
Розповсюджена помилка — синхронізувати все й у реальному часі. Це дорого, навантажує обидві системи й майже нікому не потрібно.
- Залишки — найчастіше з усього, від кількох хвилин до пів години. Це саме той потік, де затримка коштує грошей.
- Замовлення — у реальному часі або близько до того. Клієнт очікує підтвердження швидко.
- Ціни — кілька разів на день достатньо, якщо у вас немає динамічного ціноутворення.
- Нові товари й описи — раз на день. Ці дані не змінюються щохвилини.
Окремо продумайте, що відбувається, коли зв’язок обірвався. Правильна поведінка: магазин продовжує працювати з останніми відомими залишками, а після відновлення отримує актуальні дані й розбіжності потрапляють у звіт. Неправильна — магазин показує нулі й ви не продаєте нічого.
Чек-лист перед інтеграцією
Питання, на які варто відповісти до того, як обговорювати технічну реалізацію.
- Яка система володіє залишком — одна, без винятків?
- Чи приведена номенклатура до ладу, чи немає дублів під різними назвами?
- Як пов’язані ваші артикули з кодами товарів на кожному майданчику?
- Що відбувається із замовленням, яке скасували після резервування?
- Хто оформлює повернення і в який строк?
- Що робить магазин, якщо облікова система недоступна?
- Хто відповідає за інтеграцію після запуску, коли майданчик змінить своє API?
Останній пункт недооцінюють найчастіше. Маркетплейси змінюють інтерфейси обміну без узгодження з вами, і інтеграція вимагає супроводу — це не проєкт із датою завершення. Про порядок наведення ладу в довідниках до старту — у чек-листі підготовки даних.
Часті запитання
Чи можна інтегрувати будь-яку платформу магазину з обліком?
Практично будь-яку, у якої є API або можливість обміну файлами. Різниця у вартості: для популярних платформ існують готові конектори, для самописного сайту інтеграцію доведеться розробляти окремо. Це варто з’ясувати до вибору облікової системи, а не після.
Що робити з товарами, які продаються тільки онлайн?
Вести їх у тій самій номенклатурі, що й решту, просто з ознакою каналу. Окрема довідникова база під онлайн — це шлях до дублів і розбіжностей, які потім доведеться зводити вручну.
Як не продати той самий товар двічі на різних майданчиках?
Достатньо частого оновлення залишків з єдиного джерела: інтервал у кілька хвилин закриває більшість випадків. Квоти під канали потрібні лише за високої оборотності, коли навіть коротка затримка призводить до оверселінгу.
Скільки часу займає інтеграція?
Для типової платформи з готовим конектором — від двох до чотирьох тижнів, і більша частина цього часу йде на впорядкування номенклатури, а не на технічну частину. Самописний сайт або нестандартна логіка резервування збільшують строк.
Чи потрібно переносити описи товарів і фото в облікову систему?
Ні. Це контент магазину, і його місце в магазині. Спроба вести картки з описами й зображеннями в обліковій системі роздуває проєкт і не дає нічого взамін.