Как раздать права в 1С: роли, профили и группы доступа

Раздача прав в 1С — это не просто установка галочек напротив ролей. Ошибка в настройке приводит либо к тому, что сотрудник не может провести документ, либо к противоположной ситуации: пользователь видит лишние данные, включая зарплату коллег или финансовые отчёты. Правильный подход зависит от того, работаете вы с типовой конфигурацией (УТ 11, ERP, Бухгалтерия 3.0, ЗУП) или с самописной, и от того, хватает ли стандартных профилей.

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

Ниже разобраны оба способа, типовые роли, ограничение доступа на уровне записей (RLS), проверка результата и частые ошибки. Материал ориентирован на администратора или внедренца, который настраивает доступ впервые либо систематизирует уже существующие права.

Как устроена система прав в 1С

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

Поверх ролей в типовых конфигурациях работает механизм профилей групп доступа из библиотеки стандартных подсистем (БСП). Профиль — это именованный набор ролей, например «Менеджер по продажам» или «Бухгалтер». Пользователь включается в группу доступа, группе назначен профиль — так права отделяются от конкретного человека и легко переназначаются при смене сотрудника.

Дополнительный слой — ограничение доступа на уровне записей (RLS). Оно позволяет разрешить пользователю работу с документами только своей организации или своего склада, даже если роль в целом даёт доступ к виду документов. RLS настраивается через группы доступа контрагентов, организаций, складов и других объектов.

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

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

Проверьте, что у вас самого есть права администратора (роль «Полные права» / «Администратор системы»), иначе разделы настройки будут недоступны. Создайте резервную копию информационной базы, если планируете менять роли в конфигураторе или массово переназначать профили — откат настроек вручную занимает много времени.

Убедитесь, что пользователи уже заведены в базе: Администрирование → Настройки пользователей и прав → Пользователи. Для файловой базы список пользователей ведётся внутри конфигурации, для клиент-серверной — также возможна аутентификация через домен (Windows-аутентификация), что упрощает управление учётными записями.

Раздача прав в типовой конфигурации через профили

Основной сценарий для УТ 11, ERP, КА, БП 3.0 и ЗУП 3.1 выглядит так. Откройте раздел Администрирование → Настройки пользователей и прав → Профили групп доступа. Здесь уже есть предопределённые профили типовой поставки: «Бухгалтер», «Менеджер по продажам», «Кладовщик» и другие. Часто достаточно использовать их без изменений.

Если типовой профиль не подходит, создайте свой: нажмите «Создать», задайте понятное имя (например, «Менеджер по продажам — без изменения цен») и отметьте нужные роли в списке. Роли сгруппированы по подсистемам, поэтому ориентируйтесь на названия. Сохраните профиль.

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

1. 1
   Откройте Администрирование → Настройки пользователей и прав → Профили групп доступа
2. 2
   Создайте профиль или скопируйте типовой, отметьте нужные роли
3. 3
   Перейдите в Группы доступа, создайте группу и привяжите профиль
4. 4
   Добавьте пользователей в состав группы доступа
5. 5
   Попросите пользователя перезайти и проверьте доступ к его рабочим документам

Как ограничить доступ на уровне записей (RLS)

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

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

Назначение ролей в конфигураторе

Для нетиповых конфигураций или когда механизм профилей не используется, роли назначаются напрямую. Откройте конфигуратор, перейдите в Администрирование → Пользователи, выберите пользователя и на вкладке «Прочие» отметьте доступные роли. Список ролей определяется конфигурацией: в нетиповых решениях их имена могут не говорить сами за себя, поэтому сверяйтесь с документацией разработчика.

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

Если стандартных ролей не хватает, разработчик может создать новую роль в дереве конфигурации (Общие → Роли) и разметить права по объектам. Это уже доработка конфигурации: она требует тестирования на копии базы и усложняет обновление, если конфигурация на поддержке.

Два способа раздачи прав

Профили групп доступа (пользовательский режим)

Подходит для типовых конфигураций. Не требует конфигуратора, легко переназначается, поддерживает RLS. Ограничение: состав ролей фиксирован поставкой.

Роли в конфигураторе

Подходит для нетиповых решений и служебных учёток. Гибче, но требует полных прав разработчика и в типовых базах может быть перезаписан механизмом БСП.

Проверка результата и типовые ошибки

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

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

Ограничения и когда нужен специалист

Самостоятельная настройка через профили безопасна и обратима: худшее, что случится, — пользователь временно не сможет выполнить операцию. Но есть зоны, где лучше привлечь специалиста по 1С: создание собственных ролей, доработка типовых профилей путём добавления ролей в расширении, настройка сложных схем RLS с несколькими измерениями (организация + склад + контрагент одновременно).

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

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

Частые вопросы

Пользователь не видит нужный документ, хотя профиль назначен. Что проверить?

Сначала убедитесь, что пользователь реально входит в группу доступа с нужным профилем, а не только указан в справочнике пользователей. Затем проверьте, не включено ли ограничение на уровне записей: если RLS активен, а организация или контрагент не входят в разрешённые группы доступа, документ будет скрыт. Также проверьте дату документа относительно даты запрета изменения данных.

Можно ли дать права только на просмотр без изменения?

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

Как быстро передать права новому сотруднику на должность уволенного?

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

Почему роли, установленные в конфигураторе, пропадают?

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

Как ограничить доступ к данным по зарплате?

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

Нужно ли перезапускать сервер 1С после изменения прав?

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