Интеграция интернет-магазина с 1С и ERP

Главная задача интеграции — не просто заставить две системы передавать друг другу данные. Нужно определить, какая система за что отвечает.

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

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

Поэтому универсальной интеграции «сайта с 1С» не существует. Есть конкретный бизнес-процесс, который необходимо связать с конкретными системами.

Состав обмена зависит от проекта. Чаще всего интеграция затрагивает:

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

На практике обмен часто двусторонний.

Например, из ERP интернет-магазин получает ассортимент, цены и остатки. С сайта обратно передаются заказы и данные покупателей. Затем ERP меняет статус заказа — и новое состояние должно вернуться в личный кабинет клиента.

Возникает цепочка:

Один из ключевых вопросов при проектировании интеграции — где находится эталонная версия каждой сущности.

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

Для каждого типа данных желательно заранее определить master-систему.

Например:

Интеграция работает не только тогда, когда все системы доступны и данные корректны.

ERP может временно не отвечать. В передаваемом товаре может отсутствовать обязательное поле. API стороннего сервиса может вернуть ошибку. Соединение может оборваться посередине большого обмена.

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

Поэтому для интеграции нужно заранее определить:

Разные данные имеют разную чувствительность к задержке.

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

Поэтому интеграция может сочетать разные механизмы.

Часть данных передаётся в реальном времени через API или события. Часть синхронизируется по расписанию. Большие массивы могут обрабатываться пакетами.

Выбирать способ обмена стоит исходя не из принципа «чем быстрее, тем лучше», а из требований конкретного бизнес-процесса, объёма данных и допустимой задержки.

Для типового интернет-магазина на 1С-Битрикс и 1С часть обмена можно построить на стандартных механизмах платформ.

Но реальные проекты редко годами остаются полностью типовыми.

Появляются несколько складов, разные типы цен, B2B-клиенты, собственная логика резервирования, нестандартные статусы заказов, дополнительные свойства, внешние сервисы и внутренние правила обработки.

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

Начинаем с обследования текущих систем и процессов. Определяем участников обмена, источники данных, направления движения информации и критичные сценарии.

После этого описываем интеграционный контур и правила синхронизации. Только затем переходим к реализации.

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

Если интеграция внедряется в уже работающий интернет-магазин, отдельно планируем запуск. Новый обмен не должен внезапно остановить продажи или повредить существующие данные.

Факт «данные передаются» сам по себе ещё не означает, что задача решена.

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

Для самой интеграции также важны технические показатели: количество успешных и неуспешных обменов, задержка синхронизации, число повторных попыток и время восстановления после ошибки.

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

Для проектирования интеграции нам нужно понимать не только техническую конфигурацию систем.

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

Полезны доступ к документации и тестовым средам, описание текущих обменов, примеры реальных данных и возможность общаться со специалистами, которые отвечают за 1С или ERP.

Если документация неполная, это не обязательно блокирует проект. Существующую интеграцию и бизнес-логику можно обследовать отдельно.

Результат интеграции — не сам факт соединения сайта с 1С или ERP.

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

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

А хорошо спроектированная интеграция остаётся управляемой и тогда, когда одна из систем временно недоступна или бизнес-процесс становится сложнее.