Почему при формировании отчета на СКД возникает ошибка «Поле не найдено» и как ее исправить?

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

Текст ошибки обычно выглядит следующим образом:

Ошибка создания набора данных "НаборДанных1"
[ОшибкаНастроекКомпоновкиДанных]
по причине:
Ошибка при исполнении запроса набора данных
по причине:
{(59, 38)}: Поле не найдено "ЗаказПокупателяЗапасы.Номенклатура.КатегорияНоменклатуры"
(ЗаказПокупателяЗапасы.Номенклатура.<<?>>КатегорияНоменклатуры = &ДвериМеж

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

Главная причина: разница между правами «Чтение» и «Просмотр»

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

Разберем специфику прав в контексте отчетов СКД:

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

Решение: Убедимся, что пользователю (или роли, которая ему назначена) выдано не только право «Чтение», но и право «Просмотр» на используемые в отборе объекты и реквизиты. В большинстве случаев добавление галочки «Просмотр» в роли полностью решает проблему.

Другие возможные причины ошибки «Поле не найдено» в СКД

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

1. Сложные обращения через точку. При использовании конструкции вида Номенклатура.КатегорияНоменклатуры мы должны удостовериться, что даны права на просмотр объекта ссылочного типа, на который ссылается реквизит «КатегорияНоменклатуры» (например, это может быть отдельный справочник).
2. Ограничения на уровне записей (RLS). Если в базе включено ограничение прав на уровне записей, у пользователя может физически не быть доступа к конкретной группе справочника. При программной установке жесткого параметра на эту группу СКД не сможет найти ее в доступной пользователю выборке.
3. Отборы в макете. Поле может автоматически подтягиваться механизмом автозаполнения СКД в список доступных отборов. Если пользователь не имеет прав на это поле, но оно сохранилось в его пользовательских настройках (или в стандартном варианте отчета), это также приведет к падению отчета при генерации.

Альтернативные варианты решения без выдачи права «Просмотр»

Иногда мы не можем дать пользователю право «Просмотр» по соображениям безопасности (например, он не должен иметь возможность открывать карточки заказов покупателей напрямую в интерфейсе), но при этом он должен видеть агрегированные данные в отчете. Рассмотрим рабочие методы обхода:

1. Использование привилегированного режима. Мы можем формировать отчет полностью программно. Для этого в модуле объекта отчета, в процедуре ПриКомпоновкеРезультата, мы переводим выполнение кода в привилегированный режим, отключаем стандартную генерацию и выводим результат кодом:
   Скопировать код

   
   Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
       СтандартнаяОбработка = Ложь;
       УстановитьПривилегированныйРежим(Истина);
       // Далее пишем стандартный программный код вывода отчета СКД
   КонецПроцедуры
   

2. Использование возможностей БСП (для внешних отчетов). При использовании Библиотеки стандартных подсистем внешний или дополнительный отчет можно подключить в справочник дополнительных отчетов и обработок, указав нужный режим запуска (например, сняв галочку «Безопасный режим» в настройках регистрации). Это позволит системе выполнить запрос без наделения пользователя лишними ролями.
3. Ключевое слово РАЗРЕШЕННЫЕ. Если ошибка связана не с отсутствием прав на объекты метаданных, а с нехваткой прав на часть записей из-за настроенного RLS, добавим конструкцию ВЫБРАТЬ РАЗРЕШЕННЫЕ в начале текста запроса. Это исключит падение отчета, просто отбросив недоступные строки.
4. Управление автозаполнением. В конструкторе запроса СКД мы можем снять флаг «Автозаполнение». Затем на вкладке «Наборы данных» мы вручную добавим только те поля, которые действительно необходимы пользователю для отборов и вывода, и на которые у него точно есть права.

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