Границы интеграции сайта и ERP: что синхронизировать, а что оставить вручную

Границы интеграции сайта с ERP — это перечень данных и операций, которые системы обменивают автоматически, и перечень того, что сознательно остаётся внутри одной системы. Для каждой сущности нужно заранее назвать владельца, направление обмена и правило конфликта. Определить это до разработки дешевле, чем разбираться с расхождениями цен, остатков и заказов после запуска. Ниже — как зафиксировать границы, какие данные отдаёт ERP, что возвращает сайт, как ведёт себя витрина при недоступности учётной системы и по каким критериям принимать работу.

Зачем очерчивать границы интеграции сайта с ERP

ERP — это учётная система: в ней живут номенклатура, цены, остатки, документы и взаиморасчёты. Сайт — канал продаж: он показывает товар, принимает заказ, проводит оплату. Пока системы не связаны, каждая живёт по своим правилам, и расхождения незаметны. Как только появляется обмен, любое поле с двумя владельцами начинает «перетягивать» значение то в одну, то в другую сторону.

Границы интеграции фиксируют владельца каждого поля и правило разрешения конфликтов. Без этого возникают типичные сбои: правка описания на сайте затирается выгрузкой из ERP; цена в ERP обновляется, а на витрине остаётся старой; заказ, оформленный при недоступности учётной системы, теряется. Эти проблемы возникают не из-за ошибок кода, а из-за отсутствия описанных границ.

Практический смысл границ в том, что они превращают интеграцию из бесконечной отладки в управляемый список договорённостей. Дальше разберём, как этот список составить, какие данные ERP отдаёт сайту, что сайт возвращает обратно, как ведёт себя витрина при сбое и по каким критериям принимать работу.

Карта границ систем: что зафиксировать до разработки

Основной рабочий документ — карта границ систем. Это таблица, где для каждой сущности указано, какая система является источником истины, в каком направлении идут данные, с какой периодичностью, что делать при конфликте и что показывать пользователю при недоступности второй системы.

Состав карты

Минимальный набор колонок карты границ:

• сущность (товар, цена, остаток, заказ, статус);
• владелец данных (ERP или сайт);
• направление обмена (ERP → сайт, сайт → ERP, двустороннее);
• триггер обновления (по расписанию, по событию, вручную);
• правило конфликта (приоритет источника);
• поведение при недоступности (что видит покупатель, статус данных).

Пример заполненной карты для типового магазина:

Кто заполняет и согласует

Карту нельзя составить силами только разработчика. Владельца данных по ценам и остаткам подтверждает тот, кто отвечает за учёт; по описаниям и медиа — контент; по заказам — продажи. Итог согласуется один раз и дальше служит основанием для приёмки: если поведение системы расходится с картой, это дефект, а не «так исторически сложилось».

Какие данные ERP отдаёт сайту

Со стороны учётной системы на сайт обычно уходят номенклатура, цены, остатки, характеристики, изображения и файлы, а также пользовательские справочники. В терминах обмена это выгрузка товаров, цен и остатков, справочников, изображений и файлов характеристик.

Цены и остатки

Цены и остатки обновляются чаще описаний, поэтому их обмен настраивают отдельно. Это позволяет менять актуальные числа без перезаписи всей карточки товара. В некоторых конфигурациях выгружается не произвольный набор, а прайс-лист, привязанный к соглашению. Ошибка в настройке соглашения приводит к тому, что сайт получает некорректные цены или не получает их вовсе.

Описания и медиа

Описания, свойства и изображения меняются редко. Их логично обновлять реже, чем цены и остатки, и заранее решить, можно ли править их на сайте. Если да — нужно правило, по которому обмен не затирает ручные правки; если нет — правки на сайте запрещены, а все изменения вносятся в ERP. Этот пункт обязательно попадает в карту границ.

Как устроен типовой обмен сайта на Битрикс с 1С, разбирается в отдельном руководстве; здесь важно, что состав выгружаемых сущностей — это и есть граница «ERP → сайт».

Что сайт возвращает в ERP

Обратное направление обычно уже: заказы, данные контрагентов, статусы и сведения об оплате. В терминах обмена это обмен документами, выгрузка контрагентов и импорт заказов из интернет-магазина.

Заказы

Заказ — ключевая сущность обратного потока. Здесь нужно решить: попадает ли заказ в ERP сразу после оформления или после подтверждённой оплаты; что считается моментом фиксации; как обрабатывается заказ, оформленный при недоступности ERP. Ответ на последний вопрос — часть границ, а не деталь реализации.

Статусы и оплата

Статус заказа движется в обе стороны: сайт сообщает о новом заказе и об оплате, ERP возвращает статус обработки. Если статусы не синхронизированы, покупатель видит «ожидает оплаты» по уже отгруженному заказу. Оплата — отдельная зона: как устроена интеграция магазина с платёжными системами: онлайн-оплата и касса, зависит от платёжного провайдера, и её результат должен доходить до ERP в понятном виде.

Настройка обмена на стороне ERP: соглашение, отбор, прайс-листы

Часть границ задаётся не кодом, а настройками учётной системы. Их стоит проверить до того, как обсуждать доработки.

Соглашение и вид цен

В конфигурациях с привязкой цен к соглашению, именно оно определяет набор данных для сайта. Проверьте следующие параметры:

• сегмент клиентов пустой (условия для всех);
• соглашение действующее (без конечной даты);
• детализация расчётов «По заказам»;
• указан вид цен;
• активен флажок «Доступно для обмена с сайтом».

Если флажок отсутствует, его добавляют через доработку. Точный состав настроек зависит от конфигурации ERP, поэтому сверяйте их с официальной документацией.

Отбор номенклатуры

