Роли и права пользователей в B2B-портале на 1С-Битрикс

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

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

Почему у контрагента несколько пользователей

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

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

Если свести их в один логин, вы теряете сразу несколько важных вещей:

• Прозрачность. Непонятно, кто именно оформил заказ и кто его одобрил — в истории везде один обезличенный «пользователь компании».
• Разграничение доступа. Нельзя закрыть баланс и документы от того, кому они не нужны, — общий логин видит всё.
• Согласование. Невозможно построить утверждение заказов: некому «отправлять на согласование» и некому «утверждать», если все — один человек.
• Безопасность при кадровых изменениях. Уволился сотрудник — приходится менять общий пароль и раздавать его заново всем оставшимся.

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

Роль и группа: в чём разница

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

Группа пользователей — это штатный низкоуровневый механизм 1С-Битрикс. Каждый пользователь входит в одну или несколько групп, а группам назначены права доступа к модулям, разделам сайта, инфоблокам и — что особенно важно для B2B — к типам цен. Группы отвечают на грубый вопрос «к чему вообще у этого аккаунта есть доступ на уровне платформы». Например, группа «Оптовики-дилеры» видит закрытый каталог и дилерскую цену, а группа «Розница» — нет.

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

На практике одна роль обычно раскладывается в две составляющие:

• Группа Битрикса — даёт базовый доступ: закрытый каталог, тип цены, видимость разделов. Часто все сотрудники одного контрагента сидят в одной «оптовой» группе, чтобы видеть одинаковые цены.
• Кастомные права личного кабинета — тонкие права на конкретные действия и данные: «может утверждать», «видит баланс», «управляет сотрудниками». Это уже логика вашего кабинета, а не штатная механика групп.

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

Типовые роли в B2B-портале

Теперь сам набор ролей. Он не высечен в камне — это конструктор, который подгоняют под процесс закупок конкретного клиента. Но есть типовой костяк из пяти ролей, который покрывает большинство оптовых компаний и от которого удобно отталкиваться.

Разберём каждую роль чуть подробнее, потому что за коротким названием стоит вполне конкретный смысл.

Администратор компании

Это ключевая роль на стороне покупателя, которую часто забывают заложить. Администратор — не тот, кто больше всех заказывает, а тот, кто управляет своей командой внутри портала: приглашает новых сотрудников, назначает им роли, задаёт лимиты, деактивирует уволенных, поддерживает актуальность реквизитов. По сути это делегированное самообслуживание: вместо того чтобы каждый раз просить менеджера поставщика «заведите нам ещё одного закупщика», компания управляет своим составом сама. Администратором обычно делают одного-двух доверенных людей.

Закупщик

Рабочая лошадка портала. Закупщик наполняет корзину, оформляет заказы, повторяет прошлые закупки, отправляет заявки на согласование. Ему нужны каталог, персональные цены, наличие и история своих заказов. А вот баланс, документы всей компании и управление сотрудниками ему, как правило, не нужны — и по принципу минимальных прав их лучше закрыть.

Утверждающий (руководитель)

Тот, кто принимает решение по заявке. Ему важно видеть состав и сумму заказа, данные закупщика и кнопки «утвердить» / «отклонить» / «вернуть на доработку». Утверждающий — центральная фигура согласования; как устроен сам маршрут утверждения, мы разбираем в отдельной статье про согласование и статусы заказов в B2B-портале.

Бухгалтер

Работает с деньгами и документами, но не оформляет закупки. Ему нужны баланс, кредитный лимит, дебиторка, счета, акты, УПД, сверка. Права на создание заказа у него обычно нет — это не его функция. Зато финансовый раздел открыт полностью.

Наблюдатель / склад

Роль «только чтение». Кладовщик хочет видеть, что и когда приедет; собственник — держать руку на пульсе; аналитик — смотреть историю. Никаких действий: ни заказать, ни утвердить, ни изменить. Такая роль полезнее, чем кажется, — она даёт прозрачность без риска.

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

