Если у вас 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.
| Подход |
Гибкость |
Сложность |
Подходит для |
| Фильтрация по свойству |
Средняя |
Низкая |
Небольшой каталог, фиксированные типы дилеров |
| Highload-блок ассортимента |
Высокая |
Средняя |
Крупный каталог, индивидуальные настройки |
Документооборот и финансы
Дилеры запрашивают документы постоянно — счета, накладные, акты сверки. Хранить их в Битриксе избыточно, если они уже есть в 1С. Схема работы:
- Портал запрашивает список документов дилера через REST-сервис 1С (или выгрузку в промежуточную таблицу)
- Документы кешируются в Highload-блоке
dealer_documents: UF_DEALER_ID, UF_DOC_TYPE, UF_DOC_NUMBER, UF_DATE, UF_AMOUNT, UF_FILE_URL
- Синхронизация по крону каждые 2 часа через агент модуля
main (CAgent::AddAgent)
- 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 месяцев
Сроки
| Этап |
Срок |
| Аналитика и проектирование |
2–3 недели |
| Система ролей и авторизации |
2–3 недели |
| Ценообразование (все уровни) |
2–4 недели |
| Личный кабинет дилера |
3–5 недель |
| Интеграция с 1С |
3–6 недель |
| Документооборот и финансы |
2–3 недели |
| Тестирование |
2–3 недели |
Итого: 14–24 недели. Разброс определяется глубиной интеграции с 1С и количеством кастомных бизнес-правил по ценообразованию. Оценим ваш проект за 1 день — свяжитесь с нами для консультации.
Пример: как мы сократили время обработки заказов в 3 раза
Для одного клиента с 50 дилерами мы автоматизировали ценообразование и документооборот. Раньше заказ обрабатывался 2 часа, теперь 5 минут. Это дало существенную экономию. Обратитесь к нам, чтобы получить аналогичный результат.
Закажите разработку дилерского портала и получите бесплатный аудит текущих процессов. Это поможет точно оценить сроки и объём работ.
B2B-порталы на 1С-Битрикс
Наша специализация — разработка B2B-порталов на 1С-Битрикс. Не просто «интернет-магазинов для оптовиков». Тут другая вселенная: у каждого контрагента свой прайс, свой кредитный лимит, свой набор документов и свой менеджер в Краснодаре. Розничный покупатель выбирает по картинке и отзывам. Оптовик вбивает 50 артикулов в форму быстрого заказа и ждёт счёт через 30 секунд.
У нас 10+ лет опыта в этой нише, более 50 проектов внедрения. Гарантия на работы — 12 месяцев. Сертифицированные специалисты 1С-Битрикс. Свяжитесь с нами — мы проанализируем вашу текущую структуру цен и предложим архитектуру портала под ваш бизнес.
Как устроено ценообразование в B2B-портале?
Если в рознице одна цена для всех, то в B2B — матрица. Типы цен в b_catalog_price умножаются на группы контрагентов, накопительные скидки, валютные пересчёты и договорные условия. Именно здесь проект либо взлетает, либо тонет в багах.
Типы цен и прайс-листы. В Битрикс типы цен задаются через CCatalogGroup. Стандартный набор: розничная, мелкооптовая, оптовая, дилерская, дистрибьюторская. Каждый контрагент привязан к группе пользователей, группа — к типу цены. Но реальность сложнее: один дилер может видеть оптовые цены на электронику и дистрибьюторские на аксессуары. Это уже не штатный механизм — нужна кастомная логика через обработчик OnSaleBasketItemBeforePriceSave.
Скидки — прогрессивная шкала по объёму (от 100 штук — минус 5%, от 500 — минус 12%), накопительные за период, сезонные, по категориям. Скидки комбинируются через приоритеты в b_sale_discount. Порядок применения — отдельная головная боль: скидка может быть до или после фиксированной; приоритеты настраиваются в «Правилах работы с корзиной». При 20+ правилах отладка превращается в квест.
Кредитные лимиты. Контрагенту устанавливается порог отгрузки в кредит. Текущая задолженность синхронизируется с 1С через регистр РасчетыСКонтрагентами. Превышение лимита → блокировка оформления заказа. Без этого менеджеры отгружают в долг, а бухгалтерия потом разгребает дебиторку.
Договорные цены — прайс привязан к конкретному договору: сроки действия, номер, условия пролонгации. Договор истёк — цены переключаются на базовые автоматически. Реализуется через пользовательские свойства заказа и обработчик OnSaleComponentOrderProperties.
Валюта — для ВЭД обязательно. Пересчёт по курсу ЦБ (парсинг cbr.ru через CCurrencyRates::ConvertCurrency()) или фиксированный курс контракта.
Что входит в дилерский кабинет?
Заказы — полная история с фильтрацией по статусам, датам, суммам. Повтор предыдущего заказа в один клик — для регулярных закупок это экономит часы. Шаблоны заказов для типовых позиций.
Финансы — сальдо взаиморасчётов, акт сверки, история оплат. Всё, что бухгалтер обычно запрашивает по email и ждёт три дня — в кабинете мгновенно. Данные тянутся из 1С через REST или CommerceML.
Документы — счета, накладные, счета-фактуры, УПД, акты. Формируются в 1С, PDF пушится на портал через интеграцию. Скачивание одним кликом. Никакого «пришлите повторно, потерялось в почте».
Управление сотрудниками дилера — администратор создаёт учётки с разграничением прав. Менеджер по закупкам формирует заказы, бухгалтер видит только финансы, руководитель — общую картину. Реализуется через расширение стандартных групп пользователей Битрикс.
Быстрый заказ: артикул + количество = счёт
B2B-клиент знает, что ему нужно. Каталог с красивыми карточками ему не нужен — нужна форма: артикул, количество, следующая строка.
- Форма быстрого заказа — автоподстановка наименования и цены при вводе артикула. Используем AJAX-поиск по
b_iblock_element.XML_ID или PROPERTY_ARTICLE. 50 позиций за 3 минуты
- Импорт из Excel/CSV — клиент выгрузил из своей системы, загрузил на портал. Автосопоставление артикулов, проверка наличия, формирование заказа. Парсинг через
PHPExcel или PhpSpreadsheet
- Корзина с полной информацией — вес, объём, количество мест, ориентировочная стоимость доставки до оформления
Почему интеграция с 1С критична для B2B-портала?
Без актуальных данных из 1С портал бесполезен. Менеджер Иванов изменил цену на гвозди — через 15 минут дилер в Красноярске должен видеть новую цену.
| Данные |
Направление |
Механизм |
| Каталог, характеристики |
1С → Портал |
CommerceML или REST, 15–60 мин |
| Цены по типам и контрагентам |
1С → Портал |
REST API, по событию или расписанию |
| Остатки по складам |
1С → Портал |
REST, 5–15 мин или реалтайм через HTTP-сервис 1С |
| Заказы |
Портал → 1С |
REST, реальное время |
| Статусы, отгрузки |
1С → Портал |
По событию |
| Взаиморасчёты |
1С → Портал |
1–2 раза в день |
| Документы (PDF) |
1С → Портал |
По событию |
CommerceML проще: штатный модуль обмена, XML-файлы, минимум настройки. Но он медленный на больших каталогах и не поддерживает кастомные сущности (кредитные лимиты, сальдо). REST API через HTTP-сервис 1С — гибче, быстрее, но требует доработки на стороне 1С. На практике часто используем гибрид: CommerceML для каталога, REST для цен, остатков и документов. Согласно официальной документации 1С-Битрикс, для B2B-порталов критично настроить синхронизацию справочников и остатков в реальном времени. Подробнее о CommerceML и REST API 1С-Битрикс.
ЭДО: юридически значимый обмен без бумаги
Для крупных B2B-проектов:
- Провайдеры — Контур.Диадок, СБИС, Калуга Астрал. Счета-фактуры, акты, накладные в электронном виде с юридической силой
- КЭП — квалифицированная электронная подпись. Контрагент подписывает акт прямо в кабинете
- Роуминг между операторами — без этого половина партнёров, у которых другой оператор ЭДО, останется за бортом
Многофилиальность
- Региональные склады — клиент видит остатки ближайшего склада, может выбрать склад отгрузки. Товар есть в Новосибирске, но нет в Москве — портал покажет оба варианта с разными сроками
- Автоназначение менеджера — дилер из Краснодара работает с Иваном, из Екатеринбурга — с Мариной. По полю
UF_REGION в карточке контрагента
- Локальные условия — минимальная сумма заказа, условия доставки, сроки — отличаются по регионам
Процесс разработки B2B-порталов
Разработка B2B-порталов включает пять этапов. Ниже таблица с ориентировочными сроками и результатами.
| Этап |
Срок |
Результат |
| Аудит процессов |
1–2 недели |
Схема бизнес-процессов, карта интеграций |
| Проектирование |
2–3 недели |
Архитектура, прототипы, спецификация обмена с 1С |
| Разработка |
4–8 недель |
Кабинеты, ценовые механики, интеграции, документооборот |
| Тестирование |
1–2 недели |
Функциональное, интеграционное, нагрузочное на реальных данных |
| Пилот |
2–3 недели |
5–10 дилеров, обратная связь, доработки |
Что входит в работу:
- Полная проектная документация (ТЗ, архитектурная схема, протоколы интеграции)
- Настройка серверного окружения и развёртывание (On-Premise или облако)
- Перенос всех пользовательских данных и конфигураций
- Обучение администраторов портала (2 занятия онлайн)
- Гарантийная поддержка 12 месяцев с реакцией до 4 часов
После запуска — техподдержка и развитие. B2B-портал — живая система, которая эволюционирует вместе с бизнесом.
Средняя экономия времени менеджера на обработке заказов — до 20 часов в неделю.
На старте проверьте корректность типов цен и групп пользователей, ограничьте количество скидочных правил (не более 3–4), протестируйте интеграцию с 1С на реальных данных, выдайте дилерам доступы и проведите нагрузочное тестирование на 50 одновременных пользователей.
Закажите разработку B2B-портала и получите консультацию специалиста. Свяжитесь с нами для обсуждения вашего проекта — мы подготовим предварительный расчёт и предложим оптимальное решение.