Компания, которая продаёт станки, стройматериалы или комплектующие оптовым клиентам, рано или поздно упирается в один и тот же потолок: менеджеры вручную собирают прайс-листы под каждого дилера, согласование заказа идёт по почте и в мессенджерах, а склад узнаёт об отгрузке последним. Обычный интернет-магазин эту проблему не решает. Он рассчитан на разовую покупку одним человеком, а не на регулярные закупки по договорным ценам с несколькими согласующими внутри компании-клиента. Для этого нужен B2B-портал — отдельный класс решений. 1С-Битрикс на сегодняшний день остаётся одной из немногих платформ на российском и казахстанском рынке, где такая функциональность реализована на уровне ядра, а не собирается из десятка сторонних плагинов.
Чем B2B-портал отличается от обычного интернет-магазина
Разница не в дизайне и не в количестве карточек товара, а в логике доступа к информации. В рознице у всех посетителей одна и та же цена, один каталог и одна корзина. В B2B-модели у каждого контрагента — а часто и у каждого сотрудника внутри контрагента — своя картина: свой прайс с индивидуальной скидкой, своя история заказов, свой кредитный лимит, свои согласующие. Дилер из Алматы может видеть склад в своём регионе и цену с учётом годового объёма закупок, а его новый менеджер по снабжению — только каталог без права оформить заказ без подтверждения руководителя.
Отсюда вытекает и вторая особенность: B2B-портал почти всегда — не самостоятельная система, а фронтенд поверх учётных данных компании. Остатки на складе, актуальные цены, статусы отгрузок и дебиторская задолженность контрагента реально существуют в учётной системе (чаще всего 1С:Предприятие), а портал обязан отражать их без задержек и без ручной синхронизации. Как только эта связка рвётся (например, менеджер видит на сайте остаток «в наличии», а на складе товара уже нет), доверие клиента к порталу падает быстрее, чем к менеджеру по телефону: от сайта ожидают точности, а не человеческой ошибки.
Архитектура: на чём строится портал на 1С-Битрикс
В основе почти любого B2B-решения на этой платформе лежит связка из нескольких стандартных модулей ядра «1С-Битрикс: Управление сайтом», а не самописный каталог с нуля. Товарные позиции, категории, характеристики и торговые предложения хранятся в инфоблоках — это встроенный механизм структурированных данных, на котором держится вся товарная часть системы. Поверх инфоблоков работает модуль «Торговый каталог», который отвечает за цены, остатки, единицы измерения и связку с 1С.
Важный технический нюанс стоит прояснить ещё на этапе выбора лицензии: множественные типы цен, привязанные к группам пользователей, поддерживаются только в редакции «Бизнес». Если у компании единая цена на все товары для всех клиентов, хватит и младших редакций. Но для B2B-модели с оптовыми, дилерскими и розничными ценами редакция «Бизнес» обязательна, и закладывать её в бюджет проекта нужно сразу, а не после того как макеты уже согласованы.
Дальше встаёт вопрос интеграции с учётной системой. Штатный механизм обмена данными между 1С-Битрикс и 1С:Предприятие построен на стандарте CommerceML и синхронизирует номенклатуру, цены, остатки и заказы в обе стороны. На практике это означает, что менеджер по-прежнему работает в привычной 1С, а сайт лишь регулярно забирает оттуда актуальные данные и отправляет обратно оформленные через портал заказы — без двойного ввода. Частота обмена (раз в час, раз в сутки, в реальном времени через API) — это отдельное архитектурное решение. Оно зависит от объёма каталога и требований бизнеса к актуальности остатков, и фиксировать его в техническом задании нужно явно, а не оставлять на усмотрение подрядчика.
Каталог для B2B: чем он должен отличаться от розничного
Розничный каталог проектируется вокруг эмоциональной покупки: крупные фотографии, карточка с одним товаром на экран, кнопка «купить» на видном месте. У B2B-закупщика другая задача и другое поведение: он приходит с заранее составленным списком позиций, часто выгруженным из своей внутренней учётной системы, и ему нужно быстро найти нужные артикулы, сверить остатки и добавить в заказ десятки позиций за один заход, а не рассматривать карточки по одной.
Отсюда вытекают требования, которые в рознице считаются второстепенными, а в B2B-портале — базовыми. Во-первых, быстрый ввод по артикулу или номенклатурному номеру: многие закупщики знают код позиции наизусть и предпочитают ввести его в поиск, а не листать категории. Во-вторых, табличный режим просмотра каталога, где строка — это товар, а не крупная карточка, потому что за один сеанс закупщик может добавить в заказ 50-100 позиций. В-третьих, массовое добавление в корзину через загрузку списка артикулов из файла. Такого сценария почти никогда нет в розничных интернет-магазинах, но для B2B-клиента с большим постоянным списком закупки он экономит часы работы каждую неделю. Все эти элементы реализуются поверх стандартного каталога на инфоблоках, но требуют отдельного проектирования интерфейса. Типовой шаблон интернет-магазина 1С-Битрикс из коробки под такие сценарии не рассчитан.
Отдельного внимания заслуживает скорость. Оптовый каталог на несколько тысяч позиций с множеством типов цен и повторяющимися запросами к базе данных при неверной архитектуре начинает заметно проседать по скорости отклика уже при умеренной посещаемости. Если каталог заведомо большой, кэширование результатов запросов, правильную индексацию инфоблоков и вынесение тяжёлых операций (например, пересчёта персональных скидок) в фоновые процессы нужно закладывать в архитектуру сразу, а не добавлять потом.
Личный кабинет и разграничение доступа
Личный кабинет — основной инструмент управления отношениями с контрагентом. На платформе он строится на связке групп пользователей и привязанных к ним типов цен: создаются группы вроде «Дилеры», «Оптовые клиенты», «Розница», и каждой группе назначается свой тип цены, оформленный как скидка или наценка к базовой цене в процентах или фиксированной сумме. Дальше конкретный пользователь или вся компания-контрагент попадает в нужную группу и сразу видит каталог с правильными цифрами, без участия менеджера.
Для многих отраслей — дистрибуции стройматериалов, продажи оборудования, поставок сырья — этим базовым сценарием дело не ограничивается: нужна ещё и индивидуальная сетка скидок для конкретного контрагента или даже для конкретной товарной группы у этого контрагента, а не только групповой тариф. Это реализуется надстройкой над стандартным механизмом типов цен и требует отдельной проработки на этапе проектирования. Универсального «включателя» для такой гибкости в коробочной версии нет. Такую сетку скидок всегда разрабатывают индивидуально под структуру ценообразования компании.
Второй слой личного кабинета — история и статусы. Контрагенту важно видеть не абстрактный список заказов, а реальный путь каждого документа: принят в обработку, скомплектован, в пути, закрывающие документы готовы. Это снимает львиную долю звонков в отдел продаж с вопросом «а где мой заказ», и именно эта функция чаще всего окупает разработку портала быстрее остальных, просто за счёт разгрузки менеджеров.
Многоуровневое согласование заказов
В B2C-логике решение о покупке принимает один человек за одну сессию. В B2B закупку часто инициирует один сотрудник, согласует другой, а оплачивает — бухгалтерия по совершенно отдельному циклу. Портал, который не учитывает эту цепочку, вынуждает клиента возвращаться к телефону и почте ровно там, где, казалось бы, весь смысл был в автоматизации.
Практическое решение — ролевая модель внутри личного кабинета одного контрагента: сотрудник формирует заявку, она уходит на подтверждение снабженцу или руководителю отдела закупок, и только после этого превращается в заказ, который видит менеджер поставщика. Технически это надстройка над стандартным модулем «Интернет-магазин» и механизмом бизнес-процессов платформы, который умеет запускать цепочки согласования по заданным условиям. Глубина этой логики — сколько уровней согласования, какие лимиты запускают дополнительное подтверждение — всегда индивидуальна и должна обсуждаться на этапе сбора требований, а не додумываться подрядчиком постфактум.
Безопасность и разграничение прав доступа
Портал, который показывает контрагенту его собственные договорные цены, дебиторскую задолженность и историю заказов, по определению работает с чувствительными коммерческими данными. Утечка этих данных к конкуренту или просто к постороннему пользователю обходится компании куда дороже, чем сбой в дизайне. Базовый уровень защиты обеспечивает штатная система прав доступа платформы: группы пользователей, привязанные к ним права на разделы и инфоблоки, и обязательная аутентификация для доступа в личный кабинет. Всё это входит в ядро системы и не требует дополнительной разработки.
Но для портала с несколькими сотрудниками одного контрагента этого недостаточно: нужно, чтобы сотрудник компании-клиента видел заказы и цены именно своей компании, а не всех клиентов подряд, и чтобы удаление или блокировка одного сотрудника не затрагивала доступ остальных. Такая многоуровневая модель — компания как контейнер для нескольких учётных записей с общими правами на просмотр цен, но раздельными правами на оформление заказов — это уже надстройка. Её нужно закладывать в техническое задание отдельно, вместе с вопросом, кто на стороне клиента администрирует такие учётные записи: сам клиент через свой личный кабинет или менеджер поставщика вручную.
Иллюстративный пример: как это выглядит на практике
Чтобы не оставаться в абстракциях, разберём условный, обобщённый сценарий — иллюстрацию логики, а не описание конкретного внедрения. Дистрибьютор строительных смесей поставляет товар и крупным сетям, и небольшим прорабским бригадам. До портала у обеих категорий клиентов были одинаковые условия работы: звонок менеджеру, устное согласование цены, заказ по почте. Менеджеры физически не успевали обрабатывать мелкие заказы бригад с той же скоростью, что и крупные контракты сетей, и мелкая розница постепенно уходила к конкурентам с более быстрым откликом.
Решение в такой ситуации обычно строится на разделении контрагентов на группы с разными сценариями: у сетевых клиентов — индивидуальные цены, кредитный лимит и многоуровневое согласование внутри их закупочного отдела; у бригад — упрощённый каталог с фиксированной оптовой скидкой и мгновенным оформлением без согласований. Обе группы работают в одном портале, но видят принципиально разный интерфейс и разную логику оформления заказа. Именно эта развилка, а не количество товаров в каталоге, определяет сложность и стоимость проекта.
Показательно, что в подобных сценариях наибольший эффект часто даёт не самая сложная функция, а самая скучная: автоматическая подстановка правильной цены при входе в личный кабинет вместо звонка менеджеру. Именно она снимает основную часть рутинной нагрузки с отдела продаж и одновременно ускоряет цикл заказа для клиента. Согласование сложных сценариев для крупных сетей можно достраивать постепенно, а вот без корректного автоматического ценообразования портал для мелких клиентов вообще не имеет смысла: они и обращались к менеджеру именно за быстрым ответом, который теперь должен давать сайт.
Частые ошибки при разработке B2B-портала
Первая и самая дорогая ошибка — начинать разработку с дизайна, а не с описания ролей и сценариев доступа. Когда макеты каталога и личного кабинета готовы, а группы пользователей, типы цен и логика согласования обсуждаются только на этапе разработки, проект почти неизбежно уходит в повторные итерации: интерфейс, спроектированный без понимания ролевой модели, редко выдерживает её без переделок.
Вторая — недооценка интеграции с учётной системой. Заказчики часто воспринимают синхронизацию с 1С как техническую деталь, которую «подрядчик как-нибудь настроит», хотя именно от структуры данных в учётной системе — как организованы номенклатура, склады, договорные условия по контрагентам — зависит, какие сценарии портал вообще сможет реализовать без надстроек. Аудит выгрузки данных из 1С должен идти параллельно с проектированием портала, а не после него.
Третья ошибка — попытка сразу построить максимально сложную систему согласований и скидок «на вырост», под гипотетических крупных клиентов, которых пока нет. Это удлиняет разработку и usability-тестирование, но большая часть встроенной гибкости остаётся невостребованной месяцами. Разумнее спроектировать архитектуру расширяемой — с понятной точкой, куда добавить новую роль или уровень согласования, — но в первой версии реализовать только те сценарии, которые уже подтверждены реальными клиентами.
Четвёртая, менее очевидная ошибка — забыть про крупных клиентов, у которых уже есть собственная система закупок (ERP или отдельный модуль снабжения) и которым личный кабинет с ручным вводом заказа неудобен в принципе: такой контрагент хочет получать актуальный прайс-лист и отправлять заказы программно, а не через браузер. Для этой категории клиентов личного кабинета мало. Нужен отдельный программный интерфейс обмена данными, который часто закладывается в архитектуру уже на старте проекта, даже если в первой версии портала им пользуется лишь один-два крупных контрагента. Добавлять такой интерфейс постфактум, когда основная архитектура уже спроектирована только под браузерный личный кабинет, обычно дороже, чем предусмотреть его заранее.
Как оценить сроки и бюджет проекта
Сроки разработки B2B-портала на 1С-Битрикс складываются не из количества страниц, а из числа уникальных ролей, сценариев согласования и глубины интеграции с 1С. Портал с двумя-тремя группами пользователей, стандартными типами цен и односторонней выгрузкой остатков из 1С — это один порядок сложности. Портал с индивидуальной сеткой скидок по каждому контрагенту, многоуровневым согласованием заявок и двусторонним обменом заказами в реальном времени — совсем другой, и разница в трудозатратах может быть кратной.
Прежде чем запрашивать оценку у подрядчика, стоит на своей стороне описать хотя бы три вещи: список ролей пользователей и что видит каждая из них, правила ценообразования по группам и контрагентам и то, как сейчас физически устроен обмен данными между сайтом и 1С (если сайт уже есть) или как он должен быть устроен (если портал разрабатывается с нуля). Это ускорит оценку и снизит риск, что архитектура, заложенная в начале, не выдержит реальной ролевой модели бизнеса.
Полезно также заранее решить, что считается MVP-версией портала, а что можно вынести во вторую очередь без ущерба для запуска. Каталог с типами цен по группам, личный кабинет с историей заказов и односторонняя выгрузка остатков из 1С — это уже рабочий портал, который можно показать клиентам и начать собирать обратную связь. Многоуровневое согласование, индивидуальные скидки по контрагентам и программный интерфейс для крупных клиентов с собственной ERP — это функциональность, которую разумно добавлять по мере того, как реальные клиенты подтверждают в ней необходимость, а не на старте разработки, когда предположения о поведении клиентов ещё не проверены практикой.
Если своей команды под такую разработку нет, разумный путь — заказать разработку B2B-портала на 1С-Битрикс у подрядчика, который уже проектировал подобные ролевые модели и интеграции с учётными системами, а не собирает архитектуру впервые на бюджете и времени заказчика.
Частые вопросы
Какая редакция 1С-Битрикс нужна для B2B-портала с разными ценами для клиентов?
Множественные типы цен, привязанные к группам пользователей, поддерживаются только в редакции «Бизнес». Более младшие редакции подходят, если у товаров единая цена для всех категорий покупателей.
Можно ли настроить индивидуальные скидки для конкретного контрагента, а не только для группы клиентов?
Да, но это требует дополнительной разработки поверх стандартного механизма типов цен. «Из коробки» типы цен привязываются к группам пользователей, а точечная сетка скидок по каждому контрагенту и товарной группе проектируется индивидуально под структуру ценообразования компании.
Как синхронизируются остатки и цены между порталом и 1С:Предприятие?
Стандартный механизм обмена между 1С-Битрикс и 1С:Предприятие построен на стандарте CommerceML и передаёт номенклатуру, цены, остатки и заказы в обе стороны. Периодичность обмена — по расписанию или в режиме, близком к реальному времени, — настраивается под требования конкретного бизнеса.
Нужно ли сразу реализовывать многоуровневое согласование заказов?
Не обязательно в первой версии. Разумнее спроектировать архитектуру так, чтобы согласование можно было добавить позже, но запускать портал со сценариями, которые уже подтверждены реальными клиентами, а не с максимально сложной логикой «на будущее».
Сколько времени занимает разработка B2B-портала на 1С-Битрикс?
Срок зависит не от количества страниц, а от числа ролей пользователей, сложности ценообразования и глубины интеграции с учётной системой. Портал с базовой ролевой моделью и односторонней выгрузкой из 1С разрабатывается заметно быстрее, чем система с индивидуальными скидками по контрагентам и двусторонним обменом заказами.