Матрица прав: роль × действие

Роли удобно описывать, но чтобы их реализовать, нужно перевести их в конкретные права на действия. Лучший инструмент для этого — матрица прав: таблица, где по строкам роли, по столбцам действия, а в ячейках — можно или нельзя. Такая матрица снимает споры и двусмысленность: видно, кто на что имеет право, одним взглядом.

Вот типовая матрица прав B2B-портала — её всегда уточняют под клиента, но как отправная точка она рабочая:

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

Обратите внимание на строку «Просмотр всех заказов компании». Здесь кроется важная развилка: закупщик обычно видит только свои заказы, а утверждающий, бухгалтер и наблюдатель — все заказы контрагента. Это тонкое право «видимости данных», которое одними группами Битрикса не описать, — его реализуют кастомной логикой фильтрации по роли и контрагенту.

Право создавать и оформлять заказ

Разберём ключевые права по отдельности — начнём с самого частого действия — оформления заказа. На первый взгляд оно простое: «может заказывать или нет». Но в B2B за ним стоит несколько нюансов.

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

Во-вторых, у права заказа есть градации:

• Полное право. Создаёт черновики, оформляет заказы, отправляет на согласование, повторяет прошлые закупки — типичный закупщик.
• Ограниченное право. Может собирать корзину и черновики, но финальное оформление доступно только после утверждения — характерно для младших сотрудников.
• Без права. Роль вообще не оформляет заказы — бухгалтер, наблюдатель. Кнопки оформления им не показывают и, что важнее, действие блокируют на сервере.

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

Наконец, важный принцип: даже если у роли нет права оформлять заказ, проверка этого должна стоять на сервере. Спрятать кнопку «Оформить» в интерфейсе недостаточно — если действие можно вызвать прямым запросом, оно должно быть отклонено бэкендом. Об этом подробнее в разделе про безопасность.

Право видеть цены и персональные условия

В B2B цена — чувствительные данные. У каждого контрагента свои условия: скидки, тип цены, персональный прайс. И вопрос «кто внутри компании видит цены» тоньше, чем кажется.

Как правило, цены видят все сотрудники контрагента — потому что все они относятся к одной оптовой группе с одним типом цены. Закупщику цены нужны, чтобы собирать заказ; утверждающему — чтобы оценивать сумму; бухгалтеру — чтобы сверять счета; даже наблюдателю обычно показывают цены, ведь он смотрит заказы. Поэтому базовая видимость цены чаще определяется не ролью внутри компании, а группой контрагента: к какой ценовой категории он отнесён.

Здесь важно не путать два разных разграничения:

• Между контрагентами. Дилер категории A видит одну цену, категории B — другую, розница — третью. Это делается группами пользователей и типами цен Битрикса. Тема большая, мы разбираем её в статье про оптовые цены по группам клиентов в 1С-Битрикс.
• Внутри одного контрагента. Между ролями цену обычно не прячут — все сотрудники одной компании видят одинаковую цену. Роль разграничивает не цену, а действия и финансовые данные (баланс, документы).

Бывают исключения. Иногда компания хочет скрыть цены от роли «склад», которой они не нужны и которую лишний раз не стоит посвящать в закупочные условия. Или показать закупщику цену, но скрыть от него итоговые суммы по компании. Это уже тонкая настройка, и её делают кастомной логикой поверх базовой видимости. Но по умолчанию правило простое: цену определяет группа контрагента, а не роль внутри него.

Право утверждать заказы

Право утверждать — самое «весомое» в ролевой модели, потому что именно оно даёт контроль над деньгами компании. И именно вокруг него больше всего ошибок.

Ключевое правило, которое легко упустить: закупщик не должен утверждать собственную заявку. Даже если человек совмещает роли закупщика и утверждающего, для конкретного заказа, который он сам создал, утверждающим должен быть кто-то другой. Иначе разделение ответственности превращается в фикцию — портал лишь имитирует контроль. Это правило проверяют в коде, а не только скрытием кнопки «утвердить» у автора заявки.

