Інтеграція ERP з сайтом: синхронізація замовлень та товарів

Ми пропонуємо розробку інтеграцій ERP із сайтами, які автоматизують обмін даними між обліковою системою та інтернет-магазином. Кожен день без такої синхронізації — це ручне введення замовлень, помилки в цінах і втрачені продажі. За статистикою, до 60% даних вводяться з помилками, а на звірення залишків іде до 20 годин на місяць. Наша команда має 8-річний досвід в інтеграціях і реалізувала понад 50 проектів для 1С, SAP та Odoo.

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

Як дані синхронізуються між сайтом та ERP?

Прямі синхронні запити сайту до ERP — антипатерн. ERP не проєктувалися для обробки сотень HTTP-запитів на хвилину від користувачів сайту. Стандартна схема включає проміжний шар:

Користувач сайту
    ↓
Сайт (сервер)
    ↓
Кеш / БД сайту ← [Синхронізація] ← ERP
    ↓
Відповідь користувачеві (швидко, без звернення до ERP)

Критичні для користувача дані (ціни, залишки, каталог) кешуються в БД сайту та оновлюються з ERP за розкладом або через webhook. Транзакційні дані (замовлення) передаються в ERP через чергу. Такий підхід знижує навантаження на ERP на 80% порівняно з прямими викликами — це покращує показники відмовостійкості та швидкості відповіді сайту.

Типи інтеграції за напрямом

ERP → Сайт (майстер даних):

• Номенклатура, характеристики, ієрархія категорій
• Актуальні ціни (базові + для конкретних клієнтів)
• Залишки по складах
• Контрагенти (для B2B-порталів)

Сайт → ERP (транзакції):

• Замовлення покупців
• Дані нових клієнтів / оновлення контактів
• Оплати та повернення

