В практике администрирования 1С часто возникает задача разграничения зон ответственности бухгалтеров. Например, когда необходимо настроить систему так, чтобы бухгалтер по заработной плате видел только 70 счет, материально ответственное лицо — 10 счет, а специалист по взаиморасчетам — 60 и 62 счета. Однако стандартная оборотно-сальдовая ведомость (ОСВ) в конфигурациях типа 1С:УПП или 1С:Бухгалтерия предоставляет доступ ко всему плану счетов, если у пользователя есть права на чтение регистра бухгалтерии. При массовом администрировании баз такие задачи упрощаются за счет автоматизации архивирования и тестирования.
В рамках данной статьи мы разберем, почему стандартные механизмы ограничения прав могут быть опасны, и рассмотрим пошагово эффективные способы решения этой задачи, основываясь на практическом опыте разработчиков.
Первое решение, которое приходит в голову программисту — настроить RLS (Record Level Security) на объект ПланСчетовСсылка.Хозрасчетный или на сам регистр бухгалтерии. Рассмотрим подробнее, к каким критическим последствиям это может привести:
RLS на регистры бухгалтерии, содержащие миллионы записей, значительно замедляет формирование отчетов и работу системы в целом.Проанализируем ситуацию: если мы не можем ограничить данные на уровне базы (в регистре), значит, нам нужно ограничить их на уровне представления (в отчете).
Это наиболее гибкий и безопасный метод. Мы создаем копию стандартной ОСВ в виде внешнего отчета и внедряем в нее проверку прав. Разберем алгоритм действий:
Во-первых, создадим новые роли в конфигураторе, например, ДоступКСчету10, ДоступКСчету60. Эти роли не будут иметь специальных прав в метаданных, они будут служить только "маркерами" для нашего кода.
Во-вторых, в модуле внешнего отчета, в процедуре формирования (например, ПриКомпоновкеРезультата), пропишем проверку выбранного счета. Посмотрим на пример кода:
Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
// Получаем выбранный пользователем счет из настроек компоновщика
ПараметрСчет = КомпоновщикНастроек.Настройки.ПараметрыДанных.Элементы.Найти("Счет");
Если ПараметрСчет <> Неопределено И ЗначениеЗаполнено(ПараметрСчет.Значение) Тогда
ТекущийСчет = ПараметрСчет.Значение;
// Проверяем соответствие счета и роли пользователя
Если ТекущийСчет.Код = "10" И Не РольДоступна("ДоступКСчету10") Тогда
Отказ = Истина;
ИначеЕсли ТекущийСчет.Код = "60" И Не РольДоступна("ДоступКСчету60") Тогда
Отказ = Истина;
КонецЕсли;
Если Отказ Тогда
Сообщить("У вас нет прав для формирования отчета по счету " + ТекущийСчет);
СтандартнаяОбработка = Ложь;
Возврат;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
В-третьих, необходимо ограничить доступ к стандартным отчетам. Для этого в общих ролях пользователя убираем право на запуск стандартной ОборотноСальдоваяВедомостьПоСчету.
Если задача стоит жестко — пользователь вообще не должен иметь прав на РегистрБухгалтерии.Хозрасчетный, чтобы не подсмотреть данные через консоль запросов или другие отчеты, — используем привилегированный режим.
Выясним причину эффективности этого метода: отчет будет формироваться на сервере в модуле, который помечен флагом "Привилегированный". В этом случае система игнорирует права текущего пользователя и читает данные напрямую. Программа сама отфильтрует только те счета, которые разрешены пользователю, и выдаст готовый результат. Для организации такого механизма без доработки конфигурации можно использовать расширение для выполнения отчетов в привилегированном режиме.
Рассмотрим шаги реализации:
ГДЕ Счет В (&СписокРазрешенныхСчетов).Зачастую бухгалтеру не нужна именно ОСВ. Рассмотрим альтернативу: вместо бухгалтерского регистра можно использовать данные регистров накопления управленческого учета. В 1С:УПП данные о ТМЦ или взаиморасчетах дублируются в соответствующих регистрах (например, Закупки, ВзаиморасчетыСКонтрагентами).
Преимущества такого подхода:
RLS по организациям, складам или контрагентам без риска остановить проведение документов.Как отмечалось на форуме, пользователи могут попытаться открыть сторонний отчет через Файл -> Открыть и увидеть все данные. Чтобы исключить эту возможность, выполним следующие настройки:
Ограничение интерактивного открытия: В ролях пользователей (кроме администраторов) должно быть снято право Интерактивное открытие внешних отчетов и Интерактивное открытие внешних обработок. Это критически важный момент для безопасности данных. Для быстрой проверки наличия таких привилегий у сотрудников подойдёт обработка для аудита пользователей и критических прав доступа.
Использование справочника "Внешние обработки": Все необходимые пользователям дополнительные отчеты загружаем в справочник "Внешние обработки" (в УПП это "Дополнительные внешние отчеты и обработки"). Там мы можем гибко настроить права доступа: какой пользователь какой конкретно отчет может запускать.
Подведем итог: идеального "коробочного" решения для ограничения доступа к счетам ОСВ не существует из-за архитектурных особенностей двойной записи. Однако, комбинируя методы, мы можем добиться требуемого результата:
.erf и .epf через права платформы.Такой комплексный подход обеспечит сохранность конфиденциальной информации и стабильную работу системы без ошибок доступа при проведении документов.