Как интегрировать Bitrix24 с несколькими базами 1С

Интеграция одного Bitrix24 с несколькими базами 1С — типичная задача для компаний, которые выросли из простого учётного контура.

Например, у бизнеса могут быть:

• несколько юридических лиц;
• отдельные базы по филиалам;
• разные конфигурации 1С;
• отдельная база для торговли;
• отдельная база для производства;
• отдельная база для бухгалтерии;
• разные страны или регионы;
• несколько направлений бизнеса.

При этом коммерческий отдел хочет работать в одном Bitrix24.

Менеджеру неудобно разбираться:

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

Поэтому задача интеграции заключается не просто в подключении нескольких баз.

Нужно построить единую архитектуру, в которой Bitrix24 понимает:

какие данные получать из каждой 1С, куда отправлять конкретный заказ и как объединять результат в одной карточке клиента.

Разберём, как правильно спроектировать такую интеграцию.

Почему у компании появляется несколько баз 1С

Несколько баз могут возникнуть по разным причинам.

Несколько юридических лиц

Например, группа компаний работает через:

• торговую компанию;
• производственную компанию;
• сервисную компанию;
• отдельное юридическое лицо по другому региону.

Каждая организация ведёт свой учёт.

Разные филиалы

У компании есть подразделения:

• Алматы;
• Астана;
• Шымкент;
• Костанай.

Каждый филиал исторически ведёт отдельную базу.

Разные конфигурации

Например:

• 1С:Бухгалтерия;
• 1С:Управление торговлей;
• 1С:Комплексная автоматизация;
• производственная конфигурация;
• отраслевое решение.

Разные страны

Компания работает, например, в Казахстане и Узбекистане.

У каждой страны:

• свои юридические лица;
• свои учётные правила;
• своя база.

Историческая архитектура

Бизнес рос постепенно.

Новые направления создавали отдельные базы, и со временем их стало несколько.

Bitrix24 при этом внедряется как единая коммерческая система.

Главная задача — сделать несколько баз незаметными для менеджера

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

Он работает с клиентом.

В карточке сделки ему нужно видеть:

• товары;
• цены;
• остатки;
• юридическое лицо;
• заказ;
• оплату;
• отгрузку.

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

Идеальная логика выглядит так:

менеджер создаёт сделку → система определяет маршрут → заказ передаётся в нужную 1С → статусы возвращаются в Bitrix24.

Это называется маршрутизацией обмена.

С чего начинается проект

Интеграцию нескольких баз нельзя начинать с программирования.

Сначала необходимо составить карту систем.

Например:

Далее определяется:

• какие объекты хранятся в каждой базе;
• где находится основной справочник;
• какая база отвечает за заказ;
• где фиксируется оплата;
• где находится производство;
• откуда получать остатки.

Без этой карты легко получить дублирование и конфликт данных.

Шаг 1. Определить роль каждой базы 1С

Это основа архитектуры.

Например:

База №1 — торговая

Хранит:

• клиентов;
• номенклатуру;
• заказы;
• цены;
• остатки.

База №2 — производственная

Хранит:

• производственные заказы;
• спецификации;
• этапы;
• готовность.

База №3 — бухгалтерская

Хранит:

• счета;
• оплаты;
• реализации;
• финансовые документы.

В этом случае Bitrix24 получает разные данные из разных источников.

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

Шаг 2. Определить основную систему для каждого объекта

Для каждого вида данных нужно назначить владельца.

Например:

Это предотвращает ситуацию, когда один и тот же объект редактируется в нескольких базах.

Шаг 3. Определить, куда отправлять заказ

Это главный вопрос многобазовой интеграции.

Маршрут может зависеть от:

• юридического лица;
• филиала;
• региона;
• товарной группы;
• типа клиента;
• валюты;
• склада;
• направления бизнеса.

Например:

Сделка из Алматы → база Алматы.

Или:

Товар собственного производства → производственная база.

Перепродажный товар → торговая база.

Или:

Клиент из Казахстана → база KZ.

Клиент из Узбекистана → база UZ.

Как хранить правило маршрутизации

В Bitrix24 можно использовать поля:

• юридическое лицо;
• филиал;
• направление;
• страна;
• тип заказа.

Интеграция считывает значение и определяет нужную базу.

Например:

Юридическое лицо = ТОО Profi Trade → 1С Trade.

Юридическое лицо = ТОО Profi Production → 1С Production.

