Почему отчет на СКД выдает ошибку «Поле не найдено», если этот же запрос успешно выполняется в консоли?

← На главную

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

Различие в проверке прав доступа: «Чтение» против «Просмотра»

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

Рассмотрим механизм работы компоновщика: перед тем как отправить запрос в СУБД, СКД анализирует схему и строит макет компоновки. На этом этапе система проверяет наличие права «Просмотр». Если у пользователя есть право на чтение данных из базы, но в роли не установлена галочка «Просмотр» для конкретного поля или объекта, СКД просто «вырезает» это поле из итогового запроса. В результате мы получаем ошибку о том, что поле не найдено, так как компоновщик не смог включить его в макет.

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

Проблема длинных цепочек обращений «через точку»

Выясним причину, по которой обращения типа Регистратор.ДокументОснование.Менеджер.Команда считаются плохим тоном и часто приводят к ошибкам в СКД. Каждая точка в запросе — это неявное соединение (LEFT JOIN) с другой таблицей. Рассмотрим, что происходит, когда в этой цепочке встречается поле составного типа, например ДокументОснование.

Для СКД такое обращение превращается в сложную конструкцию:

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

Использование оператора ВЫРАЗИТЬ для типизации данных

Посмотрим на пример, как можно исправить ситуацию с составными типами. Использование оператора ВЫРАЗИТЬ (EXPRESS) является обязательным стандартом при работе с СКД и RLS. Это позволяет явно указать системе, к какой таблице мы обращаемся, исключая лишние проверки прав на все типы составного поля.

Проанализируем разницу в коде. Вместо опасного обращения:


ГДЕ
    ПродажиОбороты.Регистратор.ДокументОснование.Менеджер.Команда = &Значение

Рассмотрим правильный подход с приведением к конкретному типу:


ВЫБРАТЬ
    ВЫРАЗИТЬ(ПродажиОбороты.Регистратор.ДокументОснование КАК Документ.ЗаказПокупателя).Менеджер КАК Менеджер
ИЗ
    РегистрНакопления.Продажи.Обороты КАК ПродажиОбороты

В данном случае СКД будет точно знать, что нужно соединяться только с таблицей ЗаказПокупателя, и не будет пытаться анализировать права на другие типы документов.

Механизм генерации макета и кэширование

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

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

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

Практические рекомендации по решению проблемы

Подведем итог и составим пошаговый план действий для устранения подобных ошибок:

Проверка прав «Просмотр»: Убедитесь, что у пользователя есть права на просмотр всех объектов и их реквизитов, задействованных в запросе.
Отказ от глубокой вложенности: Постарайтесь не использовать более двух точек в обращениях. Если данные лежат далеко, лучше вынести их в Временную таблицу.
Типизация через ВЫРАЗИТЬ: Всегда типизируйте обращения к реквизитам составных типов.
Анализ RLS: Проверьте условия RLS. Если условие ограничения само содержит обращение через точку к полям, на которые нет прав, это вызовет ошибку именно в СКД.
Тестирование через консоль СКД: Используйте специализированные консоли (например, «Консоль системы компоновки данных»), которые показывают итоговый запрос после генерации макета, а не просто исходный текст.

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

Соблюдение этих правил и понимание внутренней механики СКД позволит вам создавать стабильные отчеты, которые будут корректно работать у пользователей с любыми наборами прав.