1С, Битрикс24 и B2B-портал: архитектура без дублей и споров о данных
Содержание
Когда в компании три системы (учёт в 1С, продажи в Битрикс24 и заказы дилеров на портале), их обычно связывают по мере появления. Сначала портал с 1С, потом 1С с Битрикс24, потом кто-то просит, чтобы заказы портала были видны в CRM, и появляется третья связка. Каждая сделана своим подрядчиком, по своим правилам.
Через полгода у одного клиента три карточки с разными реквизитами, закрытая сделка не соответствует отменённому заказу, а при любой ошибке три подрядчика указывают друг на друга. Разберём, как построить архитектуру, в которой этого не происходит.
Почему попарные интеграции ломаются
- Разные правила. Каждая связка по-своему понимает, что такое клиент, заказ и статус.
- Дубли. Одно изменение передаётся несколькими путями и приходит дважды.
- Циклы. Системы обновляют друг друга по кругу: 1С обновила контрагента, Битрикс24 принял изменение и отправил обратно, 1С снова приняла.
- Нет единого журнала. Ошибку невозможно отследить от начала до конца.
- Рост сложности. Добавление четвёртой системы, например МойСклад или сервиса доставки, удваивает число связей.
- Размытая ответственность. Никто не отвечает за стык между системами.
Принцип одного источника
Основа архитектуры: у каждого объекта ровно одна система, которая считается главной. Остальные получают копию и не меняют её самостоятельно.
| Объект | Главная система | Кто получает | Кто может инициировать изменение |
|---|---|---|---|
| Номенклатура, цены, остатки | 1С | портал, Битрикс24 | только 1С |
| Контрагенты, договоры, лимиты | 1С | портал, Битрикс24 | Битрикс24 создаёт заявку на нового клиента |
| Лиды, сделки, задачи | Битрикс24 | портал при необходимости | Битрикс24 |
| Заказы дилеров | портал создаёт, 1С учитывает | Битрикс24 видит | портал, затем статусы из 1С |
| Статусы, документы, оплаты | 1С | портал, Битрикс24 | только 1С |
Это пример. Конкретное распределение зависит от процессов компании. Например, если клиентов заводит отдел продаж, главным для новых контрагентов может быть Битрикс24 до момента заключения договора. Главное, чтобы правило было записано и соблюдалось.
Интеграционный слой
Вместо связей «каждый с каждым» все системы подключаются к одному сервису. Он:
- принимает изменения из любой системы;
- проверяет их и приводит к общей модели данных;
- раздаёт другим системам по правилам;
- защищает от дублей и циклов;
- ведёт журнал всех операций со сквозным номером;
- проводит ежедневную сверку;
- уведомляет ответственного об ошибках.
| Без интеграционного слоя | С интеграционным слоем |
|---|---|
| 3 связки при 3 системах, 6 при 4 | по одной связке на систему |
| свои правила в каждой связке | одна модель данных |
| ошибки ищут в трёх местах | один журнал |
| новая система затрагивает все | новая система подключается отдельно |
Как избежать циклов
- Метка источника. У каждого изменения есть отметка, откуда оно пришло, и система не отправляет обратно то, что только что получила.
- Сравнение состояния. Если новое значение совпадает с текущим, изменение не передаётся.
- Права на запись. Система, которая не является главной для объекта, не может менять его поля.
- Журнал. Позволяет увидеть повторяющуюся цепочку и остановить её.
Пример: жизнь одного заказа
- Дилер оформляет заказ на портале.
- Интеграционный слой присваивает заказу номер операции и создаёт заказ в 1С с резервом.
- Одновременно в карточке клиента в Битрикс24 появляется событие, а для крупного заказа сделка у менеджера.
- Заказ превысил лимит: в Битрикс24 создаётся задача на согласование.
- Менеджер согласует, результат возвращается в портал и в 1С.
- Склад отгружает, 1С меняет статус, портал и CRM получают обновление.
- Оплата поступает в 1С, сделка закрывается, дилер видит закрытие в кабинете.
Каждый шаг записан в журнале, и через месяц можно восстановить, что и когда произошло.
Пошаговый переход с попарных связок
- Описать текущие связи и известные проблемы.
- Составить единую карту данных и согласовать её с продажами и бухгалтерией.
- Запустить интеграционный слой для одного потока, обычно заказов, параллельно со старой связкой.
- Сверить результаты старой и новой схемы.
- Перевести остальные потоки по очереди: справочники, статусы, оплаты.
- Отключить старые связки.
- Настроить мониторинг и ежедневную сверку.
Такой переход не останавливает работу компании ни на день.
Частые вопросы
Это не слишком сложно для средней компании?
Если систем три и больше, интеграционный слой упрощает жизнь, а не усложняет её: меньше связей, один журнал, один ответственный.
Можно ли использовать готовую шину данных?
Да, но её всё равно нужно настраивать под вашу модель данных, писать коннекторы и поддерживать.
Что если завтра добавится МойСклад или маркетплейс?
С интеграционным слоем новая система подключается как ещё один источник или получатель, без переделки остальных.
Где физически работает интеграционный слой?
На отдельном сервере компании или в облаке. Он должен быть доступен и для 1С, и для облачного Битрикс24.
Кто отвечает за интеграцию после запуска?
Один подрядчик по договору поддержки или внутренний специалист, которому передана документация и журнал.
Можно ли оставить штатный обмен 1С и Битрикс24, а портал подключить через слой?
Можно на переходный период, но со временем лучше перевести и этот обмен в слой, чтобы иметь один журнал и одну модель данных.
