Расширение и модификация обмена b2b-портала на Битрикс с 1С
Как объединить десятки юрлиц в один аккаунт на B2B-портале? Как мы доработали обмен 1С-Битрикс и 1С КА, чтобы клиенты получили единый вход и гибкое управление контрагентами и договорами, а также автоматическую привязку ответственных менеджеров на сайте.
<section class="content-section" data-section="i1">
<h2 id="i1">1. Проблема стандартной логики обмена</h2>
<p>
Коробочный механизм интеграции «1С-Битрикс» и «1С:Управление холдингом» (КА) предполагает прямую проекцию: каждому юридическому лицу из учётной системы соответствует ровно один пользователь на сайте. Все реквизиты этого контрагента записываются в единый профиль покупателя. Такая модель удобна для небольших компаний, но становится серьёзным барьером для B2B-холдингов, где один клиент может владеть десятком юрлиц.
</p>
<p>
Для портала «Экодуш» этот подход оказался неприемлемым: менеджеры тратили время на управление множеством логинов, а клиенты не могли видеть сводную информацию по всем своим предприятиям. Требовалось кардинально изменить логику — объединить контрагентов в группы (холдинги) и дать возможность входить на сайт под одной учётной записью, но с возможностью переключения между профилями плательщиков.
</p>
</section>
<section class="content-section" data-section="i2">
<h2 id="i2">2. Расширение XML-выгрузки из 1С</h2>
<p>
Чтобы сайт мог корректно идентифицировать головные и дочерние компании, мы доработали формат выгрузки контрагентов со стороны 1С. В стандартный XML-файл были добавлены новые теги, отсутствующие в типовом обмене.
</p>
<p>
Для группировки введён тег <code><ParentCompanyExternalID></code> — он содержит внешний код головной организации. Если контрагент сам является головным, в этом поле передаётся его собственный код. Кроме того, мы добавили блоки ответственных лиц: <code><ResponsibleManager></code> и <code><AssistantManager></code>, в которые помещаются внешние идентификаторы сотрудников компании-клиента. При необходимости вместе с ними передаются ФИО и контактные данные для автоматического создания учётных записей менеджеров на сайте.
</p>
</section>
<section class="content-section" data-section="i3">
<h2 id="i3">3. Группировка пользователей на стороне сайта</h2>
<p>
Самый ответственный этап — перехват входящего XML и переопределение стандартной логики сохранения. Мы написали обработчик событий, который анализирует полученные данные и применяет новый алгоритм вместо создания пользователя на каждый тег «Контрагент».
</p>
<p>
При поступлении записи о юрлице обработчик считывает <code>ParentCompanyExternalID</code> и выполняет поиск в базе Битрикса: существует ли уже пользователь с таким внешним кодом головной компании (хранится в специальном пользовательском свойстве <code>UF_HEAD_EXTERNAL_ID</code>). Если головная учётная запись найдена, то новый пользователь не создаётся — вместо этого формируется дополнительный профиль покупателя (набор реквизитов) и привязывается к уже существующему аккаунту. Если головной записи нет, создаётся новый пользователь, который автоматически становится «головой» холдинга, и ему присваивается соответствующий внешний код.
</p>
<p>
В результате в админке сайта появляется одна учётная запись на холдинг, внутри которой перечислены все юридические лица с возможностью выбора плательщика при оформлении заказа.
</p>
</section>
<section class="content-section" data-section="i4">
<h2 id="i4">4. Автоматическая привязка ответственных менеджеров</h2>
<p>
Помимо группировки контрагентов, бизнес-процесс требовал чёткой привязки к каждому клиенту персональных менеджеров и их помощников. Эти данные также приходят в расширенном XML.
</p>
<p>
На стороне сайта мы создали две дополнительные роли пользователей: «Менеджер по работе с клиентами» и «Помощник». При обработке контрагента система ищет сотрудников по переданному внешнему коду (свойство <code>EXTERNAL_ID</code> или <code>UF_1C_ID</code>). Если сотрудник не найден, он автоматически создаётся с заполненными именем, фамилией и электронной почтой из XML, после чего ему назначается соответствующая роль.
</p>
<p>
После того как пользователь-контрагент создан или обновлён, мы устанавливаем связи: для основного менеджера используется стандартное поле привязки к пользователю (<code>UF_RESPONSIBLE</code>), а для помощника — дополнительное пользовательское свойство <code>UF_ASSISTANT</code>. Теперь в карточке клиента отображаются не просто текстовые строки, а активные ссылки на профили сотрудников, и система корректно назначает их ответственными за все заказы холдинга. Это полностью автоматизирует процесс распределения клиентов и исключает ручной ввод данных.
</p>
</section>
<h2 id="i1">1. Проблема стандартной логики обмена</h2>
<p>
Коробочный механизм интеграции «1С-Битрикс» и «1С:Управление холдингом» (КА) предполагает прямую проекцию: каждому юридическому лицу из учётной системы соответствует ровно один пользователь на сайте. Все реквизиты этого контрагента записываются в единый профиль покупателя. Такая модель удобна для небольших компаний, но становится серьёзным барьером для B2B-холдингов, где один клиент может владеть десятком юрлиц.
</p>
<p>
Для портала «Экодуш» этот подход оказался неприемлемым: менеджеры тратили время на управление множеством логинов, а клиенты не могли видеть сводную информацию по всем своим предприятиям. Требовалось кардинально изменить логику — объединить контрагентов в группы (холдинги) и дать возможность входить на сайт под одной учётной записью, но с возможностью переключения между профилями плательщиков.
</p>
</section>
<section class="content-section" data-section="i2">
<h2 id="i2">2. Расширение XML-выгрузки из 1С</h2>
<p>
Чтобы сайт мог корректно идентифицировать головные и дочерние компании, мы доработали формат выгрузки контрагентов со стороны 1С. В стандартный XML-файл были добавлены новые теги, отсутствующие в типовом обмене.
</p>
<p>
Для группировки введён тег <code><ParentCompanyExternalID></code> — он содержит внешний код головной организации. Если контрагент сам является головным, в этом поле передаётся его собственный код. Кроме того, мы добавили блоки ответственных лиц: <code><ResponsibleManager></code> и <code><AssistantManager></code>, в которые помещаются внешние идентификаторы сотрудников компании-клиента. При необходимости вместе с ними передаются ФИО и контактные данные для автоматического создания учётных записей менеджеров на сайте.
</p>
</section>
<section class="content-section" data-section="i3">
<h2 id="i3">3. Группировка пользователей на стороне сайта</h2>
<p>
Самый ответственный этап — перехват входящего XML и переопределение стандартной логики сохранения. Мы написали обработчик событий, который анализирует полученные данные и применяет новый алгоритм вместо создания пользователя на каждый тег «Контрагент».
</p>
<p>
При поступлении записи о юрлице обработчик считывает <code>ParentCompanyExternalID</code> и выполняет поиск в базе Битрикса: существует ли уже пользователь с таким внешним кодом головной компании (хранится в специальном пользовательском свойстве <code>UF_HEAD_EXTERNAL_ID</code>). Если головная учётная запись найдена, то новый пользователь не создаётся — вместо этого формируется дополнительный профиль покупателя (набор реквизитов) и привязывается к уже существующему аккаунту. Если головной записи нет, создаётся новый пользователь, который автоматически становится «головой» холдинга, и ему присваивается соответствующий внешний код.
</p>
<p>
В результате в админке сайта появляется одна учётная запись на холдинг, внутри которой перечислены все юридические лица с возможностью выбора плательщика при оформлении заказа.
</p>
</section>
<section class="content-section" data-section="i4">
<h2 id="i4">4. Автоматическая привязка ответственных менеджеров</h2>
<p>
Помимо группировки контрагентов, бизнес-процесс требовал чёткой привязки к каждому клиенту персональных менеджеров и их помощников. Эти данные также приходят в расширенном XML.
</p>
<p>
На стороне сайта мы создали две дополнительные роли пользователей: «Менеджер по работе с клиентами» и «Помощник». При обработке контрагента система ищет сотрудников по переданному внешнему коду (свойство <code>EXTERNAL_ID</code> или <code>UF_1C_ID</code>). Если сотрудник не найден, он автоматически создаётся с заполненными именем, фамилией и электронной почтой из XML, после чего ему назначается соответствующая роль.
</p>
<p>
После того как пользователь-контрагент создан или обновлён, мы устанавливаем связи: для основного менеджера используется стандартное поле привязки к пользователю (<code>UF_RESPONSIBLE</code>), а для помощника — дополнительное пользовательское свойство <code>UF_ASSISTANT</code>. Теперь в карточке клиента отображаются не просто текстовые строки, а активные ссылки на профили сотрудников, и система корректно назначает их ответственными за все заказы холдинга. Это полностью автоматизирует процесс распределения клиентов и исключает ручной ввод данных.
</p>
</section>