Право утверждать обычно не плоское, а связано с лимитами и уровнями:

• Кто утверждает. Право одобрять заявки есть у утверждающего и, как правило, у администратора компании. У закупщика, бухгалтера и наблюдателя его нет.
• До какой суммы. Утверждающий уровня «руководитель отдела» одобряет заявки до своего порога; сверх него заявка поднимается к финдиректору или директору. Это многоступенчатое утверждение.
• Кого именно. Утверждающий видит и одобряет заявки только своей компании и, возможно, только своего подразделения — но не чужих контрагентов.

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

Доступ к документам, балансу и дебиторке

Финансовый блок кабинета — баланс, кредитный лимит, дебиторка, счета, акты, УПД, сверка — это самые чувствительные данные после цен. Доступ к ним разграничивают особенно аккуратно, потому что здесь ошибка означает, что кто-то увидел деньги и документы, которые ему не положены.

Кому что обычно открыто:

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

Отдельно про счета: у закупщика часто оставляют доступ к счетам по его собственным заказам — чтобы он мог скачать счёт и передать в оплату, — но закрывают общий финансовый раздел компании. Это тот случай, когда одно право («видеть документы») дробится на подправа по признаку «свой / общий».

Право менять реквизиты контрагента

Реквизиты — юридический адрес, банковские счета, контактные данные, подписант — это то, на основании чего выставляются документы и идут платежи. Право их менять — одно из самых «опасных», потому что ошибка или злоупотребление здесь бьёт по документообороту и деньгам.

Поэтому право менять реквизиты обычно отдают только администратору компании — и то не всегда напрямую. Часто действует более осторожная схема:

• Просмотр — многим, изменение — единицам. Реквизиты видят те, кому они нужны для работы, но менять может только администратор.
• Изменение через заявку. Администратор не меняет реквизиты мгновенно, а отправляет заявку на изменение, которую подтверждает менеджер поставщика. Это защищает от подмены банковских реквизитов.
• Синхронизация с 1С. Реквизиты — часть карточки контрагента в учётной системе. Их изменение согласуют с 1С, чтобы данные на сайте и в учёте не разошлись.

Логика проста: чем сильнее действие влияет на деньги и юридическую сторону сделки, тем уже круг тех, кто его может совершить, и тем больше вокруг него контроля. Смена банковских реквизитов через самообслуживание без подтверждения — известный вектор мошенничества, поэтому здесь осторожность оправдана. Разумный баланс — администратор инициирует изменение, а фиксирует его поставщик после проверки.

Право приглашать и вести сотрудников

Это право — сердце самообслуживания контрагента. Без него каждое кадровое изменение (новый закупщик, уволившийся бухгалтер) превращается в заявку менеджеру поставщика, а тот вручную заводит и отключает людей. С ним компания управляет своим составом сама, а поставщик разгружен.

Право вести сотрудников отдают администратору компании и включает оно несколько действий:

• Пригласить сотрудника. Отправить приглашение по e-mail — новый человек регистрируется и автоматически привязывается к нужному контрагенту.
• Назначить роль. Определить, кто новичок: закупщик, утверждающий, бухгалтер, наблюдатель — с соответствующими правами.
• Задать лимит. Указать, до какой суммы сотрудник действует сам, а с какой включается согласование.
• Деактивировать. Отключить доступ уволенного, сохранив его историю действий.
• Передать полномочия. Назначить заместителя на время отпуска или сменить утверждающего.

Здесь есть тонкая грань доверия. Право приглашать и назначать роли — мощное: администратор фактически распоряжается тем, кто и что может делать в закупках компании. Поэтому администраторов делают немного (обычно один-два), а действия по управлению сотрудниками логируют особенно тщательно — кто кого пригласил, кому какую роль дал, кого отключил. Об этом в разделе про аудит.

