Інтеграція сайту з ERP і складом: з чого почати

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

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

Які дані беруть участь в обміні

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

• Каталог товарів. Назви, артикули, характеристики, категорії, фото. Часто частина даних живе в ERP, а частина, наприклад маркетингові описи, лише на сайті.
• Залишки. Кількість на складах, резерви, очікувані поставки. Дані, найчутливіші до швидкості.
• Ціни. Роздрібні, оптові, персональні, акційні, у різних валютах.
• Замовлення. Склад, клієнт, доставка, оплата. Ідуть із сайту в ERP.
• Статуси. Прийнято, зібрано, відвантажено, доставлено, скасовано. Повертаються з ERP і служби доставки на сайт.
• Клієнти. Контакти, групи, умови, історія взаєморозрахунків, якщо це B2B.

Головне правило: у кожної сутності один власник

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

Для кожної сутності визначте джерело істини:

• залишки та облікові ціни зазвичай живуть в ERP: SAP, Odoo, Microsoft Dynamics або іншій обліковій системі;
• маркетинговий контент, SEO-тексти та фото частіше живуть на сайті;
• замовлення народжується на сайті, але після передачі в ERP його статус змінюється вже там;
• статуси доставки приходять від перевізника, наприклад DHL чи локальної служби, через їхній API.

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

Схема обміну

Типова робоча схема виглядає так:

1. ERP вивантажує зміни каталогу, залишків і цін.
2. Проміжний шар, інтеграційний сервіс, приймає дані, перевіряє їх і приводить до формату сайту.
3. Сайт оновлює картки, залишки й ціни.
4. Покупець оформлює замовлення, сайт резервує товар і передає замовлення в інтеграційний сервіс.
5. Сервіс створює документ в ERP і отримує його номер.
6. ERP і служба доставки повідомляють про зміни статусу, сервіс передає їх на сайт, а сайт сповіщає клієнта.

Навіщо потрібен проміжний шар

Можна зв’язати сайт і ERP напряму, але проміжний сервіс майже завжди себе виправдовує. Він тримає чергу повідомлень, повторює відправлення при збоях, веде журнал і дозволяє замінити одну із систем, не переписуючи все.

Push, pull і вебхуки

Є кілька способів передавати дані:

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

Повна та інкрементальна синхронізація

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

Як це виглядає в реальних проєктах

В оптово-роздрібному магазині запчастин Xpert залишки та ціни синхронізуються з обліковою системою клієнта, тож склад на сайті збігається з реальним, а ціни оновлюються без ручної роботи. Товари, клієнти і замовлення пов’язані з обліком і CRM клієнта. Поверх цього працюють API для партнерів, які отримують каталог, наявність і свої ціни напряму у власні системи, генерація прайс-листів і вивантаження на маркетплейси, кожне в потрібному форматі. Доставку підключено через API Нової Пошти.

У проєкті Ricco Pizza замовлення із сайту автоматично йде в ресторанну облікову систему і потрапляє в роботу без ручного введення. Статуси синхронізуються назад, тому сайт і система ресторану показують те саме, а кур’єри отримують адресу і склад замовлення в окремому застосунку.

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

Кілька складів, валют і типів цін

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

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

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

Типові помилки

• Немає єдиного ідентифікатора товару. На сайті одні артикули, в ERP інші, і зіставлення робиться за назвою. Починайте зі спільного ключа.
• Не продумані резерви. Товар продано на сайті, але замовлення ще не дійшло до ERP, і його продають удруге.
• Немає обробки помилок. Замовлення не передалося, і про це ніхто не дізнався. Потрібні повторні спроби, журнал і сповіщення відповідальним.
• Синхронізація «в лоб». Повне вивантаження важкого каталогу щоразу навантажує обидві системи і все одно запізнюється.
• Ручні правки у двох місцях. Хтось виправив ціну на сайті, і під час наступної синхронізації її перезаписало.
• Забули про статуси. Замовлення пішло в ERP, але клієнт так і не бачить, що з ним відбувається.
• Немає тестового середовища. Інтеграцію перевіряють на живих даних, і помилки одразу б’ють по продажах.

З чого почати

1. Опишіть поточний процес: звідки беруться товари, хто змінює ціни, як замовлення проходить шлях від сайту до відвантаження.
2. Складіть таблицю сутностей та їхніх джерел істини.
3. Перевірте, які API чи формати обміну мають ваша ERP і служба доставки.
4. Визначте, які дані потрібні миттєво, а які можна оновлювати рідше.
5. Почніть з одного потоку, наприклад залишків, і запустіть його в тестовому середовищі.
6. Додайте журнал, моніторинг і сповіщення до запуску в роботу.

Читайте на тему: коли час робити власну CRM замість готової; на чому робити інтернет-магазин: OpenCart, WooCommerce, Shopify чи Laravel; що AI-асистент реально автоматизує в магазині.

Обговоримо вашу інтеграцію

Розкажіть, яка у вас облікова система, на чому працює сайт і які дані зараз переносяться вручну. Запропонуємо схему обміну і порядок робіт. Пишіть через форму на сайті, у Telegram, WhatsApp або на e-mail.