Ограничение доступа к отдельным разделам конфигурации 1С:Бухгалтерия предприятия 3.0 (далее БП 3.0) — это задача, с которой сталкиваются многие администраторы и программисты. Особенно остро стоит вопрос с разделом «Зарплата и кадры», когда необходимо предоставить бухгалтеру доступ ко всей остальной функциональности программы, но полностью скрыть или запретить работу с данными о зарплате и сотрудниках. Давайте рассмотрим, почему эта задача не так проста, как кажется на первый взгляд, и какие подходы к ее решению существуют, а также их достоинства и недостатки.
Основная сложность заключается в том, что в БП 3.0 права доступа часто сгруппированы в типовых ролях таким образом, что функциональность раздела «Зарплата и кадры» включена в общие роли, дающие доступ ко всей бухгалтерии. Например, роль Чтение и изменение данных бухгалтерии или Добавление и изменение данных бухгалтерии, необходимая для полноценной работы бухгалтера, одновременно предоставляет права и на объекты, связанные с учетом зарплаты и кадров. Мы не можем просто убрать эту роль у пользователя, иначе он потеряет доступ к огромному объему другой, критически важной бухгалтерской информации.
Если мы попробуем создать новый профиль доступа и просто исключить из него роли, отвечающие за ЗиК, то обнаружим, что пользователь лишается возможности работать со многими документами и отчетами, не имеющими прямого отношения к зарплате. Разработчики 1С предупреждают, что корректная работа программы гарантируется только для стандартных профилей, а пользовательские сочетания ролей требуют тщательной проверки и могут быть нестабильны.
Первое, что приходит на ум – это попытка скопировать существующий профиль, например, «Бухгалтер», и создать новый, исключив из него роли, связанные с «Зарплатой и кадрами». Рассмотрим этот подход подробнее.
Мы можем создать новый профиль доступа на основе типового профиля «Бухгалтер» через раздел «Администрирование» - «Настройки пользователей и прав» - «Профили групп доступа». Затем из этого скопированного профиля можно попытаться убрать роли, которые, как нам кажется, отвечают только за ЗиК (например, Добавление и изменение документов зарплата и кадры, Добавление и изменение депонированной зарплаты).
Добавление и изменение данных бухгалтерии является ключевой, и если ее убрать, то пользователь не сможет использовать большую часть функционала бухгалтера.Более радикальный вариант — скопировать типовую роль Добавление и изменение данных бухгалтерии прямо в конфигураторе и в ее копии вручную ограничить права на объекты, связанные с зарплатой. Затем эту модифицированную роль использовать в пользовательском профиле.
Таким образом, простое удаление или модификация ролей в большинстве случаев не приносит желаемого результата без серьезных побочных эффектов. При необходимости можно воспользоваться готовым профилем бухгалтера без доступа к зарплатным документам.
Механизм RLS позволяет гибко регулировать права пользователей для доступа к данным на уровне отдельных записей, документов или справочников. Наиболее распространенный пример его использования — это разграничение доступа пользователей по организациям. Разберем, применим ли RLS для нашей задачи.
В настройках «Профиля групп доступа» на вкладке «Ограничение доступа» мы можем добавить параметры ограничений. Например, можно ограничить доступ к документам и справочникам только для определенных организаций. Если данные о зарплате хранятся в отдельных регистрах или документах, связанных с конкретными параметрами, теоретически можно настроить RLS.
Таким образом, RLS – это мощный инструмент, но он предназначен для другого типа задач и не позволяет полностью скрыть раздел «Зарплата и кадры» или его функционал, а лишь ограничить доступ к данным внутри него.
Расширения – это современный механизм, позволяющий изменять конфигурацию программы без снятия ее с поддержки, что значительно упрощает процесс обновлений. На первый взгляд, это кажется идеальным решением. Мы могли бы создать расширение, скопировать в него нужную роль и модифицировать ее, исключив объекты ЗиК.
Автор исходного сообщения рассматривал создание в расширении альтернативной роли, которая исключала бы из себя все, что относится к ЗиК. Такой подход позволил бы избежать непосредственного изменения основной конфигурации.
Добавление и изменение данных бухгалтерии, нам придется перенести в расширение *почти всю конфигурацию* этой роли. Это означает, что для каждого объекта метаданных, к которому у бухгалтера должен быть доступ (а их тысячи), нам нужно будет явно указать права в расширении. Это колоссальный объем работы и очень громоздкое расширение.Добавление и изменение данных бухгалтерии могут появляться новые объекты метаданных или изменяться права на существующие. Наше расширение не будет автоматически знать об этих изменениях. Соответственно, новые объекты, необходимые бухгалтеру, не будут ему доступны через нашу кастомизированную роль. Нам придется постоянно, после каждого обновления, анализировать изменения в типовой роли, переносить их в расширение, а также сверять, не появились ли новые объекты ЗиК, которые нужно исключить. Это делает поддержку такого расширения крайне затратной и практически неприемлемой.Хотя расширения и являются мощным инструментом, для такой глобальной задачи, как переопределение широких типовых ролей, они создают больше проблем, чем решают.
Функциональные опции (ФО) предназначены для гибкого включения/отключения определенного функционала в программе без изменения кода. Идея заключается в том, чтобы использовать программное управление функциональными опциями для скрытия подсистемы «Зарплата и кадры» в зависимости от текущего пользователя.
Мы могли бы создать новую функциональную опцию, которая управляла бы видимостью раздела «Зарплата и кадры». Затем, при старте программы или при смене пользователя, мы могли бы с помощью процедуры УстановитьПараметрыФункциональныхОпцийИнтерфейса программно включать или отключать эту опцию для конкретных пользователей или групп доступа.
// Пример концепции, как это могло бы быть реализовано в модуле сеанса или при старте
Если РольДоступна("ОграниченныйБухгалтер") Тогда
// Предполагается, что "ЗарплатаИКадры" - это имя нашей функциональной опции
// и она привязана к видимости подсистемы
УстановитьПараметрыФункциональныхОпцийИнтерфейса("ЗарплатаИКадры", Ложь);
Иначе
УстановитьПараметрыФункциональныхОпцийИнтерфейса("ЗарплатаИКадры", Истина);
КонецЕсли;
Это позволило бы скрывать раздел без изменения прав доступа к данным, что потенциально решило бы проблему конфликтующих ролей.
Таким образом, функциональные опции могут помочь скрыть элементы интерфейса, но не решают проблему разграничения прав доступа к данным без дополнительных усилий.
Если ведение полноценного учета зарплаты и кадров выходит за рамки возможностей БП 3.0, или требуется более тонкое разграничение прав, наиболее robust-ным и рекомендуемым решением является использование отдельной специализированной программы 1С:Зарплата и управление персоналом (ЗУП).
Этот подход является наиболее правильным с точки зрения архитектуры и безопасности данных, особенно для организаций, где число сотрудников велико или требуется строгое разграничение ролей.
Если нет возможности использовать 1С:ЗУП, а вышеперечисленные типовые подходы не дают нужного результата, остается вариант точечных доработок конфигурации или создания специализированного расширения, сфокусированного на конкретных объектах.
Вместо попытки скрыть весь раздел, можно сфокусироваться на ограничении доступа к наиболее критичным объектам: документам начисления зарплаты, справочникам сотрудников, отчетам по зарплате, проводкам по 70-му счету.
Например, можно в расширении модифицировать формы отчетов (таких как «Оборотно-сальдовая ведомость по счету 70») и документов, связанных с зарплатой. В этих модифицированных формах мы можем программно, в зависимости от роли текущего пользователя, скрывать элементы управления, поля с данными или даже целые таблицы. Это можно сделать, устанавливая свойство Видимость для элементов формы.
// Пример из модуля формы отчета/документа (в расширении)
&НаКлиенте
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// ... типовой код ...
Если НЕ РольДоступна("ПолныеПрава") И НЕ РольДоступна("ГлавныйБухгалтер") Тогда
// Например, скрыть поле с ФИО сотрудника или сумму зарплаты
Элементы.ПолеСЗарплатой.Видимость = Ложь;
Элементы.КоманднаяПанельОтчетаПоЗарплате.Видимость = Ложь;
// Можно также программно установить отбор, чтобы данные не выводились
// или запретить генерацию отчета
КонецЕсли;
КонецПроцедуры;
Также можно в расширении создавать свои собственные формы для просмотра данных, где будет реализован нужный уровень ограничений.
Как мы уже выяснили, стандартными средствами RLS невозможно ограничить доступ к конкретному счету бухгалтерского учета. Однако, можно использовать вышеописанные доработки форм отчетов, чтобы не выводить данные по 70-му счету для определенных пользователей, или же модифицировать запросы отчетов, чтобы они не включали данные этого счета. Это будет доработкой, а не типовым функционалом.
Как мы видим, прямого и простого способа полностью скрыть раздел «Зарплата и кадры» в 1С:Бухгалтерии предприятия 3.0 без серьезных изменений или использования дополнительных решений в типовом функционале нет. Проблема сложна и многогранна. В качестве готового решения можно использовать обработку для запрета просмотра блока зарплаты в БП 3.0.
В качестве основных рекомендаций мы можем выделить следующее:
Таким образом, эта задача требует либо использования специализированного продукта, либо глубоких знаний платформы 1С и готовности к разработке и поддержанию кастомизированных решений.