Что такое роли в 1с?

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

Зачем вообще нужны роли

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

Роли решают сразу несколько задач:

• Ограничение доступа к данным (например, зарплату видят только кадровики и бухгалтерия, а менеджеры — нет).

• Ограничение действий (один пользователь может только вводить документы, другой — проводить и отменять проведение).

• Упрощение интерфейса: пользователи видят только нужные им разделы и команды, остальное скрывается.

• Повышение безопасности: критичные функции (удаление, изменение проведённых документов, загрузка внешних обработок) доступны только выбранному кругу лиц.

  

Базовые понятия: пользователь, роль, права

Чтобы понимать, как работают роли, важно различать несколько терминов.

• Пользователь — конкретный человек (учётная запись), под которой человек входит в базу 1С.

• Роль — набор прав доступа к объектам и действиям системы: что можно делать, с чем работать, какие данные читать.

• Права — «атомарные» разрешения, из которых строится роль: чтение, запись, удаление, проведение и т.п. по конкретным объектам.

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

Как роли связаны с объектами конфигурации

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

Типичные примеры:

• Справочник «Номенклатура»: права на чтение, запись, удаление.

• Документ «Реализация товаров и услуг»: права на чтение, запись, проведение, отмену проведения, проведение по регистрам.

• Регистр накопления «Продажи»: права на чтение, запись (обычно закрыто для большинства пользователей).

• Отчёт «Продажи по менеджерам»: права на использование, возможно — ограничение по набору данных (через механизмы разделения доступа).

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

Принцип «атомарных» ролей

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

Примеры атомарных ролей:

• «Работа с документом Реализация» — даёт права только на документ «Реализация товаров и услуг» и связанные объекты.

• «Работа со справочником Контрагенты» — права только на контрагентов.

• «Просмотр отчетов по продажам».

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

Где в 1С настраиваются роли

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

Общий подход:

1. В конфигураторе открывается конфигурация (или расширение) и в дереве объектов есть ветка «Роли».

2. Через контекстное меню создаются новые роли или редактируются существующие.

3. Для каждой роли в таблице прав задаётся, что разрешено по объектам конфигурации.

Назначение ролей пользователям:

• В управляемых приложениях чаще делается в режиме предприятия: через раздел «Администрирование» → «Пользователи» (или аналог).

• В более старых/простых конфигурациях возможно назначение через список пользователей в конфигураторе.

  

Типичные преднастроенные роли в типовых конфигурациях

Большинство типовых решений 1С (Бухгалтерия, УТ, ERP и др.) уже содержат готовый набор ролей. Они ориентированы на стандартные должности и сценарии использования системы.

Часто можно встретить:

• «Администратор» — практически полный доступ ко всем объектам, включая сервисные функции.

• «Полные права» — роль с максимальными полномочиями для работы с прикладными объектами (но не всегда с техническими).

• «Бухгалтер», «Кассир», «Кладовщик», «Менеджер по продажам», «Руководитель» — роли, соответствующие привычным должностям.

Для простых внедрений бывает достаточно назначить пользователям одну из типовых ролей. Однако по мере развития учётной системы почти всегда возникает потребность в донастройке и создании дополнительных ролей под реальные процессы организации.

Как роли влияют на интерфейс и доступность команд

Интерфейс управляемого приложения в 1С зависит не только от выбранного функционального варианта, но и от ролей пользователя. Если у пользователя нет прав на конкретный объект, соответствующий раздел, команда или форма часто просто не отображается.

Практические эффекты:

• Если убрать право «Использование» для отчёта, он исчезнет из списка отчётов у пользователя.

• Если запретить чтение документа, пользователь не сможет его открыть по ссылке или из списка.

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

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

Пример: роль для менеджера по продажам

Рассмотрим практический пример типовой роли «Менеджер по продажам» в условной конфигурации.

Обычно менеджеру нужны:

• Справочники: Номенклатура, Контрагенты.

• Документы: Заказ клиента, Реализация, Счёт покупателю.

• Отчёты: Продажи, Дебиторская задолженность (только просмотр).

Какие права можно выдать:

• Чтение и запись элементов справочников (создание новых контрагентов и номенклатуры, если это допускается политикой компании).

