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

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

Понимаем корень проблемы: Консоль vs СКД

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

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

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

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

Шаг 2. Настройка ролей полей (Измерения и Периоды)

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

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

Шаг 3. Флаг «Использовать всегда»

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

Если мы установим этот флаг для реквизита, СКД будет включать его в итоговый запрос и группировку СГРУППИРОВАТЬ ПО, даже если пользователь не выбрал это поле в настройках. Это гарантирует, что суммы не «схлопнутся» из-за отсутствия поля в выборке.

Шаг 4. Управление автозаполнением

Проанализируем работу механизма Автозаполнения. В сложных запросах с использованием ОБЪЕДИНИТЬ ВСЕ и временных таблиц (как в представленном ниже примере), автозаполнение часто ошибается.

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

Шаг 5. Работа с агрегатными функциями и ресурсами

Посмотрим на фрагмент сложного запроса, который может вызывать проблемы при агрегации в СКД:

ВЫБРАТЬ
    ПрочиеРасходыОбороты.СтатьяРасходов КАК СтатьяРасходов,
    ПрочиеРасходыОбороты.АналитикаРасходов КАК АналитикаРасходов,
    ПрочиеРасходыОбороты.Регистратор КАК Регистратор,
    СУММА(ВЫБОР
            КОГДА ПрочиеРасходыОбороты.СуммаОборот = 0
                ТОГДА ПрочиеРасходыОбороты.СуммаУпрОборот
            ИНАЧЕ ПрочиеРасходыОбороты.СуммаОборот
        КОНЕЦ - 1) КАК СуммаОборот,
    ПрочиеРасходыОбороты.Подразделение КАК Подразделение,
    НАЧАЛОПЕРИОДА(ПрочиеРасходыОбороты.Период, МЕСЯЦ) КАК Период
ПОМЕСТИТЬ ВТ_ПрочиеРасходы_Авансовый_ОС
ИЗ
    РегистрНакопления.ПрочиеРасходы.Обороты(&НачалоПериода, &КонецПериода, Регистратор, ) КАК ПрочиеРасходыОбороты

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

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

Шаг 6. Проблема NULL в объединениях

В запросах с ОБЪЕДИНИТЬ ВСЕ часто возникают ситуации, когда в одной части объединения поле заполнено, а в другой стоит NULL. СКД при группировке может посчитать NULL и пустую ссылку разными значениями или, наоборот, схлопнуть их непредсказуемым образом.

Выясним причину через типизацию. Вместо использования NULL в пустых колонках объединения, лучше использовать пустые ссылки конкретного типа:

ВЫБРАТЬ
    ВТ_АктивыПассивы.Подразделение,
    ЗНАЧЕНИЕ(Справочник.Склады.ПустаяСсылка) КАК Склад,
    ВТ_АктивыПассивы.Статья КАК Аналитика
...

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

Резюме действий для исправления отчета

Подведем итог нашему исследованию. Если вы столкнулись с «неправильными» суммами в СКД:

1. Проверьте роли: все поля, которые должны разделять данные, должны иметь роль «Измерение».
2. Настройте периоды: убедитесь, что регистратор и дата имеют роли периода с правильной иерархией.
3. Используйте «Обязательное»: включите этот флаг для ключевых полей группировки.
4. Проверьте ресурсы: убедитесь, что расчет итогов идет по нужным полям и не происходит лишнего суммирования уже агрегированных данных.
5. Исключите NULL: замените их в UNION на пустые ссылки соответствующих типов.

Соблюдение этих правил позволит вам создавать сложные аналитические отчеты, данные в которых будут на 100% совпадать с ожиданиями и результатами прямых запросов.