ERP → Сайт (зворотний зв'язок):

• Статуси замовлень (прийнято до виконання, відвантажено, закрито)
• Виставлені документи (рахунки, накладні)
• Кредитні ліміти та стан рахунку (для B2B)

Формати та протоколи

Чому потрібен middleware?

Для великих інтеграцій рекомендується виділений middleware-сервіс:

Сайт API → Middleware (Go/Node.js) → ERP
                  ↕
             Черга (RabbitMQ/Kafka)
                  ↕
           Моніторинг + ретраї

Middleware відповідає за: трансформацію форматів, маршрутизацію, retry при помилках, батчинг запитів (важливо для ERP з лімітами на кількість викликів), логування всіх обмінів. Без middleware кожна помилка мережі призводить до втрати замовлення — з чергою гарантується доставка навіть після пауз.

Прямі запити до ERP через інтернет знижують надійність у 3–5 разів порівняно з асинхронною чергою через middleware. Крім того, middleware дозволяє обробляти тисячі замовлень на годину без блокувань ERP.

Порівняння підходів: пряма інтеграція vs middleware

Помилки та reconciliation

У будь-якій інтеграції бувають розбіжності: замовлення створено на сайті, але не потрапило в ERP через помилку мережі. Потрібен механізм reconciliation — періодична перевірка узгодженості даних:

-- Знайти замовлення на сайті, що не мають запису в ERP
SELECT o.id, o.created_at
FROM orders o
WHERE o.erp_sync_status != 'synced'
  AND o.created_at < NOW() - INTERVAL '10 minutes'
  AND o.status = 'confirmed'
ORDER BY o.created_at

Стандартизація перед інтеграцією

Перед початком розробки необхідно провести аналітику:

• Які об'єкти ERP братимуть участь в обміні
• Маппінг полів: поле сайту ↔ поле ERP (з типами даних та обмеженнями)
• Правила дедуплікації (як пов'язати клієнта сайту з контрагентом ERP)
• Частота та обсяг обмінів
• SLA: допустима затримка синхронізації

Що входить у роботу

До складу робіт входить: аналіз поточної системи, проєктування схеми обміну, реалізація middleware (якщо потрібно), налаштування моніторингу, документування, навчання співробітників і гарантійна підтримка протягом місяця після запуску. Замовте інтеграцію ERP із сайтом під ключ — ми проведемо аудит, спроєктуємо та реалізуємо обмін даними. Для точної оцінки та старту отримайте консультацію нашого інженера.

Термін розробки: від 6 до 16 тижнів залежно від системи, обсягу даних та складності трансформацій.

Як уникнути типових помилок при інтеграції?

• Відсутність дедуплікації контрагентів — клієнти заводяться багаторазово.
• Спроба синхронізувати всі поля «на льоту» — призводить до таймаутів.
• Ігнорування різниці у форматах дат та чисел.
• Немає механізму повтору при тимчасових помилках мережі.
• Забувають налаштувати моніторинг — про розбіжність дізнаються від клієнта.

Ці помилки збільшують вартість володіння інтеграцією на 40% відносно правильно спроєктованого рішення. Зв'яжіться з нами, і ми покажемо, як їх уникнути.

Як вирішити проблеми синхронізації з 1С?

Ранок понеділка. Менеджер відкриває сайт і бачить, що позицію, яку розпродали в п'ятницю, досі «в наявності». Три клієнти вже оплатили товар, якого немає. Ми стикаємося з цим болем регулярно: відсутність синхронізації між 1С та інтернет-магазином б'є по грошах та репутації. Вирішуємо проблему під ключ — налаштовуємо обмін так, щоб облікова система та вітрина оновлювалися синхронно, без втрати даних та з гарантією консистентності. Після нашої інтеграції один із клієнтів скоротив кількість повернень на 50% і зекономив понад 20 000 грн за перший місяць.

1С — облікова система більшості українських компаній. Сайт — вітрина. Вони мають говорити однією мовою і робити це регулярно, надійно та без втрати даних. Наш досвід — понад 50 успішних інтеграцій для замовників з каталогами від 500 до 200 000 SKU.

Чому стандартний CommerceML не завжди рятує?

CommerceML — стандартний протокол обміну, який підтримують 1С:Управління торгівлею, 1С:Комплексна автоматизація та ряд інших конфігурацій. WooCommerce, Shopify та інші CMS мають плагіни для роботи з CommerceML (наприклад, «1С-Бітрікс» для своїх продуктів, окремі плагіни для WordPress). Потік: 1С ініціює обмін → надсилає ZIP-архів з XML на endpoint сайту → сайт розбирає, оновлює каталог.

Формат CommerceML — XML зі своєю схемою: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. Категорії, товари, характеристики, зображення, ціни, залишки. Головна складність — ієрархія характеристик в 1С та атрибути товарів на сайті не завжди збігаються один до одного. Потрібен мапінг. Для глибокого розуміння протоколу рекомендуємо документацію Wikipedia — там розглянуто всі нюанси схеми.

Як ми обходимо обмеження CommerceML

Для нестандартних конфігурацій 1С або коли CommerceML не підходить — пишемо HTTP-сервіс в 1С (вбудована можливість починаючи з версії 8.3) і взаємодіємо через REST JSON. Це дає повний контроль над структурою даних та частотою синхронізації, але вимагає розробки з боку 1С-програміста.

Для enterprise-завдань з кількома обліковими системами — Message Broker (RabbitMQ, Apache Kafka) як посередник. 1С публікує події в чергу, сайт підписується і обробляє. Гарантована доставка, буферизація при недоступності однієї зі сторін.

Що синхронізуємо і як

Каталог (товари, категорії, характеристики). Найоб'ємніша частина. Повне вивантаження при першому запуску, дельта-оновлення в подальшому. При імпорті CommerceML: парсимо XML через PHP SimpleXML або XMLReader (для великих файлів — тільки XMLReader, інакше memory limit). Зіставляємо товари за GUID з 1С, який зберігаємо в окремому полі БД. Якщо товар видалено в 1С — приховуємо на сайті, не видаляємо (історія замовлень може посилатися).

Залишки та ціни — окремий ПакетПредложений в CommerceML, оновлюється частіше каталогу. Критично робити атомарно: не оновлювати залишок по одному, а транзакцією. Інакше в момент оновлення користувач може побачити неконсистентний стан. Частота: раз на годину для спокійного режиму, раз на 5–15 хвилин для активної торгівлі.

Замовлення — двосторонній обмін. Сайт → 1С: нове замовлення передається з номенклатурою, кількістю, цінами, контактними даними покупця. 1С → сайт: статус замовлення (оплачено, зібрано, відвантажено, доставлено). Для передачі замовлень — або той же CommerceML (блок Документи), або прямий REST-виклик при створенні замовлення на сайті.

Типові проблеми, які вирішуємо

Дублювання товарів. 1С-оператор створив позицію з помилкою в артикулі, потім виправив. На сайті — два товари. Рішення: зіставлення за GUID з 1С (не за артикулом), GUID незмінний.

Кирилиця в XML та кодування. 1С історично працює з Windows-1251. CommerceML файл може прийти в CP1251, PHP очікує UTF-8. mb_convert_encoding() або iconv() в перших рядках парсера — обов'язково.

Тайм-аути при великому вивантаженні. Каталог з 100 000 позицій — це 50–200MB XML. PHP default execution time 30s не вистачить. Рішення: CLI-команда (Laravel Artisan або Symfony Console), запускається через cron, без HTTP timeout. Або chunked processing через XMLReader з частковими комітами в БД. Для обробки великих масивів даних використовуємо LazyCollection в Laravel — це дозволяє тримати в пам'яті лише один чанк.

Зображення. 1С може передавати зображення Base64 всередині XML (роздуває файл в 1.3 рази) або посиланнями на файли. Другий варіант кращий. Скачуємо асинхронно, конвертуємо в WebP, кладемо в медіабібліотеку.

Кейс: інтернет-магазин запчастин, 85 000 SKU

Синхронізація через CommerceML кожні 30 хвилин. Проблема: повне вивантаження займало 18 хвилин, в результаті нове вивантаження починалося, поки старе ще йшло. Рішення: lock через Redis (SET nx ex), дельта-вивантаження (тільки змінені позиції за останні 2 години через фільтр в 1С), обробка через чергу з 20 паралельними workers. Час синхронізації: 18 хвилин → 2.5 хвилини, конфліктів немає. Економія ресурсів сервера — до 40% навантаження CPU.

Як відбувається синхронізація даних з 1С?

Порівняння методів інтеграції

CommerceML в типових сценаріях швидше REST для синхронізації каталогу в 2-3 рази за рахунок бінарної упаковки XML та компактного формату. Однак, якщо потрібна кастомна логіка обміну, REST дає повну гнучкість.

Процес і терміни

Покроковий алгоритм налаштування інтеграції:

1. Аудит конфігурації 1С (версія, тип конфігурації, можливості вивантаження).
2. Проектування мапінгу даних — узгодження полів 1С та атрибутів сайту.
3. Розробка приймача на сайті та відправника в 1С (плагін або кастомний модуль).
4. Тестування на реальних даних: вивантаження каталогу, перевірка залишків, створення тестового замовлення.
5. Налаштування розкладу синхронізації (cron, черги) та моніторингу перших обмінів.
6. Документування схеми мапінгу та логіки обробки помилок.

Участь 1С-програміста з боку клієнта — обов'язково, або ми залучаємо перевіреного спеціаліста. Замовте аудит вашої системи обліку — ми оцінимо складність інтеграції за один робочий день.

Що входить в результат (deliverables)

• Документація: схема мапінгу, формати даних, логіка обробки помилок.
• Налаштований розклад синхронізації з логами виконання.
• Доступ до моніторингу (Grafana/ELK — за домовленістю).
• Навчання менеджерів: як запускати ручний обмін, як читати логи.
• Гарантійна підтримка після запуску — 2 тижні (виправлення інцидентів).

Отримайте консультацію

Вартість інтеграції розраховується індивідуально після аудиту — залиште заявку на консультацію. Зв'яжіться з нами, щоб отримати детальний план інтеграції для вашого бізнесу. Понад 7 років досвіду в інтеграціях з 1С — гарантуємо стабільну синхронізацію без сюрпризів.