Как объединить компании в битрикс

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

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

Рекомендуется использовать API Битрикс24 или REST-интерфейс для поэтапной миграции, с обязательным логированием на каждом этапе. Объединение через экспорт/импорт CSV-файлов не обеспечивает сохранение связей между сущностями, особенно в случае сложной структуры сделок или иерархических задач.

Тестовая среда – обязательный этап перед финальной миграцией. На базе «песочницы» можно выявить несовместимости в структуре данных, проверить сохранность истории коммуникаций и корректность восстановления бизнес-процессов. Также важно заранее сформировать карту соответствий между ID сущностей разных аккаунтов для исключения конфликтов при импорте.

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

Подготовка резервных копий перед началом объединения

Перед объединением компаний в Битрикс важно создать полные резервные копии всех критичных данных. Ошибка на этом этапе может привести к потере сделок, контактов, задач и документов. Для гарантии безопасности необходимо выполнять резервное копирование по следующим направлениям:

• База данных MySQL: экспорт с использованием mysqldump с параметрами для сохранения структуры и данных, например: mysqldump -u user -p --single-transaction --routines --triggers database_name > backup.sql.
• Файловая структура сайта: полное копирование директории /bitrix, /upload и пользовательских компонентов через rsync или tar, например: tar -czf site_backup.tar.gz /var/www/html.
• Облачные хранилища и внешние диски: сохранение всех связанных с CRM файлов, загруженных пользователями, если они размещены вне основной структуры сайта.
• Интеграции с внешними сервисами: экспорт конфигураций API, webhook’ов, логов синхронизаций для последующей ручной проверки после объединения.

Резервные копии должны быть протестированы. Разверните копию сайта на тестовом сервере и убедитесь в работоспособности всех модулей. Особое внимание уделите сохранности прав доступа, связей между сущностями (сделки – компании – контакты), пользовательским полям и автоматизациям (роботы, триггеры).

Храните бэкапы как минимум в двух местах: локально и в защищённом облачном хранилище (например, Amazon S3 или Яндекс Облако). Убедитесь, что доступ к резервным копиям имеют только ответственные сотрудники, и все действия зафиксированы в логах.

Без создания и верификации бэкапов начинать процесс объединения категорически не рекомендуется.

Выявление пересекающихся сущностей в структуре компаний

Перед объединением компаний в Битрикс24 необходимо точно определить пересекающиеся элементы, чтобы избежать дублирования и потери связей между данными. В первую очередь следует сравнить структуры CRM: лиды, контакты, компании, сделки. Используйте экспорт в Excel и фильтрацию по ключевым полям – ИНН, email, телефоны, доменные имена сайтов. Это позволит выявить повторяющиеся записи даже при незначительных расхождениях в наименованиях.

Особое внимание уделите справочникам – направлениям сделок, стадиям, источникам, типам контактов и компаний. При несовпадении этих элементов после слияния данные могут быть распределены некорректно. Используйте API Битрикс24 для выгрузки настроек обоих порталов и сравнения конфигураций на уровне ID и значений. Несовпадающие идентификаторы могут привести к потере связей между сделками и их статусами.

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

Также проанализируйте дубли бизнес-процессов и роботов. При объединении их без синхронизации возможна блокировка сценариев и пересечения по условиям запуска. Используйте REST API и бизнес-аналитику для выстраивания карты автоматизаций до объединения.

Каждое выявленное пересечение должно быть классифицировано: объединение, замена, игнорирование. Только после завершения этого этапа можно переходить к технической миграции данных.

Сравнение и синхронизация пользовательских полей CRM

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

• Выгрузите список всех пользовательских полей в обеих CRM: раздел «Настройки» → «Настройки форм и отчетов» → «Пользовательские поля».
• Сравните поля по сущностям: Лиды, Контакты, Компании, Сделки. Обратите внимание на совпадение символьных кодов (FIELD_NAME) и типов (строка, список, привязка и т.д.).
• Если поле присутствует только в одной CRM – определите его значимость. В случае необходимости добавьте его вручную в другую CRM с теми же параметрами.
• Для списков – предварительно синхронизируйте значения. Идентификаторы значений (XML_ID) должны совпадать, иначе произойдет дублирование.
• Если тип поля отличается – пересоздайте поле в целевой CRM вручную, затем с помощью скрипта перенесите данные. Например, при преобразовании текстового поля в список возможна потеря структуры.
• Обязательные поля на этапе объединения должны быть временно сделаны необязательными, чтобы избежать ошибок при переносе сущностей без значений.

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

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

