Как ограничить отбор по подразделению в отчете "Валовая прибыль" на базе Универсального отчета в 1С?

← На главную

Довольно часто возникает задача ограничить пользователям видимость данных в типовых отчетах. Разберем ситуацию, когда в отчете "Валовая прибыль" (построенном на базе Универсального отчета, например, в 1С:Управление торговлей) необходимо запретить менеджерам видеть прибыль по чужим подразделениям, предоставив доступ только к своему. Проанализируем несколько путей решения этой задачи: от программной модификации отчета до использования типовых механизмов платформы.

Решение 1: Программная установка отбора в Построителе отчета

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

Чтобы не писать код для каждого отчета индивидуально, логично внести изменения непосредственно в модуль Универсального отчета. В процедуре формирования отчета (например, СформироватьОтчет) добавим вызов нашей экспортной процедуры:


ДобавитьОтборВПостроитель(ПостроительОтчета, "Подразделение", списокПодразделений);

Далее в общем модуле или в самом отчете реализуем процедуру, которая будет проверять наличие поля отбора и устанавливать нужное значение:


Процедура ДобавитьОтборВПостроитель(ПостроительОтчета, ИмяОтбора, список) ЭКСПОРТ
    Если ПостроительОтчета.ДоступныеПоля.Найти(ИмяОтбора) <> НЕОПРЕДЕЛЕНО Тогда
        Отбор = ПостроительОтчета.Отбор;
        нашли = ЛОЖЬ; 
        инд = Отбор.Количество() - 1;
        
        ПОКА НЕ нашли И (инд >= 0) Цикл
            эо = Отбор[инд];
            нашли = эо.ПутьКДанным = ИмяОтбора;
            инд = инд - 1;
        КонецЦикла;    
        
        Если НЕ нашли Тогда
            эо = Отбор.Добавить(ИмяОтбора);
        КонецЕсли;
        
        Если НЕ эо.Использование Тогда
            эо.ВидСравнения = ВидСравнения.ВСписке;
            эо.Использование = ИСТИНА;    
            эо.Значение = список;
        КонецЕсли;    
    КонецЕсли;    
КонецПроцедуры

Ограничения данного метода:

Важно понимать, что просто программно добавить условие в коллекцию Отбор бывает недостаточно. Опытный пользователь может зайти в расширенные настройки Универсального отчета и вручную отключить этот фильтр или изменить вид сравнения. Чтобы полностью заблокировать интерфейс, потребуется перехватывать обработчики событий табличного поля с отборами (например, ПередНачаломИзменения) и прописывать отказ, если текущая строка содержит наше подразделение. На современных релизах платформы (8.3) весь этот код следует выносить в Расширение конфигурации, чтобы не усложнять обновление типовой базы.

Решение 2: Использование RLS (Ограничение прав на уровне записей)

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

Настроим RLS только для справочника Подразделения. В запросах типовых отчетов практически всегда используется ключевое слово РАЗРЕШЕННЫЕ. Если пользователю на уровне прав запрещено читать чужие элементы справочника, платформа сама отсечет эти данные при компоновке отчета. Пользователь физически не сможет выбрать в отборе чужое подразделение, и дополнительные доработки программного кода не потребуются.

Решение 3: Перевод отчета на СКД (Систему компоновки данных)

Поскольку ПостроительОтчета является устаревшей технологией, наиболее грамотным и современным шагом будет создание внешнего отчета на базе СКД. Посмотрим на преимущества этого подхода:

Перенос запроса из Универсального отчета в схему компоновки данных занимает минимум времени.
В СКД нужный отбор (или параметр, например, список разрешенных подразделений) добавляется в настройки на закладке «Параметры» или «Отбор».
Для этого отбора снимается флаг «Включать в пользовательские настройки» и ставится запрет на редактирование.
В результате пользователь получает готовый отчет, никак не может повлиять на принудительный фильтр, а основная конфигурация остается полностью типовой.

Важное замечание по методологии

Проанализируем последствия любого скрытого отсечения данных. Если менеджер с ограниченными правами сформирует отчет по компании в целом (без группировки по подразделениям), общие итоги в подвале отчета покажут сумму только по доступным ему отделам. Это может вызвать путаницу при сверке цифр. Менеджер увидит одну "Валовую прибыль", а руководитель с полными правами в том же отчете — совершенно другую. Обязательно предупреждайте пользователей о таких математических нюансах при внедрении ограничений видимости.