Менеджеру не нужно выбирать технический адрес базы.

Он выбирает бизнес-параметр.

Шаг 4. Определить, где хранится клиент

Один клиент может покупать у нескольких компаний группы.

Возникает вопрос:

создавать одну карточку клиента в Bitrix24 или несколько?

В большинстве случаев удобнее:

один клиент в CRM + несколько реквизитов.

Например:

Компания:

ТОО «Альфа».

Внутри карточки есть отношения:

• с юридическим лицом №1;
• с юридическим лицом №2;
• с филиалом №3.

При передаче заказа интеграция использует нужные реквизиты.

Как связать одного клиента с несколькими базами

Можно хранить несколько идентификаторов.

Например:

• ID клиента в базе Алматы;
• ID клиента в базе Астана;
• ID клиента в бухгалтерской базе.

При первом обмене система создаёт или находит клиента в соответствующей базе и сохраняет связь.

Это позволяет избежать повторного поиска по названию.

Почему нельзя использовать только БИН

БИН — полезный идентификатор, но его не всегда достаточно.

Возможны ситуации:

• несколько договоров;
• разные филиалы;
• разные карточки по юридическим лицам;
• исторические дубли.

Поэтому лучше использовать:

БИН + внутренний ID связи.

После первого сопоставления основной становится сохранённая техническая связь.

Шаг 5. Определить источник товарного каталога

При нескольких базах товар может храниться:

• в одной общей базе;
• в каждой базе отдельно;
• в мастер-системе;
• в разных базах по направлениям.

Сценарий 1. Один общий каталог

Наиболее удобный вариант.

Одна 1С считается главным источником:

Master Catalog → Bitrix24.

Другие базы используют те же идентификаторы.

Сценарий 2. У каждой базы свой каталог

Сложнее.

Нужно определить:

• одинаковые ли товары;
• совпадают ли коды;
• отличаются ли характеристики;
• как объединить каталог в CRM.

Как объединять разные каталоги

Допустим:

в базе Алматы товар имеет код A001.

В базе Астана тот же товар — K547.

Bitrix24 должен понимать, что это одна коммерческая позиция.

Можно создать таблицу соответствий:

CRM Product ID → ID в базе Алматы → ID в базе Астана.

Так CRM выступает единым коммерческим представлением каталога.

Но поддержка такой таблицы требует дисциплины.

Шаг 6. Как синхронизировать цены из нескольких баз

Цены могут отличаться по:

• юридическому лицу;
• филиалу;
• региону;
• валюте;
• складу.

Например:

Алматы — 100 000 ₸.

Астана — 105 000 ₸.

Тогда CRM должна понимать контекст сделки.

Вариант 1. Цена зависит от юридического лица

Менеджер выбирает организацию.

CRM показывает соответствующий прайс.

Вариант 2. Цена зависит от филиала

Цена автоматически определяется по региону.

Вариант 3. Цена запрашивается динамически

Bitrix24 отправляет:

• товар;
• клиент;
• юридическое лицо;
• количество.

Нужная 1С возвращает цену.

Для сложных компаний это часто надёжнее постоянной синхронизации всех вариантов.

Шаг 7. Как показывать остатки из нескольких баз

Представим три склада:

• Алматы — база №1;
• Астана — база №2;
• Костанай — база №3.

В CRM можно показать:

Товар X

Алматы: 50
Астана: 25
Костанай: 10
Всего: 85

Менеджер получает единую картину.

Нужно ли суммировать все остатки

Не всегда.

Если филиалы работают независимо, общий остаток может ввести менеджера в заблуждение.

Например:

в Алматы товара нет.

В Астане есть 50 единиц.

Но компания не перемещает товар между филиалами.

Показать менеджеру:

Доступно: 50

будет неправильно.

Лучше:

Алматы: 0
Астана: 50

Поэтому значение остатка должно учитывать логистику бизнеса.

Шаг 8. Как передавать заказ при нескольких юридических лицах

В сделке должны быть определены:

• продавец;
• клиент;
• договор;
• валюта;
• склад.

После подтверждения заказа интеграция:

1. проверяет обязательные поля;
2. определяет нужную базу;
3. находит или создаёт клиента;
4. передаёт товары;
5. создаёт документ;
6. получает ID заказа;
7. сохраняет связь в Bitrix24.

В карточке сделки можно показывать:

База 1С: Trade KZ
Заказ: №000145
Юрлицо: ТОО Profi Trade