Объединение каталогов товаров с сохранением уникальных свойств

При слиянии компаний на платформе 1С-Битрикс критически важно корректно объединить каталоги, не потеряв индивидуальные свойства товаров. Прямое копирование данных приводит к дублированию или удалению характеристик. Для исключения потерь необходимо использовать механизм экспорта-импорта в формате XML через модуль «Инфоблоки» с ручной настройкой соответствия полей.

Этап 1: Анализ структуры. Сначала сравниваются типы инфоблоков, кодовые обозначения свойств и их типы данных. Если в одном каталоге свойства заданы списком, а в другом – строкой, требуется привести их к единому формату. Несоответствие типов приведёт к потере значений при импорте.

Этап 2: Создание единого инфоблока. Рекомендуется создать новый инфоблок, включающий объединённый набор всех уникальных свойств. Для этого используются API-инструменты CIBlock::GetProperties и CIBlockProperty::Add. Названия и символьные коды должны быть приведены к стандарту – избегайте дублирующихся кодов, различающихся лишь регистром.

Этап 3: Миграция товаров. Для переноса элементов используется скрипт на основе CIBlockElement::Add, где каждому товару сопоставляются свойства из исходных каталогов. При наличии одинаковых артикулов необходимо настроить проверку по уникальному идентификатору (например, SKU или внешнему ID) и использовать обновление вместо добавления.

Этап 4: Сопоставление значений. Уникальные свойства (цвет, размер, материалы) часто различаются по формату записи. Используйте словари соответствий для приведения к единому виду. Например, «Синий» и «Blue» должны объединяться в одно значение. Это настраивается через преобразование данных перед импортом.

Этап 5: Проверка связей. После миграции необходимо восстановить связи: с торговыми предложениями, остатками и ценами. Используйте catalog_product и catalog_price, сверяясь по ID. Пропуск этого этапа приведёт к отображению пустых карточек в публичной части сайта.

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

Миграция сделок и лидов без потери истории взаимодействий

Перед переносом данных необходимо выгрузить полную информацию о сделках и лидах из обеих CRM-систем. Используйте REST API Битрикс24 для получения связанных сущностей: комментариев, задач, звонков, писем и файлов. Важно не ограничиваться только базовыми параметрами сделок (статус, сумма, ответственный), а зафиксировать всю хронологию действий, включая события живой ленты.

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

Импортируйте данные через метод `crm.deal.add` и `crm.lead.add`, указывая поле `CREATED_BY`, `MODIFY_BY`, а также дату создания и изменения вручную через `DATE_CREATE` и `DATE_MODIFY`. Для восстановления комментариев используйте `crm.timeline.comment.add`, передавая оригинальные временные метки. Звонки переносятся через `telephony.statistic.add` с обязательной привязкой к сущности по полю `ENTITY_TYPE` и `ENTITY_ID`.

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

Для автоматизации повторных переносов используйте промежуточный JSON или CSV формат с четкой структурой: каждый файл должен содержать полные вложенные объекты (например, сделка → история комментариев → файлы). Это упростит откат в случае ошибок и ускорит восстановление.

Настройка прав доступа после слияния структур

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

Для каждого подразделения настройте отдельную группу с чётко ограниченными правами. В разделе «Настройки» → «Пользователи» → «Группы пользователей» создайте новые группы, привяжите к ним соответствующие роли через «Роли в CRM», «Доступ к бизнес-процессам» и модулям документооборота.

Права на элементы CRM (лиды, сделки, контакты) задаются через «CRM» → «Настройки» → «Права доступа». Убедитесь, что сотрудники новой объединённой структуры видят только те сущности, которые необходимы им по должностным обязанностям. Применяйте настройку по правилам: минимум прав по умолчанию, доступ только по необходимости.

