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

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

Механизм «декларативного» запроса в СКД

Рассмотрим ситуацию на примере запроса, представленного автором темы. В конфигураторе мы видим следующее:

ВЫБРАТЬ РАЗРЕШЕННЫЕ
    &ДатаНачала КАК ДатаНачала,
    &ДатаОкончания КАК ДатаОкончания,
    Сотрудники.Ссылка КАК Сотрудник
ПОМЕСТИТЬ ВТСотрудники
ИЗ
    Справочник.Сотрудники КАК Сотрудники
{ГДЕ
    Сотрудники.Ссылка.* КАК Сотрудник}

На первый взгляд кажется, что запрос просто выбирает список сотрудников во временную таблицу. Если запустить его в консоли без параметров, результат действительно может быть пустым. Однако в типовых решениях этот текст является лишь «каркасом» или объявлением доступных полей. Основная магия происходит программно.

Проанализируем причины, по которым запрос ведет себя именно так:

1. Использование расширений СКД: Конструкции в фигурных скобках {ГДЕ ...} позволяют системе динамически добавлять отборы, которые пользователь устанавливает в настройках отчета. Если в коде программы не инициализированы параметры компоновки, запрос может не выдать ожидаемых данных.
2. Программная подмена текста: В большинстве отчетов ЗУП 3.1 используется событие ПриКомпоновкеРезультата. В этом модуле система вызывает универсальные механизмы (например, подсистему «Варианты отчетов» из БСП), которые полностью заменяют текст запроса на другой, программно сгенерированный.
3. Динамические соединения: Система анализирует, какие поля пользователь выбрал для отображения. Если нужны только ФИО сотрудников, запрос будет коротким. Если же добавлены начисления, налоги и данные о стаже, программный код «долепит» к исходному тексту десятки левых соединений и временных таблиц.

Как найти реальный текст запроса

Когда мы сталкиваемся с запросом в 4755 строк, который генерируется системой, нам необходимо увидеть его «глазами сервера». Выясним, какими способами это можно сделать.

Самый простой и эффективный метод — использование отладчика в процедуре ПриКомпоновкеРезультата. Нам нужно найти точку, где МакетКомпоновки уже сформирован. Проанализируем объект МакетКомпоновки.НаборыДанных. В свойстве Запрос у соответствующего набора данных будет лежать итоговый текст, который уйдет на SQL-сервер.

Также крайне полезно использовать методы платформы для работы с временными таблицами. Рассмотрим метод ВыполнитьПакетСПромежуточнымиДанными(). Это мощный инструмент, который позволяет получить содержимое каждой ВТ в огромном пакете:

Запрос = Новый Запрос(ТекстЭтогоОгромногоЗапроса);
// Установка всех параметров
МассивРезультатов = Запрос.ВыполнитьПакетСПромежуточнымиДанными();
// Теперь в массиве лежат результаты всех временных таблиц, их можно просмотреть в отладке

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

Стратегия модификации «монструозных» запросов

Допустим, нам нужно добавить одно поле в отчет, где итоговый запрос занимает тысячи строк. Лезть в середину программно генерируемого кода — это «совать голову в петлю», как выразился автор темы. Посмотрим, какие есть безопасные пути.

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

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

Способ 2: Использование программного интерфейса БСП.
В ЗУП 3.1 многие отчеты строятся на базе функций модуля ЗарплатаКадрыОтчеты. Вместо правки запроса напрямую, зачастую достаточно добавить описание нового поля в процедуру НастроитьВариантОтчета или аналогичную. Система сама поймет, что нужно добавить поле в выборку, если оно описано в метаданных схемы.

Полезные советы по отладке

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

• Проверяйте временные таблицы: В платформе 8.3 появилась возможность просматривать содержимое ВТ через менеджер временных таблиц в отладчике. Используйте метод МенеджерВременныхТаблиц.Таблицы.Найти("ИмяВТ").ПолучитьДанные().Выгрузить().
• Внимание на параметры: Часто запрос «не работает» в консоли просто потому, что в нем используются специфические параметры-границы или значения пустых ссылок, которые СКД заполняет автоматически.
• Не бойтесь объема: Большая часть из 4000 строк кода в ЗУП — это типизированные блоки для работы с правами доступа (RLS) и объединения данных из разных периодов. Основная логика обычно сосредоточена в первых нескольких временных таблицах и финальной сборке.

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