Что именно выгружать, задаётся в форме настройки отбора: там указывают номенклатуру, склады, соглашения и другие условия. Это ещё одна граница: товар, не попавший в отбор, на сайте не появится, и это не ошибка обмена, а следствие настройки. Перед запуском отбор стоит сверить с ассортиментом, который должен быть на витрине.

Порядок настройки обмена товарами и заказами подробно описан в материале Интеграция Битрикс с 1С: как настроить обмен товарами и заказами; здесь мы фиксируем, что соглашение и отбор — часть границ, а не техническая мелочь.

Работа сайта при недоступности ERP

ERP может быть недоступна: обновление, регламентные работы, сбой канала. Границы должны описывать это состояние заранее, иначе витрина либо продаёт то, чего нет, либо полностью перестаёт принимать заказы.

Варианты поведения витрины

• Показывать последние известные остатки и пометку о возможной неточности.
• Переводить товары в режим «под заказ» без обещания срока.
• Запрещать оформление по позициям с неизвестным остатком.
• Принимать заказы и ставить их в очередь на передачу в ERP.

Выбор зависит от типа товара и рисков продажи отсутствующего товара. Для штучных или скоропортящихся позиций безопаснее запрет оформления. Для услуг или товаров с длительным сроком поставки допустим приём в очередь. Решение фиксируется в карте границ и проверяется на тестовом контуре.

Что делать с заказами, принятыми в период недоступности

Заказ не должен теряться. Нужно правило: заказы сохраняются на сайте и передаются в ERP, когда связь восстановится, либо сразу уходят ответственному сотруднику. Отдельно фиксируется, как покупатель узнаёт о статусе. Это поведение проверяется до запуска, а не после первого сбоя.

Развилки: таблица принятия решения

Таблица помогает принять решение, но не заменяет карту границ: выбранный вариант переносится в неё как договорённость с владельцем и правилом конфликта.

Учебный пример: границы для магазина с двумя складами

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Интернет-магазин торгует инструментом, ассортимент — около двух тысяч позиций. Учёт ведётся в ERP, товар хранится на двух складах. Цены пересматриваются раз в неделю, остатки меняются в течение дня. Описания товаров пишет контент-менеджер на сайте. Заказы должны попадать в ERP, оплата — через платёжного провайдера.

Действия. Команда составляет карту границ: владелец цен и остатков — ERP, владелец описаний — сайт, заказы идут с сайта в ERP, статусы — из ERP на сайт. Цены и остатки обмениваются чаще, описания — реже и без перезаписи. Для периода недоступности ERP выбирают режим «под заказ» для позиций с неизвестным остатком и очередь для заказов. На тестовом контуре проверяют: изменение цены в ERP, изменение остатка, ручную правку описания на сайте, оформление заказа, оплату и возврат статуса.

Наблюдаемый результат. После обмена цена и остаток на витрине совпадают с ERP; ручная правка описания сохраняется; заказ появляется в ERP с корректным составом; статус оплаты отражается на сайте. При отключённой ERP витрина не продаёт позиции с неизвестным остатком, а оформленные заказы не теряются.

Проверка. Результат сверяют с картой границ по каждому пункту. Если поведение расходится — это дефект настройки или доработки, и его устраняют до запуска. Отдельно проверяют журнал обменов и журнал ошибок: в них видно, прошёл ли обмен и на чём остановился.

Как проверить результат и принять работу

• Карта границ систем заполнена и согласована владельцами данных.
• Для каждой сущности указан владелец и правило конфликта.
• Проверено, что обмен не затирает данные, которые должны оставаться на сайте.
• Настроены соглашение и отбор номенклатуры; выгружается нужный вид цен.
• Проверено поведение витрины при недоступности ERP.
• Заказы, оформленные в период недоступности, не теряются.
• Статусы заказов и оплат совпадают на сайте и в ERP.
• Журнал обменов и журнал ошибок доступны ответственному сотруднику.
• Проведена проверка на тестовом контуре до запуска на рабочем.
• Определён ответственный за мониторинг обмена после запуска.

Типичные ошибки и ограничения

• Два владельца у одного поля. Описание правят и на сайте, и в ERP — обмен затирает одну из версий.
• Обмен настроен, но границы не описаны. Формально всё работает, пока не случится сбой, и тогда непонятно, что должно было произойти.
• Проверка только на «счастливом пути». Тестируют успешный обмен, но не проверяют недоступность ERP, дубли контрагентов и ошибки в данных.
• Игнорирование журналов. Журнал обменов и журнал ошибок есть, но за ними никто не смотрит, и проблема обнаруживается по жалобе покупателя.
• Ожидание, что обмен решит всё. Часть процессов остаётся ручной, и это нормально, если граница описана.

Ограничения тоже стоит зафиксировать. Обмен не делает данные мгновенно согласованными: между выгрузками возможна задержка. Часть ошибок связана с качеством данных в ERP, а не с интеграцией. Настройки учётной системы могут требовать участия специалиста по ERP. Работа с персональными данными контрагентов — отдельная зона, которую сверяют с профильным специалистом, а не решают только техническими средствами.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужны:

• перечень сущностей и то, какая система ими владеет;
• частота изменения цен, остатков и описаний;
• список складов и правила расчёта доступного остатка;
• требования к заказам: момент передачи, обработка неоплаченных, статусы;
• поведение витрины при недоступности ERP;
• сведения о платёжном провайдере и о том, как результат оплаты должен попадать в ERP;
• ответственный за приёмку и за мониторинг после запуска.

Без этих данных оценка сводится к догадкам, а границы остаются неописанными. Следующий шаг — собрать карту границ и согласовать её с владельцами данных до начала работ.