Если используются кастомные модули или интеграции (например, с 1С или внешними API), проверьте, какие пользователи и группы имеют к ним доступ через «Marketplace» → «Установленные решения». Удалите устаревшие токены, пересоздайте подключения под единым администраторским контролем.

Для аудита изменений активируйте логирование доступа: «Настройки» → «Журнал событий». Это позволит отслеживать попытки несанкционированного доступа и выявить ошибки в конфигурации. Периодически пересматривайте структуру прав с учётом внутренней ротации сотрудников и изменений в бизнес-процессах.

Сверка бизнес-процессов и корректировка шаблонов

После объединения компаний необходимо провести анализ всех активных бизнес-процессов в разделе «Бизнес-процессы» → «Шаблоны процессов». Особое внимание уделите дублирующимся сценариям, использующим одинаковые события запуска и пересекающиеся переменные. Для каждого процесса зафиксируйте владельца, точку входа, участвующие роли и связанные сущности CRM.

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

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

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

Проверка целостности данных после завершения объединения

Для выявления ошибок, возникших в процессе слияния баз, выполните постобъединительный аудит по ключевым сущностям CRM. Начните с анализа дублей: используйте инструмент «Контроль дубликатов» в разделе «CRM» → «Настройки» → «Контроль и объединение». Сравнивайте по полям: ИНН, e-mail, номер телефона. Для автоматизации свёрки подключите обработчик через API с проверкой по уникальным бизнес-идентификаторам.

Проверьте связность элементов – каждая сделка должна быть привязана к компании или контакту. Используйте отчёт по неполным связям через «CRM» → «Аналитика» → «Пользовательские отчёты». В случае потерь в связях экспортируйте данные в CSV и восстановите связи через массовый импорт с ручной верификацией.

Сравните числовые показатели до и после слияния:

Любое расхождение должно быть объяснено: удаление дублей, отказоустойчивые ошибки при импорте, фильтрация устаревших записей. Зафиксируйте каждое изменение в журнале миграции. Для критически важных данных выполните ручную верификацию по источникам – выгрузки из 1С, корпоративных реестров, почтовых логов.

Дополнительно проверьте сохранность вложений, комментариев и истории взаимодействий. Используйте REST API для выборки по полям типа UF_CRM_xxx. Потеря этих данных приведёт к искажению контекста по клиенту, что критично для B2B-направлений.

Вопрос-ответ:

Можно ли объединить две CRM в Битрикс без потери истории сделок?

Да, но при условии, что перед объединением будут выполнены экспортные процедуры с сохранением ID сделок, связанных контактов и компаний. История перемещается вместе с сущностью, если используется штатный механизм импорта через API или файл с правильно сопоставленными полями. Если объединение делается вручную — есть риск потери комментариев, вложений и переписки. Рекомендуется использовать промежуточную базу для тестовой миграции и сверки данных.

Как правильно объединить справочники товаров из двух компаний?

Объединение товарных каталогов требует предварительной стандартизации единиц измерения, валют и структуры разделов. Сначала стоит выгрузить оба справочника в CSV и привести к единому формату. Удалите дубли, используя артикулы или внешние коды. После этого можно загрузить финальный каталог через модуль «Каталог товаров» с включённой опцией обновления по внешнему идентификатору. Настоятельно рекомендуется протестировать на копии портала.

Что делать, если после объединения пропала часть контактов?

Нужно сравнить исходное количество записей с итоговым. Если есть расхождения, проверьте журнал импорта и наличие дубликатов. Битрикс автоматически объединяет контакты с одинаковыми e-mail или телефоном, если включена соответствующая настройка. Для восстановления данных загрузите архивную копию и выполните повторный импорт пропавших записей вручную с отключенной проверкой на дублирование. Это временная мера — затем объедините совпадающие вручную.

Как перенести бизнес-процессы из одного аккаунта Битрикс в другой?

Откройте нужный шаблон бизнес-процесса, нажмите «Экспорт» и сохраните файл с расширением .bptl. В целевой системе перейдите в раздел «Бизнес-процессы» → «Импорт шаблона» и загрузите файл. Обратите внимание, что привязки к конкретным пользователям или группам нужно перенастроить вручную, так как ID пользователей различаются. Также проверьте, чтобы все используемые переменные и действия были доступны в новой системе.