Двостороння синхронізація каталогу товарів з ERP-системою
Уявіть: на сайті ціна 1500 грн, а в ERP — 1200. Клієнт замовляє за неактуальною ціною, ви втрачаєте маржу або скасовуєте замовлення. Фінансові втрати від таких розсинхронізацій можуть сягати мільйонів гривень на рік — наприклад, для каталогу з 10 000 SKU середня втрата становить 1,5 млн грн/рік. Особливо критично це для великих каталогів, де ручна вивірка неможлива. Такі розбіжності виникають, коли каталог товарів живе окремо від ERP (SAP, Oracle NetSuite, Microsoft Dynamics, Odoo). Ми вирішуємо цю проблему двосторонньою синхронізацією: будь-яка зміна в ERP миттєво відображається на сайті і навпаки. Згідно з документацією Odoo, правильно налаштована синхронізація скорочує помилки до 0.1%.
Як синхронізація каталогу з ERP вирішує проблему розбіжностей?
ERP-системи мають зрілі REST API або SOAP/OData-інтерфейси, але кожна — зі своєю моделлю даних, логікою версіонування та обмеженнями. Без правильної інтеграції дані швидко розходяться. Нижче — варіанти протоколів для популярних ERP.
| ERP | Протокол | Формат |
|---|---|---|
| SAP S/4HANA | OData v4, REST | JSON/XML |
| Oracle NetSuite | REST (SuiteQL) | JSON |
| Microsoft Dynamics 365 | OData v4 | JSON |
| Odoo | JSON-RPC / REST | JSON |
| 1С:ERP | CommerceML + REST | XML/JSON |
Що обрати: Event-Driven чи Polling?
Polling — сайт періодично запитує зміни в ERP. Простіше реалізувати, але створює затримку (в середньому 5–15 хвилин до оновлення) і зайве навантаження на ERP.
Webhooks (Change Data Capture) — ERP повідомляє сайт про кожну зміну. Мінімальна затримка (секунди), але потребує підтримки з боку ERP та обробки перебоїв. Webhooks у 5 разів швидше за polling для критичних даних.
Гібридний підхід (рекомендуємо) — webhooks для критичних даних (ціни, залишки), polling раз на годину для менш термінових (описи, характеристики). Так ви отримуєте швидкість без втрати надійності. Гібридний підхід у 3 рази ефективніший за чистий polling за швидкістю оновлення критичних даних і знижує навантаження на ERP на 40%. Порівняння методів:
| Метод | Затримка | Навантаження на ERP | Складність |
|---|---|---|---|
| Polling | 5-15 хв | Висока | Низька |
| Webhooks | 1-5 сек | Низька | Середня |
| Гібрид | 1-15 хв | Середня | Висока |
Що входить в роботу з інтеграції?
Ми — команда з 7-річним досвідом інтеграції, виконали 50+ проєктів. Ми не просто підключаємо API — ми проєктуємо архітектуру, обробляємо помилки та гарантуємо консистентність. У deliverables входять:
- документація: схеми даних, маппінг полів, sequence-діаграми;
- код: модуль синхронізації з логами, ретраями та моніторингом;
- тестування: unit-тести, інтеграційні тести, навантажувальне тестування (гарантуємо обробку 10 000 SKU за 2 хвилини);
- навчання: як запускати, оновлювати та налагоджувати інтеграцію;
- підтримка: місяць після запуску.
Типова інтеграція займає 12–20 робочих днів. Інвестиції окупаються в середньому за 3–4 місяці за рахунок зниження помилок у даних.
Покроковий план впровадження
- Аудит ERP — вивчаємо документацію, доступність тестового середовища, версію API.
- Проєктування архітектури — обираємо протоколи, визначаємо маппінг полів.
- Реалізація модуля синхронізації — пишемо код з логікою ретраю та ідемпотентності.
- Інтеграційне тестування — симулюємо реальні сценарії (зміна ціни, створення товару).
- Навантажувальне тестування — перевіряємо на 10 000+ записів.
- Деплой та моніторинг — налаштовуємо алерти, логування, дашборди.
- Навчання команди — передаємо документацію, проводимо воркшоп.
Приклад інтеграції з Odoo
Для Odoo використовуємо xmlrpc.client (Python). Приклад конектора:
import xmlrpc.client class OdooConnector: def __init__(self, url, db, username, password): self.url = url self.db = db # Аутентифікація common = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/common') self.uid = common.authenticate(db, username, password, {}) self.models = xmlrpc.client.ServerProxy(f'{url}/xmlrpc/2/object') def get_products(self, since: datetime = None): domain = [['active', '=', True]] if since: domain.append(['write_date', '>', since.isoformat()]) return self.models.execute_kw( self.db, self.uid, self.password, 'product.template', 'search_read', [domain], {'fields': ['id', 'name', 'default_code', 'list_price', 'qty_available', 'categ_id', 'description_sale']} ) Обробка змін
class ERPSyncService: def sync_products(self): last_sync = SyncState.get_last_sync('erp_products') products = self.erp.get_products(since=last_sync) updated = 0 for erp_product in products: product, created = Product.objects.update_or_create( erp_id=erp_product['id'], defaults={ 'name': erp_product['name'], 'sku': erp_product.get('default_code', ''), 'price': erp_product['list_price'], 'stock': erp_product['qty_available'], 'category': self.map_category(erp_product['categ_id']), } ) updated += 1 SyncState.update_last_sync('erp_products', datetime.now()) return updated Типові помилки та їх усунення
При синхронізації часто виникають проблеми: ігнорування кешу (після оновлення ціни сайт показує стару — перевірте кеш на рівні HTTP або CDN, інвалідуйте через purge), відсутність ідемпотентності (повторний запит не повинен створювати дублікати — використовуйте update_or_create та унікальні ключі), а також розрив з'єднання (налаштуйте retry-механізм з exponential backoff: перша спроба через 1 с, потім 2 с, 4 с, до 5 повторень, усі помилки логуються, критичні — алерт у Telegram).
Терміни та окупність
Інтеграція з конкретною ERP через API з двосторонньою синхронізацією: 12–20 робочих днів залежно від якості документації та доступності тестового середовища ERP. Вартість розраховується індивідуально після аудиту. За 10+ років ми виконали понад 50 подібних інтеграцій — це дозволило нам оптимізувати процес і знизити кількість помилок на етапі тестування на 95%. Середня економія від впровадження — 2 млн грн на рік на великому каталозі.
Готові оцінити вашу ERP за один день? Зв'яжіться з нами — підберемо оптимальну архітектуру. Отримайте консультацію інженера, який уже реалізовував синхронізацію для SAP, Odoo та 1С.