Вернуться к статьям Покупатель добавляет товар в корзину, оформляет заказ, а менеджер выясняет, что позиции уже нет на складе или цена изменилась. Другой частый сценарий — карточка товара на сайте заполнена вручную, а в учётной системе она выглядит иначе: отличаются артикул, характеристики, варианты и изображения. Причина обычно не в корзине, а в том, что интернет-магазин и ERP работают с разными версиями данных.
Интеграция интернет-магазина с ERP определяет источник данных для каталога и заказов, правила передачи изменений и действия при сбоях. Сам обмен не гарантирует корректность информации: сначала нужно сопоставить сущности в обеих системах и зафиксировать правила их обработки.
Интеграция интернет-магазина с ERP: что передавать
Состав обмена зависит от модели продаж. Для каталога обычно рассматривают наименования, артикулы, категории, характеристики, варианты товара, изображения, цены и доступность. Для заказов — состав корзины, выбранные параметры, данные покупателя, способ получения, комментарий и статус обработки.
Данные не обязательно передавать в обе стороны. ERP может быть источником остатков и цен, а тексты карточек, подборки и редакционные изображения ведутся на сайте. Заказ, созданный в интернет-магазине, передаётся в ERP; изменение статуса при необходимости возвращается на сайт.
Полезно подготовить таблицу с полями, источником, направлением обмена, правилом обновления и ответственным за данные. Она помогает обнаружить спорные точки до начала настройки: разные артикулы, несколько цен у одной позиции, товары без остатка, комплекты и варианты.
Синхронизация ассортимента интернет-магазина и ERP
Ассортимент редко выглядит как простой перечень товаров. В каталоге встречаются варианты по размеру, цвету или комплектации, товары под заказ, комплекты, сопутствующие услуги и архивные позиции. ERP и сайт могут описывать эти объекты по-разному, поэтому для настройки нужны реальные примеры карточек, а не несколько типовых позиций из выгрузки.
Отдельное правило требуется для товара, который исчез из учётной системы. Его можно скрыть, сделать недоступным для заказа или оставить в каталоге без возможности покупки. Такой же вопрос возникает при смене категории, артикула или состава варианта. Без зафиксированного порядка очередной обмен способен создать дубли, пустые карточки или неверные связи между товарами.
Структура учёта и структура витрины могут не совпадать. В ERP товар иногда относится к одной классификации, а на сайте участвует в нескольких разделах и подборках. Для таких случаев отдельно описывают, какие связи создаёт обмен, а какие поддерживаются редактором сайта.
Выгрузка остатков из ERP в интернет-магазин
Остаток не всегда сводится к одному числу. В правилах проекта определяют, учитывается ли конкретный склад, резерв, товар в пути, доступность под заказ или внутреннее ограничение на продажу. После этого становится понятно, какой показатель увидит покупатель и откуда он берётся.
Следующий вопрос — поведение сайта при отсутствии товара. Для одной категории подходит запрет на добавление в корзину, для другой требуется возможность оставить запрос. У товаров с вариантами доступность проверяют для выбранного варианта, а не для общей карточки.
Расхождения возможны, если заказ создан между обновлениями, сотрудник изменил данные в ERP или товар резервируется по отдельному порядку. Для таких заказов нужен рабочий сценарий: кто видит расхождение, как корректируется состав и какая информация остаётся у покупателя.
Обмен ценами между ERP и интернет-магазином
Цена может зависеть от типа покупателя, единицы измерения, варианта товара, комплекта или условий сделки. Формулировка «выгружать цены» не описывает обмен. Нужно определить используемые виды цен, правила отображения и источник каждого значения.
Отдельно согласуют ручное редактирование. Если менеджер изменил цену на сайте, следует определить, сохранится ли она после следующей выгрузки. При двухстороннем редактировании заранее выбирают приоритет систем и порядок разрешения конфликтов.
На тестовых данных проверяют округление, валюты, цены вариантов и комплектов, а также позиции без цены. Это позволяет увидеть несоответствия модели данных до передачи рабочих заказов.
Передача заказов из интернет-магазина в ERP
Заказ включает состав товаров, контакты покупателя, адрес или точку выдачи, комментарий, способ получения, скидку, комплекты и параметры вариантов. Для каждого поля определяют, передаётся ли оно, куда попадает в ERP и как обрабатывается ситуация, когда подходящего поля в учётной системе нет.
Особого внимания требуют статусы. Сайт и ERP могут использовать разные этапы, а одинаковые названия не всегда обозначают одно действие. Техническое получение заказа, проверка сотрудником и передача в доставку — разные события. Их лучше сопоставлять по условиям смены статуса и видимости для покупателя, а не по названию.
Нужен сценарий повторной отправки. Если ERP временно не приняла заказ, сотрудник должен увидеть ошибку и проверить, не создался ли документ частично или повторно.
Выбор способа интеграции с ERP
Способ обмена выбирают после описания данных и ограничений. В одном проекте достаточно регулярной передачи каталога и заказов, в другом учитывают изменения по событиям, несколько складов или отдельный маршрут для заказов под заказ.
При обсуждении работ уточняют источник каждого типа данных, правила сопоставления товаров, вариантов, категорий и цен, действия при удалении или объединении позиций, место фиксации ошибок и допустимые ручные операции на сайте. Также заранее определяют порядок проверки изменений после обновления ERP или доработки каталога.
Если сайт работает на «1С-Битрикс: Управление сайтом», это CMS интернет-магазина. ERP остаётся учётной системой, а CRM — отдельным контуром для работы с клиентами. Их данные и правила обмена описывают раздельно.
Проверка интеграции интернет-магазина и ERP
Обмен проверяют на наборах, близких к рабочим: товар с вариантами, отсутствующая позиция, товар без изображения, комплект, несколько цен, отменённый заказ, изменение остатка после добавления в корзину. Для каждого сценария фиксируют ожидаемый результат в ERP и на сайте.
Отдельный перечень составляют для ошибок: недоступна принимающая система, не найден товар, не передалась характеристика, заказ уже существует, цена изменилась во время оформления. У сотрудников должен быть способ заметить такую ситуацию без ручного сравнения всего каталога.
Для приёмки нужны проверяемые правила обмена и ожидаемые результаты по каждому сценарию. Тогда изменения в ассортименте, ценах и внутренних процессах можно сопоставить с исходными договорённостями.
Часто задаваемые вопросы
- Как понять, какие данные должны идти из ERP на сайт?
Перечислите данные каталога и заказа, затем укажите владельца каждого поля: ERP, сайт или ручной процесс. Если поле редактируется в двух системах, заранее выбирают приоритет и правило разрешения конфликтов.
- Можно ли редактировать товары на сайте после настройки обмена?
Можно, если это предусмотрено правилами проекта. Следует разделить поля, которые ERP перезаписывает при обмене, и данные редактора сайта: например, описания, подборки или изображения. Иначе изменения могут исчезнуть после синхронизации.
- Что делать, если в ERP нет товара, который есть на сайте?
Сценарий зависит от назначения карточки: её скрывают, показывают как недоступную, оставляют для запроса или сохраняют как страницу каталога. Отдельные правила задают для удалённых, архивных и временно отсутствующих товаров.
- Как избежать дублей заказов при повторной отправке?
Для заказа нужен идентификатор, по которому ERP и сайт распознают одну операцию. Также определяют, где отображаются неуспешные отправки и кто проверяет создание документа перед повторной передачей.
- Какие примеры подготовить для проверки обмена?
Подойдут реальные товары с вариантами, разными остатками и ценами, позиции без наличия, комплекты, товары с неполными характеристиками. Для заказов используют несколько товаров в корзине, отмену и нестандартный способ получения.