Важный нюанс безопасности: администратор контрагента управляет только своими сотрудниками. Он не должен видеть или трогать пользователей других компаний — его «песочница» ограничена его же контрагентом. Это реализуется той же изоляцией по привязке к контрагенту, что и везде.

Лимиты полномочий и делегирование

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

Лимит полномочий — чаще всего денежный порог: до какой суммы сотрудник действует самостоятельно. Логика знакома любому, кто работал в компании с бюджетом:

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

Ключевое: лимиты — это финансовая политика покупателя, а не настройка сайта. Кто и до какой суммы может распоряжаться закупками, решает сама компания, исходя из уровня доверия и своей культуры. Портал только применяет заданные цифры, проверяя каждый заказ. Поэтому при внедрении сначала выясняют лимиты, а потом настраивают — не наоборот. И задаёт лимиты администратор контрагента внутри своей команды.

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

И лимиты, и делегирование должны проверяться на сервере при каждом действии. Если ограничение «до 50 тысяч» живёт только в интерфейсе, его легко обойти прямым запросом. Настоящий лимит — тот, что проверяется бэкендом в момент оформления заказа, а не тот, что прячет кнопку.

Привязка пользователей к контрагенту

Всё разграничение ролей держится на одном фундаменте — привязке пользователя к контрагенту. Это связь «этот аккаунт принадлежит этой организации», и именно она определяет, чьи данные человек видит и от чьего имени действует. Без надёжной привязки любая ролевая модель рассыпается: непонятно, чьи заказы показывать и чей баланс открывать.

Как устроена привязка на практике:

• Один контрагент — много пользователей. К организации привязано несколько учётных записей сотрудников. У каждого своя роль, но контрагент общий.
• Пользователь знает свой контрагент. В профиле пользователя хранится ссылка на его организацию (свойство пользователя или связь через отдельную сущность).
• Все данные фильтруются по контрагенту. Заказы, документы, баланс, лимит — всё выбирается с условием «где контрагент = контрагент текущего пользователя».
• Роль уточняет доступ внутри контрагента. Привязка отвечает на вопрос «чьи данные», роль — «какие из них и что можно с ними делать».

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

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

Доступ к разделам кабинета по роли

Роль влияет не только на действия, но и на то, какие разделы личного кабинета человек вообще видит. Один и тот же кабинет показывает разным ролям разный набор пунктов меню — это делает интерфейс чище и заодно закрывает то, что роли не положено.

Как обычно выглядит меню кабинета по ролям:

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

Поэтому правильная схема двухслойная: меню формируется по роли (для удобства), а каждый раздел независимо проверяет право доступа на входе (для безопасности). Тогда даже если человек угадает URL закрытого раздела, он получит отказ, а не чужие данные.

Группы пользователей Битрикса как фундамент

Перейдём к реализации. Первый её слой — штатные группы пользователей 1С-Битрикс. Это встроенный механизм платформы, и на нём удобно строить базовое разграничение доступа: к разделам, модулям, а главное для B2B — к типам цен.

Что группы дают в ролевой модели:

• Тип цены. Группа определяет, какую цену видит контрагент. Все сотрудники одной компании обычно в одной оптовой группе — видят одинаковую цену.
• Доступ к закрытому каталогу. Через группы закрывают опт от неавторизованных и от розницы — каталог и цены видны только «своим».
• Базовые права на разделы. Штатные права доступа групп к модулям и инфоблокам — грубый уровень, «пускать или нет».
• Основа для правил скидок. Правила работы с корзиной и наценки часто завязаны на группу пользователя.

Но у групп есть предел применимости, и его важно понимать. Группы хорошо разделяют категории контрагентов («дилер A», «дилер B», «розница»), но плохо описывают роли внутри одной компании. Если пытаться сделать под каждую роль свою группу («закупщики дилера A», «бухгалтеры дилера A», «утверждающие дилера A»...), групп станет столько, что ими будет невозможно управлять, а тонкие права вроде «видит только свои заказы» они всё равно не выразят.