Шаг 9. Как получать оплаты из нескольких баз

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

Например:

сделка создана на 12 000 000 ₸.

Оплата может поступить в базу соответствующего юридического лица.

Интеграция передаёт:

• сумму;
• дату;
• процент;
• остаток;
• задолженность.

Менеджер видит всё в одной карточке независимо от источника.

Что делать, если клиент платит разным юридическим лицам

Можно показывать общую картину:

Общая задолженность группы клиента: 10 000 000 ₸.

И детализацию:

• ТОО Trade — 4 000 000 ₸;
• ТОО Production — 6 000 000 ₸.

Для решения о новой продаже иногда важна именно общая экспозиция по клиенту.

Шаг 10. Как получать производственные статусы из отдельной базы

Это распространённая архитектура.

Bitrix24 связан:

• с торговой 1С для заказа;
• с производственной 1С для исполнения.

Сделка может показывать:

Заказ клиента: №145
Заказ производства: №P-814
Статус: в производстве
Готовность: 65%
План: 30 августа

Менеджеру не нужно понимать, из какой базы пришёл каждый показатель.

Шаг 11. Как объединять данные в одной сделке

Внутри Bitrix24 может формироваться единая карточка.

Например:

Коммерческий блок

• клиент;
• сумма;
• менеджер;
• условия.

1С Trade

• заказ;
• счёт;
• отгрузка.

1С Finance

• оплачено;
• задолженность.

1С Production

• статус производства;
• готовность;
• плановая дата.

Для пользователя это единый бизнес-процесс.

Можно ли одной сделкой управлять несколькими заказами 1С

Да.

Это актуально, если один клиентский заказ разделяется:

• по юридическим лицам;
• по складам;
• по производству и торговле.

Например:

клиент заказал:

• собственное оборудование;
• комплектующие другого производителя.

Первую часть создаём в производственной базе.

Вторую — в торговой.

В Bitrix24 остаётся одна клиентская сделка.

Внутри неё связаны два заказа 1С.

Как показывать общий статус такой сделки

Необходимо определить агрегированную логику.

Например:

Заказ 1: готов на 100%.

Заказ 2: готов на 60%.

Общий статус сделки:

Исполняется.

Не стоит автоматически закрывать клиентскую сделку после завершения первой части.

Какие сложности возникают при нескольких базах

1. Дубли клиентов

Один клиент существует в нескольких системах.

2. Разные коды товаров

Нужно сопоставление.

3. Разные правила ценообразования

CRM должна понимать контекст.

4. Разные статусы

В одной базе:

Отгружено.

В другой:

Закрыто.

Их нужно привести к единой бизнес-модели.

5. Разные структуры документов

В одной конфигурации используется «Заказ клиента».

В другой — другой объект.

6. Разное качество данных

Одна база чистая, другая содержит дубли.

7. Разная скорость обмена

Одна 1С находится в облаке, другая — в локальном офисе.

Почему нельзя просто подключить несколько одинаковых обменов

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

Но тогда возникает риск:

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

При нескольких базах нужен центральный слой маршрутизации и правил.

Даже если технически используются несколько отдельных подключений.

Архитектура «один Bitrix24 — несколько 1С»

Упрощённо её можно представить так:

Bitrix24

↓

Маршрутизация интеграции

↓

• 1С Trade
• 1С Production
• 1С Accounting
• 1С Branch 1
• 1С Branch 2

Маршрутизация определяет:

• куда отправлять;
• откуда читать;
• как сопоставлять;
• что делать при ошибке.

Где может находиться слой интеграции

Есть несколько подходов.

Прямая интеграция

Bitrix24 напрямую взаимодействует с каждой 1С.

Подходит для относительно простой архитектуры.

Отдельный интеграционный сервис

Между системами появляется middleware.

Он:

• принимает данные;
• маршрутизирует;
• хранит очередь;
• ведёт журнал;
• повторяет операции.

Для сложных корпоративных проектов это часто более устойчивый подход.

Когда нужен интеграционный сервис

Стоит рассматривать его, если:

• много баз;
• большое количество операций;
• несколько систем помимо 1С;
• критична отказоустойчивость;
• нужна единая очередь;
• требуется центральный мониторинг.

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

Как обрабатывать ошибки

Представим:

из пяти баз одна временно недоступна.

Плохая архитектура останавливает весь обмен.

Хорошая:

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

