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

← На главную

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

Причины расхождения данных между консолью и отчетом

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

Выделим ключевые факторы, приводящие к расхождениям:

Автоматическая модификация текста запроса построителем. Объект ПостроительОтчета анализирует состав выбранных полей, группировок и условий. Если в пакете запросов используются виртуальные таблицы, но необходимые ресурсы не выведены явно в конечную выборку, механизм построителя может отсечь их либо некорректно рассчитать итоги. В результате записи из таблиц остатков могут рассчитываться с нулевыми значениями ресурсов.
Ограничения при работе с пакетными запросами. Построитель отчета полноценно управляет отборами, полями и группировками только в последней (результирующей) секции пакета. Промежуточные временные таблицы выполняются без автоматического наложения пользовательских фильтров, если внутри них не были явно объявлены директивы расширения языка запросов.
Неправильное наложение условий на виртуальные таблицы. Если в тексте запроса не используется синтаксис расширения {ГДЕ ...} внутри параметров виртуальной таблицы остатков, построитель выносит условия в общую секцию ГДЕ. Это кардинально меняет логику: фильтрация после расчета остатков приводит к искажению сумм задолженностей и оборотов.
Специфика выгрузки результатов построителя. При попытке отладить отчет и выгрузить результат построителя в плоскую таблицу значений с помощью метода Выгрузить(), разработчик видит «задвоение» строк. В действительности строки не задваиваются — в плоскую таблицу попадают как детальные записи, так и строки итогов группировок разных уровней иерархии.

Шаг 1. Перехват и анализ реального текста запроса

Чтобы понять, что именно СУБД получает на вход, необходимо извлечь текст запроса непосредственно перед моментом его исполнения. Используем метод ПолучитьЗапрос() у объекта ПостроительОтчета.

Посмотрим на пример отладочного кода:


// Перед выполнением построителя перехватываем реальный запрос
РеальныйЗапрос = ПостроительОтчета.ПолучитьЗапрос();

// Выводим текст модифицированного запроса в окно сообщений или смотрим в отладчике
Сообщить(РеальныйЗапрос.Текст);

// Проверяем заполнение параметров
Для Каждого Параметр Из РеальныйЗапрос.Параметры Цикл
    Сообщить("Параметр: " + Параметр.Ключ + " = " + Строка(Параметр.Значение));
КонецЦикла;

// Выполнение отчета
ПостроительОтчета.Выполнить();

Скопируем полученный через РеальныйЗапрос.Текст запрос обратно в консоль запросов вместе со всеми параметрами. В большинстве случаев сразу становится видно, какие секции ИТОГИ или условия ГДЕ добавил построитель и почему итоговая сумма перестала сходиться.

Шаг 2. Корректная проброска ресурсов и полей

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

Чтобы исключить эту проблему, соблюдаем следующие правила:

Явно прокидываем ресурсы в выборку. Все числовые ресурсы виртуальных таблиц, участвующие в логике расчетов, должны присутствовать в списке полей выборки последнего запроса пакета, иначе построитель может рассчитать группировки без их учета.
Управляем составом полей через конструкции расширения. Используем фигурные скобки для явного указания доступных полей, условий и группировок:


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

Обратите внимание на размещение фигурных скобок {ГДЕ ...} непосредственно внутри параметров виртуальной таблицы. Это заставляет построитель накладывать пользовательские отборы до вычисления остатков, что обеспечивает правильный расчет итогов.

Шаг 3. Упрощение структуры запроса и альтернативные решения

Если запрос содержит 4–5 временных таблиц со сложными левыми соединениями регистра остатков и регистра оборотов, построитель отчета часто дает сбой при автоматическом формировании итогов по группировкам. В таких ситуациях помогают следующие действия:

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