Расширение и модификация обмена b2b-портала на Битрикс с 1С

1. Проблема стандартной логики обмена

Коробочный механизм интеграции «1С-Битрикс» и «1С:Управление холдингом» (КА) предполагает прямую проекцию: каждому юридическому лицу из учётной системы соответствует ровно один пользователь на сайте. Все реквизиты этого контрагента записываются в единый профиль покупателя. Такая модель удобна для небольших компаний, но становится серьёзным барьером для B2B-холдингов, где один клиент может владеть десятком юрлиц.

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

2. Расширение XML-выгрузки из 1С

Чтобы сайт мог корректно идентифицировать головные и дочерние компании, мы доработали формат выгрузки контрагентов со стороны 1С. В стандартный XML-файл были добавлены новые теги, отсутствующие в типовом обмене.

Для группировки введён тег <ParentCompanyExternalID> — он содержит внешний код головной организации. Если контрагент сам является головным, в этом поле передаётся его собственный код. Кроме того, мы добавили блоки ответственных лиц: <ResponsibleManager> и <AssistantManager>, в которые помещаются внешние идентификаторы сотрудников компании-клиента. При необходимости вместе с ними передаются ФИО и контактные данные для автоматического создания учётных записей менеджеров на сайте.

3. Группировка пользователей на стороне сайта

Самый ответственный этап — перехват входящего XML и переопределение стандартной логики сохранения. Мы написали обработчик событий, который анализирует полученные данные и применяет новый алгоритм вместо создания пользователя на каждый тег «Контрагент».

При поступлении записи о юрлице обработчик считывает ParentCompanyExternalID и выполняет поиск в базе Битрикса: существует ли уже пользователь с таким внешним кодом головной компании (хранится в специальном пользовательском свойстве UF_HEAD_EXTERNAL_ID). Если головная учётная запись найдена, то новый пользователь не создаётся — вместо этого формируется дополнительный профиль покупателя (набор реквизитов) и привязывается к уже существующему аккаунту. Если головной записи нет, создаётся новый пользователь, который автоматически становится «головой» холдинга, и ему присваивается соответствующий внешний код.

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

4. Автоматическая привязка ответственных менеджеров

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

На стороне сайта мы создали две дополнительные роли пользователей: «Менеджер по работе с клиентами» и «Помощник». При обработке контрагента система ищет сотрудников по переданному внешнему коду (свойство EXTERNAL_ID или UF_1C_ID). Если сотрудник не найден, он автоматически создаётся с заполненными именем, фамилией и электронной почтой из XML, после чего ему назначается соответствующая роль.

После того как пользователь-контрагент создан или обновлён, мы устанавливаем связи: для основного менеджера используется стандартное поле привязки к пользователю (UF_RESPONSIBLE), а для помощника — дополнительное пользовательское свойство UF_ASSISTANT. Теперь в карточке клиента отображаются не просто текстовые строки, а активные ссылки на профили сотрудников, и система корректно назначает их ответственными за все заказы холдинга. Это полностью автоматизирует процесс распределения клиентов и исключает ручной ввод данных.

5. Выгрузка договоров контрагентов

Для корректного оформления заказов на B2B-портале «Экодуш» потребовалось учитывать не только юридическое лицо (плательщика), но и конкретный договор, заключённый между этим юрлицом и компанией. В стандартном обмене такая информация отсутствует, поэтому мы расширили XML-выгрузку новым блоком <ДоговораКонтрагентов>.

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

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

6. Дебиторская задолженность и блокировка заказов

Важным требованием бизнеса стало информирование клиентов об их текущей финансовой дисциплине. Мы доработали обмен, чтобы в XML-файле контрагента передавались два дополнительных числовых поля: DebtAmount (общая дебиторская задолженность) и OverdueDebt (просроченная дебиторская задолженность). Эти данные рассчитываются в 1С и выгружаются при каждом обмене.

На сайте для каждого пользователя-контрагента мы сохраняем эти суммы в пользовательских свойствах (например, UF_DEBT и UF_OVERDUE_DEBT) и отображаем их в виджете «Финансовое состояние» в личном кабинете. Партнёр в любой момент видит актуальную задолженность и может предпринять меры до оформления нового заказа.

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