Дилерский портал на 1С-Битрикс: система ролей, цены, интеграция с 1С

Если у вас 80 дилеров, менеджеры тратят полдня на рассылку прайсов. Это узкое место, которое мы устраняем. Портал закрывает три задачи: самостоятельное оформление заказов дилером, индивидуальные условия для каждого партнёра и автоматическая синхронизация с 1С без участия человека. Оценим проект за 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. Согласно документации Битрикс, BasePriceProvider обеспечивает совместимость с будущими обновлениями. Кастомное решение на Битриксе лучше готового CRM-модуля по гибкости ценообразования.

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

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

• Фильтрацию по свойству инфоблока: добавляем свойство 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.

Что делать, если дилер превышает кредитный лимит?

При каждом создании заказа срабатывает обработчик OnBeforeSaleOrderAdd: проверяется текущая задолженность дилера из dealer_credit. Если лимит превышен или есть просрочка, заказ блокируется, а дилеру отправляется уведомление. Это исключает риски неоплаты и автоматизирует контроль.

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

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

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

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

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

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

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

Что входит в работу

• Аналитика и проектирование: прототип, техническое задание
• Разработка системы ролей и авторизации
• Ценообразование всех уровней (скидки, контрактные цены, акции)
• Личный кабинет дилера с историей заказов и документами
• Интеграция с 1С через CommerceML или REST
• Тестирование и деплой на боевой сервер
• Обучение сотрудников и передача доступов
• Гарантийная поддержка 6 месяцев

Сроки

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

Закажите разработку дилерского портала и получите бесплатный аудит текущих процессов. Это поможет точно оценить сроки и объём работ.