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