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