В журнале видно:

База: Production
Объект: Заказ №548
Статус: Ошибка соединения
Попыток: 3

Почему нужна отдельная очередь для каждой базы

Если одна база работает медленно, она не должна блокировать остальные.

Для каждой системы можно вести свою очередь.

Это особенно важно при больших объёмах данных.

Как защититься от дублей заказов

Каждый заказ должен иметь уникальную связь.

Например:

Bitrix24 Deal ID = 5689
1С Database = Trade
1С Order ID = 78155

Если одна сделка создаёт несколько заказов, связь хранится по каждому объекту.

Повторная отправка не должна создавать новый заказ.

Как тестировать многобазовую интеграцию

Тестирование должно включать гораздо больше сценариев.

Маршрутизация

• правильное юрлицо;
• правильная база;
• неправильное или пустое значение.

Клиенты

• новый клиент;
• существующий;
• клиент в нескольких базах.

Товары

• одинаковый товар;
• разные коды;
• отсутствующая позиция.

Заказы

• один заказ;
• разделённый заказ;
• изменение;
• отмена.

Оплаты

• одна база;
• разные юридические лица;
• частичная оплата.

Ошибки

• одна база недоступна;
• повторная отправка;
• задержка;
• конфликт данных.

Без сценарного тестирования риск ошибок значительно выше.

Как запускать проект

Многобазовую интеграцию лучше внедрять поэтапно.

Этап 1

Одна наиболее важная база.

Например:

Bitrix24 ↔ торговая 1С.

Этап 2

Добавить бухгалтерскую или второе юридическое лицо.

Этап 3

Подключить производство.

Этап 4

Добавить филиалы.

Так можно проверить архитектурную модель до масштабирования.

Какую базу подключать первой

Лучше начать с той, через которую проходит основной поток заказов.

Это позволит быстрее проверить:

• справочники;
• маршрутизацию;
• связь клиентов;
• обмен заказами;
• возврат статусов.

После этого добавлять остальные базы проще.

Как работать с отчётностью

Когда компания использует несколько баз, отчётность становится особенно важной.

Руководитель хочет видеть не пять отдельных отчётов, а единую картину:

• продажи;
• оплаты;
• задолженность;
• отгрузки;
• производство;
• маржа.

Bitrix24 может показывать часть данных.

Для глубокой сводной аналитики часто используется BI.

Пример дашборда собственника

Можно объединить:

Продажи CRM: 120 млн ₸

Заказы 1С: 105 млн ₸

Оплачено: 82 млн ₸

Дебиторка: 23 млн ₸

В производстве: 37 млн ₸

Готово к отгрузке: 11 млн ₸

И добавить разрезы:

• юридическое лицо;
• филиал;
• менеджер;
• регион.

Так множество баз перестаёт быть проблемой для управления.

Как несколько баз влияют на стоимость интеграции

Чем больше баз, тем выше трудоёмкость.

На бюджет влияют:

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

Но стоимость не растёт строго пропорционально числу баз.

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

Типовые ошибки

Подключать каждую базу отдельно без общей архитектуры

Появляются конфликты.

Не определять мастер-систему

Непонятно, где правильные данные.

Использовать название компании для сопоставления

Появляются дубли.

Не продумать маршрутизацию

Заказы уходят не в ту базу.

Не учитывать разные каталоги

Товары не сопоставляются.

Суммировать остатки без учёта логистики

Менеджеры обещают недоступный товар.

Не вести центральный журнал

Ошибка одной базы долго ищется.

Не документировать связи

Через год никто не понимает архитектуру.

Когда достаточно готового решения

Готовая интеграция может подойти, если:

• базы типовые;
• процессы одинаковые;
• небольшое число систем;
• требуется стандартный обмен.

Например:

две одинаковые базы по филиалам с одинаковыми справочниками.

Когда нужна индивидуальная архитектура

Она необходима, если:

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

Как подготовиться к проекту

Перед интеграцией полезно собрать информацию.

По каждой базе

• конфигурация;
• версия;
• юридические лица;
• пользователи;
• доработки;
• основные справочники.

По процессам

• где создаётся заказ;
• кто выставляет счёт;
• где фиксируется оплата;
• как работает производство;
• где выполняется отгрузка.

По данным

• клиенты;
• товары;
• цены;
• остатки;
• договоры.

По маршрутизации

• какой заказ куда должен попадать.