Поэтому здоровая схема разделяет ответственность так: группы отвечают за ценовую категорию и базовый доступ, а роли внутри контрагента — за кастомные права личного кабинета. Обычно все сотрудники одного контрагента сидят в одной группе (одна цена, один каталог), а различаются ролью, которая хранится отдельно и определяет их действия. Как настраивают доступ к ценам и каталогу через группы, мы подробно разбираем в статьях про оптовые цены по группам и закрытый оптовый раздел на 1С-Битрикс.

Кастомные права личного кабинета

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

Как обычно устроен этот слой:

• Роль как свойство пользователя. У каждого пользователя хранится его роль внутри контрагента (закупщик, утверждающий, бухгалтер, наблюдатель, администратор) — как свойство пользователя или запись в отдельной таблице.
• Права как проверяемые правила. Действия («может оформить заказ», «может утвердить», «видит баланс») — это функции-проверки, которые смотрят на роль и лимит пользователя и возвращают «можно/нельзя».
• Единая точка проверки. Все проверки прав собраны в одном месте (сервис прав), а не разбросаны по шаблонам. Контроллеры и компоненты спрашивают у него разрешение перед действием.
• Фильтрация данных по роли. Списки заказов, документов, заявок фильтруются с учётом роли и контрагента — «свои / все / никакие».

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

И здесь неизменное правило кастомизации Битрикса: не править ядро и штатные компоненты напрямую. Ролевую логику реализуют через собственные модули, события, наследование и копии шаблонов. Тогда обновление платформы не затрёт доработки, и разграничение прав переживёт апдейты. Аккуратная реализация — то, что отличает поддерживаемый портал от «однажды собранного и боящегося обновлений».

Приглашение и деактивация сотрудников

Ролевая модель живёт не в вакууме — состав сотрудников меняется: кто-то приходит, кто-то увольняется. Как портал управляет этим жизненным циклом, определяет, будет ли ролевая система удобной или превратится в постоянную головную боль поддержки.

Разложим процесс по шагам — как правильно заводить и отключать людей:

1. Приглашение по e-mail. Администратор компании (или менеджер поставщика) вводит e-mail нового сотрудника и отправляет приглашение — письмо со ссылкой на регистрацию.
2. Регистрация и привязка. Человек переходит по ссылке, задаёт пароль — и его аккаунт автоматически привязывается к нужному контрагенту. Не нужно вручную вводить реквизиты компании: приглашение уже «знает» организацию.
3. Назначение роли и лимита. Администратор выбирает роль новичка и, если нужно, задаёт лимит полномочий. С этого момента сотрудник видит и может ровно то, что положено его роли.
4. Работа. Сотрудник действует в рамках роли: оформляет заказы, утверждает, смотрит документы — что разрешено.
5. Деактивация при увольнении. Когда человек уходит, администратор переводит его в неактивные: доступ закрыт, но история действий сохранена и привязана к нему.

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

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

Аудит действий пользователей

Роли и права определяют, кто что может делать. Аудит фиксирует, кто что сделал. Это разные вещи, и вторая не менее важна: без журнала действий разграничение доступа теряет половину смысла, потому что нарушения и ошибки невозможно ни заметить, ни разобрать.

Что стоит логировать в B2B-портале:

• Действия с заказами. Кто создал, отправил на согласование, утвердил, отклонил, отменил — с датой и временем.
• Управление сотрудниками. Кто кого пригласил, какую роль назначил, кому сменил лимит, кого деактивировал.
• Изменение реквизитов. Кто и когда менял банковские и юридические данные — самое чувствительное.
• Доступ к финансам. При необходимости — факты просмотра баланса, скачивания документов (для особо строгих требований).
• Входы и попытки доступа. Успешные и неуспешные, особенно попытки обратиться к закрытым разделам.

