Разработка дилерского портала на 1С-Битрикс

Разработка дилерского портала на 1С-Битрикс

Дилерская сеть из 80 компаний и менеджер, который вручную рассылает прайс-листы по почте каждый понедельник — это не процесс, это узкое место. Дилерский портал на Битриксе закрывает три вещи сразу: самостоятельное оформление заказов дилером, индивидуальные условия для каждого партнёра и автоматическую синхронизацию с 1С без участия менеджера.

Архитектура доступа: дилер как сущность

Главное отличие дилерского портала от обычного B2B — иерархия «производитель → дилер → субдилер». Один дилер может иметь несколько торговых точек и несколько сотрудников с разными правами. Штатная модель групп пользователей Битрикс (b_user_group) здесь недостаточна — она не хранит связь «пользователь принадлежит компании».

Реализация через D7 ORM: создаём сущность DealerCompany (таблица b_dealer_company) с полями идентификатора в 1С, статуса, типа дилера, региона. Связь пользователей с компанией — через промежуточную таблицу b_dealer_company_user с полем роли. Роли: owner, manager, accountant — с разными правами на создание заказов, просмотр документов, управление сотрудниками.

Авторизация через bitrix:system.auth.form дополняется кастомным обработчиком: при входе пользователя определяем его компанию и тип дилера, кешируем в сессии. Все последующие запросы к ценам и каталогу идут с учётом dealer_type.

Ценообразование для дилеров

Дилерское ценообразование — самая сложная часть. Типичная схема:

• Базовый прайс (публичный или закрытый)
• Дилерская скидка по типу (silver, gold, platinum) — процент от базовой цены
• Индивидуальные контрактные позиции — конкретные артикулы по фиксированной цене
• Акционные условия с датой действия

Стандартный механизм CATALOG_GROUP_ID в b_catalog_price покрывает первые два уровня. Для контрактных позиций нужен Highload-блок dealer_contract_prices со структурой: UF_DEALER_ID, UF_PRODUCT_ID, UF_PRICE, UF_CURRENCY, UF_DATE_FROM, UF_DATE_TO. При запросе цены проверяем сначала контрактную позицию, затем дилерский тип, затем базовую.

Логика приоритета цен внедряется через событие OnBeforeSaleOrderDoFinalAction или через кастомный провайдер цен, реализующий Bitrix\Catalog\v2\Price\BasePriceProvider. Второй вариант чище — он не ломается при обновлениях модуля sale.

Каталог и остатки

Дилеры часто работают с ограниченным ассортиментом — не весь каталог производителя доступен каждому партнёру. Ограничение ассортимента реализуется через:

• Фильтрацию по свойству инфоблока: добавляем свойство AVAILABLE_FOR_DEALER_TYPES (тип «список»), указываем типы дилеров. В компоненте bitrix:catalog.section добавляем фильтр PROPERTY_AVAILABLE_FOR_DEALER_TYPES = тип текущего дилера
• Highload-блок ассортимента: для гибкой настройки — таблица dealer_assortment (UF_DEALER_ID, UF_IBLOCK_SECTION_ID). Дилеру доступны только разделы каталога, перечисленные в его записях

Остатки — через штатный модуль catalog, таблица b_catalog_store_product. Для дилерского портала важно показывать остатки на конкретных складах, доступных дилеру (склад в его регионе). Связь дилер → склад хранится в Highload-блоке, в компоненте переопределяется запрос к b_catalog_store_product.

Документооборот и финансы

Дилеры запрашивают документы постоянно — счета, накладные, акты сверки. Хранить их в Битриксе избыточно, если они уже есть в 1С. Схема работы:

1. Портал запрашивает список документов дилера через REST-сервис 1С (или выгрузку в промежуточную таблицу)
2. Документы кешируются в Highload-блоке dealer_documents: UF_DEALER_ID, UF_DOC_TYPE, UF_DOC_NUMBER, UF_DATE, UF_AMOUNT, UF_FILE_URL
3. Синхронизация по крону каждые 2 часа через агент модуля main (CAgent::AddAgent)
4. PDF-файлы запрашиваются по требованию, кешируются в /upload/dealer/docs/ на 24 часа

Задолженность и лимит кредита — аналогично: Highload-блок dealer_credit (UF_DEALER_ID, UF_LIMIT, UF_CURRENT_DEBT, UF_OVERDUE). При превышении лимита или наличии просрочки — запрет на оформление заказа реализуется через обработчик события OnBeforeSaleOrderAdd.

Уведомления и коммуникация

Портал без уведомлений — половина работы. Настраиваем:

• Почтовые события (CEventType, CEvent::Send): смена статуса заказа, приближение срока оплаты, новый прайс
• Push-уведомления через модуль pull (если есть мобильное приложение)
• Лента событий в кабинете дилера — Highload-блок dealer_events с событиями, помеченными как прочитанные

Интеграция с CRM

Если у производителя Битрикс24, дилерский портал синхронизируется с CRM:

• Регистрация нового дилера → создаёт компанию в CRM (crm.company.add)
• Заказ дилера → сделка в CRM с привязкой к компании
• Изменение статуса сделки → изменение статуса заказа на портале через вебхук

Связь реализуется через REST API Битрикс24, хранение ID сущностей CRM в пользовательских полях компании.

Сроки

Итого: 14-24 недели. Разброс определяется глубиной интеграции с 1С и количеством кастомных бизнес-правил по ценообразованию.