Эта информация существенно ускоряет предпроектное обследование.

Как Profi Soft интегрирует Bitrix24 с несколькими базами 1С

Profi Soft рассматривает многобазовую интеграцию как архитектурную задачу.

Мы не просто подключаем каждую базу отдельно.

Сначала определяем:

• структуру бизнеса;
• роль каждого юридического лица;
• назначение каждой 1С;
• основной источник данных;
• правила маршрутизации;
• справочники;
• связи объектов;
• сценарии ошибок.

После этого проектируется единая схема.

Что может входить в проект Profi Soft

• предпроектное обследование;
• карта IT-систем;
• анализ всех баз 1С;
• аудит Bitrix24;
• карта данных;
• маршрутизация заказов;
• сопоставление клиентов;
• сопоставление товаров;
• синхронизация цен;
• синхронизация остатков;
• передача заказов;
• получение оплат;
• задолженность;
• отгрузки;
• производственные статусы;
• очередь;
• журналирование;
• мониторинг;
• тестирование;
• обучение;
• поддержка.

Что получает компания

После правильно спроектированной интеграции:

Менеджер

Работает в одном Bitrix24 и не ищет данные по нескольким базам.

Бухгалтерия

Получает корректные заказы в нужной системе.

Производство

Получает только относящиеся к нему задания.

Руководитель

Видит единый коммерческий процесс.

Собственник

Получает общую картину по группе компаний.

Главное преимущество:

сложность внутренней IT-архитектуры перестаёт перекладываться на сотрудников.

Главный принцип

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

Нужно построить правила:

какие данные являются главными, куда должен идти заказ и откуда должен возвращаться результат.

Если эти правила определены правильно, даже сложная инфраструктура может выглядеть для пользователя как единая система.

Закажите аудит архитектуры Bitrix24 и нескольких баз 1С

Если в вашей компании несколько баз 1С, юридических лиц или филиалов, не стоит начинать проект с подключения первой попавшейся интеграции.

Сначала необходимо создать общую архитектуру.

Команда Profi Soft изучит:

• структуру группы компаний;
• Bitrix24;
• каждую базу 1С;
• клиентские данные;
• товарные справочники;
• цены;
• остатки;
• заказы;
• оплаты;
• производство.

По итогам вы получите:

• карту систем;
• распределение ролей;
• мастер-источники данных;
• правила маршрутизации;
• схему обмена;
• требования к интеграции;
• этапы запуска;
• оценку сроков и бюджета.

Оставьте заявку на предпроектное обследование. Мы покажем, как связать один Bitrix24 с несколькими базами 1С так, чтобы менеджеры работали в единой CRM, а заказы, оплаты и данные автоматически попадали в правильные учётные системы.

Чек-лист перед интеграцией нескольких баз 1С

• Сколько баз используется?
• Какие конфигурации?
• Какие юридические лица находятся в каждой?
• Есть ли общий каталог товаров?
• Где хранится основной клиентский справочник?
• Где формируются цены?
• Где находятся остатки?
• В какую базу должен попадать заказ?
• Как выбирается юридическое лицо?
• Где фиксируются оплаты?
• Есть ли производственная база?
• Нужно ли разделять один заказ между базами?
• Какие данные должны возвращаться в CRM?
• Как будут обрабатываться ошибки?
• Нужна ли единая управленческая аналитика?

Часто задаваемые вопросы

Можно ли подключить несколько баз 1С к одному Bitrix24?

Да. Но необходимо определить архитектуру, маршрутизацию заказов и основные источники данных.

Как Bitrix24 понимает, в какую базу отправлять заказ?

По заранее установленным правилам: юридическому лицу, филиалу, региону, товару или другому параметру сделки.

Можно ли объединить остатки из нескольких баз?

Да. Но важно учитывать, действительно ли товар можно отгрузить между филиалами и складами.

Что делать, если товары имеют разные коды в разных базах?

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

Можно ли одному клиенту иметь записи в нескольких 1С?

Да. В Bitrix24 можно хранить связи с несколькими идентификаторами 1С.

Можно ли передавать одну сделку в несколько баз?

Да. Например, если заказ делится между торговой и производственной компаниями.

Можно ли получать оплаты из нескольких баз в одну CRM?

Да. Финансовые статусы можно централизованно отображать в Bitrix24.

Нужен ли отдельный интеграционный сервер?

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

Можно ли подключать базы поэтапно?

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

С чего начать?

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