Почему отчет на СКД показывает разные данные под разными пользователями и как его проанализировать?

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

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

Причина поведения платформы: RLS и неявные соединения

Проанализируем механику работы ограничений на уровне записей (RLS) в отчетах СКД:

1. Модификатор ВЫБРАТЬ РАЗРЕШЕННЫЕ: По умолчанию процессор компоновки данных платформы 1С принудительно накладывает ограничения прав текущего пользователя и использует режим выборки только разрешенных записей.
2. Подмена строк на NULL: В типовых отчетах данные о графиках и состояниях часто соединяются с помощью конструкции ЛЕВОЕ СОЕДИНЕНИЕ к срезам регистров сведений (например, к регистру СостоянияСотрудников). Если у пользователя нет прав на чтение конкретной записи в присоединяемой таблице, платформа не генерирует исключение о нарушении прав, а возвращает NULL для всех полей этой строки.
3. Обработка отсутствующих значений: В коде запроса или выражениях полей СКД часто используется конструкция ЕСТЬNULL(..., "Я"). В результате недоступный из-за RLS больничный лист превращается в пустое значение, которое алгоритм расчета табеля трактует как обычный рабочий день (явку).

Способ 1. Программное извлечение итогового запроса и параметров из СКД

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

Рассмотрим по шагам программный код, который извлекает текст запроса и выгружает сформированные параметры в структуру:

// Получаем схему и настройки компоновки данных
СхемаКомпоновкиДанных = ОтчетОбъект.СхемаКомпоновкиДанных;
Настройки = ОтчетОбъект.КомпоновщикНастроек.ПолучитьНастройки();

// Выполняем компоновку макета
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, Настройки,,, Тип("ГенераторМакетаКомпоновкиДанных"));

// 1. Извлекаем итоговый текст запроса с учетом всех группировок и условий
ТекстЗапросаДляКонсоли = "";
Для Каждого НаборДанных Из МакетКомпоновки.НаборыДанных Цикл
    Если ТипЗнч(НаборДанных) = Тип("НаборДанныхЗапросМакетаКомпоновкиДанных") Тогда
        ТекстЗапросаДляКонсоли = ТекстЗапросаДляКонсоли + Символы.ПС + НаборДанных.Запрос;
    КонецЕсли;
КонецЦикла;

// 2. Извлекаем все фактические параметры
СтруктураПараметров = Новый Структура;
Для Каждого ПараметрМакета Из МакетКомпоновки.ЗначенияПараметров Цикл
    СтруктураПараметров.Вставить(ПараметрМакета.Имя, ПараметрМакета.Значение);
КонецЦикла;

Полученные данные можно сразу передать в консоль запросов, не тратя время на заполнение параметров вручную.

Способ 2. Диагностика через технологический журнал (ТЖ)

Если нет возможности запустить отладчик в рабочей базе, зафиксируем реальный запрос к СУБД с наложенными условиями RLS через технологический журнал. Для этого достаточно настроить сбор события SDBL с фильтром по пользователю или имени метаданных отчета. В лог запишется текст запроса со всеми подставленными литералами и условиями ограничений прав, что позволит увидеть, на какой именно таблице отсекаются строки.

Способ 3. Пошаговое тестирование прав на таблицы пакета

Если текст запроса уже открыт в консоли под проблемным пользователем, выясним, какая именно таблица дает сбой:

1. Уберем ключевое слово РАЗРЕШЕННЫЕ из первой секции пакетного запроса.
2. Если запрос завершился системной ошибкой «Нарушение прав доступа», значит, ограничение сработало на объектах первой временной таблицы.
3. Если запрос выполнился, поочередно убираем РАЗРЕШЕННЫЕ сверху вниз по пакетам, пока платформа не выдаст ошибку прав. Та таблица, на которой произойдет сбой, и является источником скрытого ограничения.

Решение проблемы: дубли физических лиц и настройка групп доступа

Частой причиной скрытого срабатывания RLS в ЗУП 3.1 является человеческий фактор при ведении справочников. Рассмотрим типовой сценарий:

1. В системе включено ограничение прав по группам физических лиц (правило #ПоЗначениям("РегистрСведений.СостоянияСотрудников", "Чтение", "", "ГруппыФизическихЛиц", "Сотрудник.ФизическоеЛицо")).
2. В информационной базе случайно создали дубль карточки в справочнике ФизическиеЛица.
3. Кадровый документ или состояние привязались к одному элементу (входящему в закрытую группу доступа), а в карточке сотрудника остался другой элемент, либо наоборот.
4. В результате кадровик с ограниченными правами видит сотрудника, но платформа блокирует чтение записей из регистра СостоянияСотрудников, подставляя NULL.

Для исправления ситуации выполним следующие действия:

1. Проверим информационную базу на наличие дублирующихся записей с помощью типового сервиса объединения дублей физических лиц.
2. Убедимся, что регламентные задания по обновлению ключей доступа выполнили актуализацию данных в регистрах КлючиДоступаКОбъектам и КлючиДоступаКРегистрам.
3. При необходимости выполним принудительное обновление прав доступа через панель администрирования.

Альтернативный вариант: привилегированный режим формирования отчета

Если бизнес-логика предприятия требует, чтобы пользователь видел унифицированную форму табеля целиком (включая факт отсутствия), но не имел прямого доступа к карточкам закрытых физических лиц, формирование отчета переводят в привилегированный режим.

Для этого в модуле объекта отчета при компоновке данных вызывают инструкцию:

УстановитьПривилегированныйРежим(Истина);

В этом случае компоновщик данных игнорирует ограничения RLS по группам физических лиц исключительно в момент генерации макета и вывода результата, обеспечивая корректное заполнение табельных обозначений.