Интеграция ERP-системы с сайтом
ERP-интеграция — категория задач, а не одна конкретная реализация. Под ERP понимают 1С:ERP, SAP, Microsoft Dynamics, Oracle NetSuite, Odoo, Epicor и десятки других систем. Каждая имеет свою архитектуру API, форматы данных и модели безопасности. Тем не менее подходы к интеграции сайта с любой ERP следуют общим принципам.
Общая архитектура
Прямые синхронные запросы сайта к ERP — антипаттерн. ERP не проектировались для обработки сотен HTTP-запросов в минуту от пользователей сайта. Стандартная схема включает промежуточный слой:
Пользователь сайта
↓
Сайт (сервер)
↓
Кеш / БД сайта ← [Синхронизация] ← ERP
↓
Ответ пользователю (быстро, без обращения к ERP)
Критичные для пользователя данные (цены, остатки, каталог) кешируются в БД сайта и обновляются из ERP по расписанию или через webhook. Транзакционные данные (заказы) передаются в ERP через очередь.
Типы интеграции по направлению
ERP → Сайт (мастер данных):
- Номенклатура, характеристики, иерархия категорий
- Актуальные цены (базовые + для конкретных клиентов)
- Остатки по складам
- Контрагенты (для B2B-порталов)
Сайт → ERP (транзакции):
- Заказы покупателей
- Данные новых клиентов / обновления контактов
- Оплаты и возвраты
ERP → Сайт (обратная связь):
- Статусы заказов (принято к исполнению, отгружено, закрыто)
- Выставленные документы (счета, накладные)
- Кредитные лимиты и состояние счёта (для B2B)
Форматы и протоколы
| ERP | Протокол | Формат |
|---|---|---|
| SAP | OData / RFC / SOAP | JSON / XML / IDoc |
| 1С любая | HTTP-сервисы / COM / CommerceML | JSON / XML |
| Odoo | JSON-RPC | JSON |
| MS Dynamics | OData (Dataverse) | JSON |
| Oracle NetSuite | SuiteTalk SOAP / REST | XML / JSON |
Промежуточный сервис (Middleware)
Для крупных интеграций рекомендуется выделенный middleware-сервис:
Сайт API → Middleware (Go/Node.js) → ERP
↕
Очередь (RabbitMQ/Kafka)
↕
Мониторинг + ретраи
Middleware отвечает за: трансформацию форматов, маршрутизацию, retry при ошибках, батчинг запросов (важно для ERP с лимитами на количество вызовов), логирование всех обменов.
Ошибки и 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: допустимая задержка синхронизации
Срок разработки: 6–16 недель в зависимости от системы, объёма данных и сложности трансформаций.







