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

← На главную

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

Анализ исходной проблемы

Рассмотрим ситуацию: в типовую или кастомизированную базу (например, на базе БИТ:Финанс) встроен отчет. Если формировать его со стандартными настройками, всё работает корректно. Однако, как только пользователь через настройки отчета добавляет в строки доп. реквизит (например, поле Клиент у справочника Проекты), перестает работать расшифровка или сам отчет. Система выдает ошибку, указывая на отсутствие какого-либо ресурса (например, СуммаУпрЭталон), хотя это поле явно присутствует в схеме.

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

Сравнение «рабочего» и «проблемного» запросов

Проанализируем структуру запросов. В обоих случаях используется механизм получения оборотов из регистра бит_ОборотыПоБюджетам с расчетом курсовых разниц и группировкой по статьям.

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


// Фрагмент финального пакета старого запроса
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    СтатьиБюджета.СтатьяБюджета КАК СтатьяБюджета,
    ВременнаяТаблица.Проект КАК Проект,
    СУММА(ЕСТЬNULL(ВременнаяТаблица.СуммаУпрОборотЭталон, 0)) КАК СуммаУпрОборотЭталон
ИЗ
    СтатьиБюджета КАК СтатьиБюджета
ЛЕВОЕ СОЕДИНЕНИЕ ВременнаяТаблица КАК ВременнаяТаблица
    ПО СтатьиБюджета.СтатьяБюджета = ВременнаяТаблица.СтатьяБюджета
СГРУППИРОВАТЬ ПО
    СтатьиБюджета.СтатьяБюджета,
    ВременнаяТаблица.Проект

Вариант 2 (Новый, с ошибкой): Здесь разработчик добавил промежуточное звено — ИтоговаяТаблица. Сначала данные помещаются в неё, а затем в последнем пакете просто выбираются «как есть».


// Промежуточный пакет, сохраняющий данные в ИтоговаяТаблица
...
ПОМЕСТИТЬ ИтоговаяТаблица
ИЗ
    СтатьиБюджета КАК СтатьиБюджета
ЛЕВОЕ СОЕДИНЕНИЕ ВременнаяТаблица КАК ВременнаяТаблица ...
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ИтоговаяТаблица.СтатьяБюджета КАК СтатьяБюджета,
    ИтоговаяТаблица.Проект КАК Проект,
    ИтоговаяТаблица.СуммаУпрОборотЭталон КАК СуммаУпрОборотЭталон
ИЗ
    ИтоговаяТаблица КАК ИтоговаяТаблица

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

Причина 1: Потеря связи с объектом метаданных

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

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

Причина 2: Конфликт механизмов «Автозаполнения» и «Характеристик»

Проанализируем вкладку «Наборы данных» в конструкторе СКД. По умолчанию для запросов включен флаг Автозаполнение. Система сама расставляет роли (измерения, ресурсы) и пытается определить связи.

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

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

Как решить проблему: пошаговое руководство

Рассмотрим методы исправления данной ситуации, начиная от самого эффективного.

Способ 1: Упрощение структуры запроса (Рекомендуемый)

Как показала практика, самым надежным решением является отказ от лишних промежуточных временных таблиц. Если вам нужно выполнить группировку или расчет, старайтесь делать это в последнем пакете запроса, который возвращает данные в СКД. Избегайте конструкции ВЫБРАТЬ * ИЗ ВременнаяТаблица в финальном пакете.

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

Способ 2: Явное указание типов (Приведение типов)

Если временную таблицу исключить невозможно, попробуйте принудительно указать системе тип поля в финальном запросе. Для этого используем функцию ВЫРАЗИТЬ.


ВЫБРАТЬ
    ВЫРАЗИТЬ(ИтоговаяТаблица.Проект КАК Справочник.Проекты) КАК Проект,
    ИтоговаяТаблица.СуммаУпрОборотЭталон КАК СуммаУпрОборотЭталон
ИЗ
    ИтоговаяТаблица КАК ИтоговаяТаблица

Это подскажет механизму характеристик СКД, к какому именно объекту метаданных относятся дополнительные реквизиты, которые пытается вывести пользователь.

Способ 3: Настройка ролей полей в СКД

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

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

Способ 4: Проверка вкладки «Характеристики»

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

Если вы изменили запрос и переименовали поля (например, было Проект, стало ПроектСсылка), настройки характеристик могут перестать «узнавать» поле. Убедитесь, что имена полей в запросе соответствуют именам, указанным в настройках характеристик.

Резюме

Ошибка «Поле не найдено» при использовании доп. реквизитов — это сигнал о том, что СКД запуталась в структуре ваших временных таблиц и потеряла контекст метаданных. Главное правило: чем меньше уровней вложенности временных таблиц в запросе, тем стабильнее работает механизм расшифровки и динамического подключения характеристик БСП. Рассмотрим это как стандарт разработки: финальный пакет запроса всегда должен содержать прямые ссылки на объекты метаданных с их явной группировкой.