Аудит решает несколько задач сразу. Он дисциплинирует: когда люди знают, что действия фиксируются, злоупотреблений меньше. Он помогает в разборах: спорную ситуацию («кто утвердил эту закупку?», «кто сменил реквизиты?») закрывают за секунды, а не в переписке. И он обнаруживает аномалии: серия неуспешных попыток обратиться к чужим данным — сигнал, что кто-то щупает границы доступа.

Особое внимание — действиям с деньгами и людьми. Изменение реквизитов, назначение ролей, утверждение крупных заказов — это то, что стоит логировать максимально подробно и хранить дольше обычного. А журнал должен быть защищён от правки самими пользователями: если действия можно «подчистить», аудит бесполезен. Именно поэтому история согласования и журнал действий — часть доверия к порталу и у покупателя, и у поставщика.

Роли и 1С: контрагент и контактные лица

B2B-портал почти всегда работает в связке с 1С, и ролевую модель важно правильно состыковать с учётной системой. Ключевой вопрос — где живут контрагент, его сотрудники и их права.

Разложим, что где хранится:

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

При этом роли и права чаще живут на стороне портала, а не в 1С. Учётной системе не важно, кто из сотрудников контрагента — закупщик, а кто утверждающий; ей важен сам контрагент и факт заказа. Поэтому ролевую модель обычно не тащат в 1С — она остаётся логикой кабинета. А вот базовое соответствие «пользователь сайта ↔ контактное лицо контрагента» поддерживать стоит, чтобы данные не расходились и заказы корректно ложились в учёт. Как в принципе устроен обмен заказами и данными с учётной системой, мы разбираем в статье про интеграцию интернет-магазина с 1С.

Отдельно про регистрацию и первичную привязку. Когда новый контрагент только заходит на портал, его нужно верифицировать и связать с карточкой в 1С (или создать новую). Этот процесс — регистрация и проверка B2B-клиента — мы описали отдельно в статье про регистрацию и верификацию B2B-клиентов на 1С-Битрикс; ролевая модель включается уже после того, как контрагент подтверждён и к нему привязан первый пользователь-администратор.

Безопасность и минимально необходимые права

Разграничение доступа — это в первую очередь безопасность, поэтому соберём принципы, на которых она держится. Их немного, но каждый критичен.

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

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

Изоляция данных контрагентов. Заказы, документы, баланс, сотрудники одной компании недоступны другой — ни через интерфейс, ни подбором ссылки, ни через API. Каждый запрос фильтруется по привязке пользователя к контрагенту. Утверждающий видит только заявки своей компании, администратор управляет только своими людьми. Это — фундамент, без которого весь портал небезопасен.

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

Реализация: группы, права, привязка

Соберём всё сказанное в цельную картину реализации. Разграничение доступа в B2B-портале на 1С-Битрикс стоит на трёх опорах, и каждая отвечает за свой уровень.

1. Группы пользователей Битрикса — базовый доступ и цена. Через группы задают ценовую категорию контрагента, доступ к закрытому каталогу и грубые права на разделы. Все сотрудники одной компании обычно в одной оптовой группе.
2. Привязка к контрагенту — изоляция данных. Каждый пользователь связан со своей организацией; все заказы, документы, баланс фильтруются по этой привязке. Это несущая конструкция изоляции контрагентов.
3. Кастомные права личного кабинета — роли и действия. Роль пользователя и тонкие права (оформить, утвердить, видеть баланс, менять реквизиты, вести сотрудников) живут в собственном слое кабинета и проверяются на сервере.
4. Лимиты и делегирование — пределы полномочий. До какой суммы сотрудник действует сам, кто кого замещает — задаёт администратор контрагента, проверяет бэкенд при каждом действии.
5. Аудит — журнал действий. Кто что сделал с заказами, сотрудниками и реквизитами, защищённый от правки, — для разборов, дисциплины и обнаружения аномалий.
6. Стык с 1С — контрагент и контактные лица. Организация на портале соответствует контрагенту в 1С, пользователи — его контактным лицам; роли остаются на сайте, финансовые данные приходят обменом.

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

