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

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

Разбор проблемы: логика оптимизации Построителя

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

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

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

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

Рассмотрим пример того, как это реализовать в тексте запроса:

Допустим, у нас есть условие, исключающее перемещения между выбранными складами:

ВЫБРАТЬ
    Номенклатура,
    Регистратор,
    КоличествоОборот
ИЗ
    РегистрНакопления.ПартииТоваровНаСкладах.Обороты(&Начало, &Конец) КАК ИсточникДанных
ГДЕ
    НЕ (ИсточникДанных.Регистратор ССЫЛКА Документ.ПеремещениеТоваров
    И ИсточникДанных.Регистратор.СкладПолучатель В (&СписокСкладов)
    И ИсточникДанных.Регистратор.СкладОтправитель В (&СписокСкладов))
ИТОГИ ПО
    ОБЩИЕ,
    Номенклатура,
    Регистратор

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

Альтернативные подходы к решению

Хотя метод с «обязательными итогами» работает надежно, стоит учитывать и другие подходы, принятые в профессиональной разработке:

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

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