Сквозная синхронизация сайт → CRM → склад

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

Что такое сквозная синхронизация и зачем она

Под сквозной синхронизацией понимают связку из трёх звеньев: сайт (1С-Битрикс) как витрина и точка приёма заказов, CRM (RetailCRM, Битрикс24, amoCRM) как место работы менеджеров, и складская/учётная система (МойСклад, 1С) как источник товародвижения и остатков. Каждое звено отвечает за свой участок и является мастером для определённого набора полей.

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

• Сайт → CRM — новые заказы, лиды, регистрации, корзины.
• CRM → склад — подтверждённые заказы, резервы, отгрузки.
• Склад → сайт — остатки, цены, новые товары каталога.
• CRM/склад → сайт — статусы оплаты и доставки для личного кабинета.

Мастер данных: кто главный по каждому полю

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

Без такой матрицы возникают кольцевые перезаписи: сайт правит остаток, склад тут же возвращает свой, и значение мигает. Мастерство данных разрывает цикл.

Ключи сопоставления и идентификаторы

Чтобы заказ и товар «узнавались» в каждой системе, нужны устойчивые ключи сопоставления. Внутренний ID Битрикса в других системах бесполезен, поэтому в свойствах хранят внешние идентификаторы.

• Товар — артикул (CATALOG_XML_ID), внешний код склада, штрихкод. Артикул должен быть уникальным.
• Заказ — ID заказа Битрикса + ACCOUNT_NUMBER, а также внешний номер из CRM в свойстве заказа.
• Клиент — телефон в нормализованном формате (E.164), email, внешний ID контакта.

Для товаров, приходящих из склада, удобно писать внешний код в поле XML_ID элемента инфоблока — по нему стандартный обмен и находит совпадения. Для заказов заведите отдельное свойство, куда CRM запишет свой номер сделки, чтобы обратные статусы попадали в нужный заказ.

Архитектура обмена: точка-точка или через хаб

Есть две базовые топологии. Точка-точка — каждая пара систем связана напрямую (сайт↔CRM, CRM↔склад). Через хаб — центральным узлом выступает одна система (чаще CRM), через которую проходит весь трафик.

Для розницы на 1С-Битрикс чаще всего оптимальна схема с CRM в роли хаба: сайт передаёт заказ в RetailCRM или Битрикс24, а уже CRM обменивается со складом. Так менеджер видит единую картину, а склад не завязан на каждый источник заказов по отдельности.

Порядок и расписание обменов

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

1. Каталог и цены — реже (раз в час или по событию), тяжёлый обмен.
2. Остатки — часто (каждые 5–15 минут), лёгкий обмен только по изменённым позициям.
3. Заказы сайт → CRM — по событию оформления, near-real-time через агент или очередь.
4. Статусы CRM → сайт — по событию смены статуса.

В 1С-Битрикс регулярные задачи вешают на агентов или на системный cron через /bitrix/php_interface/cron_events.php. Для near-real-time лучше использовать очередь и обработку заданий, а не тяжёлые агенты на хите.

Идемпотентность и защита от дублей

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

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

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

Итог

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

Мы в B2Bsite проектируем такие цепочки под конкретный бизнес: определяем мастеров данных, выбираем топологию (чаще с CRM в роли хаба), настраиваем расписания и защиту от дублей, добавляем мониторинг. Если у вас несколько систем и данные периодически расходятся — поможем собрать их в единый управляемый контур.