Администрирование · 12 мин
Настройка прав пользователя в 1С:Розница
Как настроить права пользователя в 1С:Розница: профили групп доступа, роли, ограничение на уровне записей, типичные ошибки и проверка результата.
Разграничение прав в 1С:Розница строится на двух уровнях: роли определяют, какие объекты конфигурации доступны пользователю в принципе, а профили и группы доступа собирают эти роли в удобные наборы — «Кассир», «Менеджер», «Администратор». Правильно настроенная связка «пользователь → группа доступа → профиль → роли» позволяет кассиру работать только в РМК, менеджеру — вести товары и цены, а администратору — управлять системой целиком, не мешая друг другу.
Большинство магазинов совершают одну и ту же ошибку: выдают всем сотрудникам полные права «на время», а потом забывают сузить. Результат — случайно изменённые цены, удалённые чеки, расхождения в учёте и невозможность установить, кто именно допустил ошибку. Настройка занимает от 15 минут до часа и выполняется штатными средствами, без доработок конфигурации.
Ниже разобран полный цикл: от создания пользователя до проверки, что ограничения реально работают. Инструкция ориентирована на типовую 1С:Розница редакции 2.3/3.0, но общая логика профилей и ролей одинакова во всех конфигурациях на БСП (Библиотека стандартных подсистем).
Как устроена модель прав в 1С:Розница
Механизм прав состоит из четырёх связанных элементов. Роль — это атомарное разрешение на чтение, добавление, изменение или удаление конкретных объектов (документов, справочников, регистров). Роли зашиты в конфигурацию, и менять их без режима «Конфигуратор» нельзя. Профиль группы доступа — это именованный набор ролей, который администратор собирает или корректирует под должность: «Кассир», «Товаровед», «Менеджер по закупкам».
Группа доступа объединяет пользователей и привязывает их к профилю. Один пользователь может входить в несколько групп — тогда его права суммируются. Наконец, ограничение доступа на уровне записей (RLS) фильтрует данные внутри разрешённых объектов: например, менеджер видит только документы своего магазина, хотя формально документы ему доступны.
Практический вывод: если пользователь жалуется «нет доступа», причина почти всегда в одном из трёх мест — не включён пользователь в группу доступа, в профиле не хватает роли, либо RLS отсекает конкретные записи. Проверять нужно в этом же порядке, от простого к сложному.
Заведение пользователя и назначение профиля
Откройте раздел «Администрирование → Настройка пользователей и прав → Пользователи». Нажмите «Создать» и заполните карточку: полное имя, имя для входа (логин), при необходимости — пароль и признак «Аутентификация 1С:Предприятия». Если магазин работает в домене, можно включить аутентификацию операционной системы, чтобы кассир не вводил пароль отдельно.
На вкладке «Права доступа» (или через ссылку «Группы доступа») добавьте пользователя в нужную группу. В типовой поставке уже есть группы с готовыми профилями: «Кассиры», «Администраторы», «Менеджеры». Если готовый профиль не подходит, создайте свой в разделе «Профили групп доступа»: скопируйте ближайший типовой профиль и снимите/добавьте отдельные разрешения. Копирование безопаснее редактирования типового профиля — при обновлении конфигурации типовые профили могут перезаписаться.
После сохранения попросите пользователя перезайти в базу: права применяются при новом сеансе. Если пользователь работал в момент изменения прав, старый набор ролей действует до конца его сеанса — это частая причина ложных выводов «настройка не сработала».
Ограничение доступа на уровне записей (RLS)
RLS нужен, когда в одной базе работает несколько магазинов или организаций и сотрудники не должны видеть чужие данные. Включите механизм в «Администрирование → Настройка пользователей и прав → Группы доступа», установив флаг «Ограничивать доступ на уровне записей». Затем в карточке группы доступа на вкладке «Ограничения доступа» укажите разрешённые значения: конкретные магазины, организации, склады, кассы.
После включения RLS пользователь группы увидит только документы и остатки по разрешённым значениям. Учтите важный нюанс: если пользователь входит в две группы, и в одной ограничение задано, а в другой — «все разрешены», действует более широкое разрешение. Поэтому группы с «полным» доступом и группы с RLS нельзя смешивать для одного человека.
Производительность — главная цена RLS. На больших базах сложные ограничения замедляют формирование списков и отчётов, потому что к каждому запросу добавляются условия проверки. Включайте RLS только там, где он реально необходим, и по возможности ограничивайте по одному виду доступа (например, только по магазинам), а не по пяти одновременно.
Проверка, что права работают
Настройка без проверки не считается завершённой. Войдите в базу под учётной записью пользователя и пройдите контрольный список: открывается ли РМК, доступны ли запрещённые документы, видит ли пользователь чужие магазины. Проверяйте не только «что открывается», но и «что не должно открываться» — попытка открыть запрещённый документ должна завершаться штатным сообщением о нарушении прав, а не пустой формой или ошибкой.
Дополнительный инструмент — отчёт «Анализ прав доступа» (в разделе администрирования, доступность зависит от версии БСП): он показывает, какие роли есть у пользователя и откуда они взялись. Если пользователь видит лишнее, отчёт поможет найти группу, через которую «протекло» лишнее разрешение. Также полезно периодически смотреть журнал регистрации по событиям «Отказ в доступе» — массовые отказы у одного пользователя означают, что профиль собран неполно.
Как проверить результат
Открывается РМК, продажа и закрытие смены проходят
Ошибки доступа при открытии РМК или доступны документы ценообразования
В списках документов только разрешённый магазин
Видны документы всех магазинов или списки пустые
Штатное сообщение «Нарушение прав доступа»
Объект открывается либо падает с технической ошибкой
Типичные ошибки при настройке прав
Первая ошибка — назначение ролей напрямую пользователю в обход профилей (галочки ролей в карточке пользователя, если она доступна в вашей версии). Это разрушает управляемость: через полгода никто не помнит, кому и зачем выдали отдельную роль. Вторая ошибка — редактирование типовых профилей «Администратор» и «Кассир»: при обновлении конфигурации изменения могут затереться или, наоборот, конфликтовать с новыми ролями.
Третья группа ошибок связана с RLS: включение ограничений без проверки на тестовом пользователе, смешение групп с ограничениями и без, ограничение по слишком многим видам доступа. Наконец, частая организационная ошибка — отсутствие процедуры отключения прав уволенного сотрудника. Деактивируйте пользователя (снимите флаг «Вход в программу разрешён») в день увольнения, не удаляя саму учётную запись — она нужна для истории в журнале регистрации.
Когда стандартных профилей не хватает
Если требуется разрешение, которого нет ни в одном типовом профиле (например, «только просмотр отчёта по продажам без доступа к документам»), соберите отдельный профиль с минимальным набором ролей: базовые роли БСП для входа в систему плюс роли на нужные отчёты. Состав ролей смотрите в конфигураторе или в типовом профиле-доноре.
Предельный случай — доработка ролей в конфигураторе. Это оправдано редко: почти всё решается комбинацией профилей и RLS. Доработка ролей снимает конфигурацию с полной поддержки и усложняет обновления, поэтому сначала исчерпайте штатные средства. Если задача нестандартная (например, запрет изменения документов старше определённой даты), посмотрите механизм «Даты запрета изменения данных» в разделе администрирования — он работает поверх ролей и не требует доработок.
Удобно завести в базе «эталонного» тестового пользователя для каждого профиля — тестового кассира, тестового менеджера. Перед обновлением конфигурации или изменением прав заходите под ними и прогоняете ключевые операции. Это занимает пять минут и отлавливает проблемы до того, как с ними столкнутся реальные сотрудники.
Частые вопросы
Кассир не может открыть РМК, пишет «Нарушение прав доступа». Что делать?
Проверьте, что пользователь включён в группу доступа с профилем «Кассир» и что он перезашёл в базу после назначения прав. Если профиль самодельный, убедитесь, что в него включены базовые роли БСП (например, «Базовые права») и роли на кассовые документы и РМК. Также проверьте, не отсекает ли RLS кассу ККМ пользователя.
Можно ли дать пользователю права только на просмотр без изменения?
Да. Создайте копию нужного профиля и снимите в нём разрешения на добавление, изменение и удаление, оставив только чтение и просмотр. Для отдельных объектов ограничение «только чтение» настраивается в составе ролей профиля.
Почему после изменения профиля у пользователя ничего не поменялось?
Права применяются при старте сеанса: пользователь должен завершить работу и войти заново. Если изменений нет и после перезахода, проверьте, не входит ли пользователь ещё в одну группу доступа с более широким профилем — права в 1С суммируются.
Как запретить кассиру делать возвраты?
Создайте копию профиля «Кассир» и уберите из неё роли на документ «Возврат товаров от покупателя» и на отмену чека. Возвраты при этом сможет оформлять старший кассир или менеджер под своей учётной записью — так сохраняется контроль и ответственность фиксируется в журнале.
Нужно ли настраивать права отдельно для каждого магазина сети?
Нет, если магазины работают в одной базе. Создайте по группе доступа на магазин (например, «Кассиры магазина №1») с одним и тем же профилем, но разными ограничениями RLS по магазину. Профиль остаётся общим, различаются только разрешённые значения доступа.
Что делать, если забыт пароль администратора в файловой базе?
Если в базе есть второй пользователь с полными правами, войдите под ним и сбросьте пароль в карточке пользователя. Если администратор единственный, потребуется восстановление доступа специалистом по 1С с использованием служебных механизмов — поэтому всегда держите минимум две учётные записи с полными правами.
Что важно запомнить
Настройка прав в 1С:Розница — это связка «пользователь → группа доступа → профиль → роли» плюс RLS для разделения данных по магазинам. Используйте копии типовых профилей, не выдавайте административные права без необходимости, делайте резервную копию перед изменениями и всегда проверяйте результат под учётной записью реального пользователя.