Интеграция сайта с 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.