• Создание и редактирование документов «Заказ клиента», «Реализация», но, возможно, без права удаления проведённых документов.

• Просмотр отчётов по продажам без права менять настройки доступа или параметры регистров.

Чего менеджеру не нужно:

• Доступ к зарплате, регламентированной отчётности, налоговым регистрам.

• Администрирование пользователей и технические настройки.

На основе этого администратор может либо использовать типовую роль, либо создать свою: «Менеджер по продажам (локальная)» и тонко настроить права под конкретную организацию.

Комбинирование ролей и наследование прав

В 1С нет классического наследования ролей, вместо этого используется комбинирование: одному пользователю можно назначить сразу несколько ролей, и права суммируются. Результирующий доступ — объединение всех разрешений всех ролей; запрет в одной роли не «перебивает» разрешение в другой.

Пример:

• Роль А: «Работа с документом Реализация» (разрешено чтение, запись, проведение).

• Роль Б: «Просмотр отчётов по продажам».

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

Роли в расширениях конфигурации

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

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

Практический смысл:

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

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

Роли и разделение доступа к данным

Отдельная важная тема — разделение доступа к данным (например, по организациям, подразделениям, складам). Роли определяют «что» пользователь может делать, а механизмы разделения доступа уточняют «с чем именно» он может это делать.

Примеры:

• У всех менеджеров одинаковая роль, но один работает по организации «ООО Альфа», а другой — по «ООО Бета»; в отчётах и документах они видят только свои организации.

• Кладовщики разных складов имеют одну и ту же роль, но каждый видит документы и остатки только по своему складу.

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

Типичные ошибки при работе с ролями

В реальных внедрениях часто встречаются одни и те же ошибки.

Наиболее распространённые:

• Всем дают роль «Администратор» или «Полные права», чтобы «ничего не сломалось» — в итоге нарушения регламента и риски по безопасности.

• Создают слишком общие роли, в которые «на всякий случай» добавляют лишние права; со временем никто уже не помнит, для чего что было включено.

• Изменяют типовые роли напрямую в конфигурации без документации, что усложняет обновления и поддержку.

• Не тестируют изменения ролей: пользователи внезапно перестают видеть нужные функции или, наоборот, получают лишний доступ.

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

Рекомендации по организации ролей в вашей базе

Для компаний, где пользователей больше трёх–пяти, имеет смысл сразу продумать структуру ролей.

Практические советы:

• Используйте говорящие наименования ролей: «Менеджер продаж (розница)», «Бухгалтер по зарплате», «Руководитель отдела продаж» и т.п.

• Не бойтесь разбивать крупные роли на несколько атомарных, если сотрудникам часто нужны вариации прав.

• Не изменяйте типовые роли без крайней необходимости — лучше создайте собственные дополнительные роли и комбинируйте их с типовыми.

• Ведите короткое описание роли (зачем она, для каких должностей, что в неё входит).

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

Как пользователю понять, что ему не хватает прав

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

• В интерфейсе нет нужного раздела или отчёта (хотя коллега говорит, что у него есть).

• При попытке открыть документ или отчёт появляется сообщение о недостаточности прав.

• Некоторые команды в формах недоступны (серые кнопки, нет пункта меню).

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

Полезно:

• Приложить скриншот экрана с сообщением об ошибке.

• Указать, какие действия выполнялись и какая роль (должность) у пользователя.

Это помогает администратору корректно настроить роли: добавить необходимые права или, наоборот, объяснить, почему доступ сознательно ограничен.

Итог: как объяснить роли «несколько словом пользователю»

Если объяснять совсем по-простому, можно сказать так: роль в 1С — это «набор возможностей» пользователя в программе. Как в пропускной системе: у пропуска есть список дверей, которые можно открыть, а также указано, можно ли только входить или ещё и закрывать, настраивать и т.д.

Для пользователя важно понимать:

• Роли нужны не для того, чтобы «мешать работать», а чтобы защитить данные и упорядочить работу.

• Если чего-то не хватает, это нормально и решается через администратора.

• Чем точнее описана рабочая задача, тем легче настроить правильные роли и сделать удобный интерфейс.