Частые ошибки при настройке ролей

Эти промахи повторяются в B2B-проектах чаще всего — зная их заранее, вы сэкономите время и нервы:

• Один логин на всю компанию. Классика. Непонятно, кто что сделал, все видят всё, согласование невозможно, при увольнении меняют общий пароль. Как только сотрудников больше одного — это дыра.
• Все видят всё. Роли заведены, но права не разграничены: закупщик видит баланс и документы, наблюдатель может оформлять заказы. Ролевая модель для галочки, без реального смысла.
• Закупщик утверждает сам себя. Автор заявки может её же и одобрить — контроля нет, портал имитирует согласование. Правило «нельзя утвердить свою заявку» не заложено.
• Права проверяются в вёрстке. Кнопки скрыты, но действие вызывается прямым запросом. Данные и операции доступны в обход интерфейса — это не защита, а иллюзия.
• Роли выражены только группами Битрикса. Под каждую комбинацию прав плодят отдельную группу; групп десятки, управлять невозможно, тонкие права всё равно не выражаются.
• Аккаунты удаляют вместо деактивации. При увольнении запись стирают, история заказов и согласований остаётся «ничьей», аудит рассыпается.
• Нет роли администратора компании. Каждое кадровое изменение идёт через менеджера поставщика вручную — долго и неудобно; самообслуживание не заложено.
• Лимиты и пороги придумал подрядчик. Суммы «по аналогии» вместо реальной финансовой политики покупателя — модель не приживается.
• Нет изоляции контрагентов. Подбором ссылки или через API можно достучаться до чужих заказов и документов — запросы не фильтруются по привязке к контрагенту.
• Нет замены утверждающего. Единственный утверждающий ушёл в отпуск — заявки зависли, поставки сорваны. Делегирование и заместители не предусмотрены.
• Реквизиты меняет кто угодно. Право смены банковских данных не ограничено администратором и не подтверждается — прямой вектор мошенничества.
• Персональные разделы кэшируются для всех. Из общего кэша один пользователь получает чужой баланс и заказы — и ошибка, и утечка одновременно.

Чек-лист внедрения ролей и прав

Короткий список для приёмки ролевой модели перед запуском — по нему удобно проверить, что разграничение доступа закрыто и не развалится в эксплуатации:

1. Реальная структура закупок описана. Известно, кто в компании готовит, кто одобряет, кто платит, кто контролирует — до настройки, а не после.
2. Набор ролей согласован с клиентом. Администратор, закупщик, утверждающий, бухгалтер, наблюдатель — или их вариант под конкретный процесс.
3. Матрица прав заполнена. Для каждой роли явно определено, что можно и чего нельзя; начата от закрытого состояния.
4. Несколько пользователей на контрагента. У каждого сотрудника своя учётная запись со своей ролью; общего логина нет.
5. Привязка к контрагенту работает. Все данные фильтруются по организации; чужое недоступно ни через интерфейс, ни по ссылке.
6. Запрет самоутверждения заложен. Закупщик не может одобрить собственную заявку; проверка на сервере.
7. Лимиты и делегирование заданы. До какой суммы кто действует сам; есть заместители на время отсутствия; всё проверяется бэкендом.
8. Разделы кабинета разграничены. Меню по роли для удобства, плюс независимая проверка права на входе в каждый раздел.
9. Финансы закрыты по ролям. Баланс, лимит, документы видят только те, кому положено; данные приходят из 1С.
10. Приглашение и деактивация настроены. Администратор ведёт сотрудников сам; уволенных деактивируют с сохранением истории.
11. Аудит действий ведётся. Заказы, управление сотрудниками, смена реквизитов логируются; журнал защищён от правки.
12. Стык с 1С состыкован. Контрагент и контактные лица соответствуют учёту; роли остаются на портале.
13. Безопасность на бэкенде. Минимальные права, серверная проверка, изоляция контрагентов, корректный кэш.

Вывод

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

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