Как правильно настроить вывод данных в таблицу СКД при использовании левого соединения и избежать дублирования итогов?

← На главную

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

Анализ проблемы: почему «раздуваются» итоги при левом соединении

Рассмотрим стандартную ситуацию: у нас есть левая таблица (например, ОстаткиНоменклатуры) и правая таблица (например, ПродажиПоАвторам). Мы хотим вывести остатки в строках, а продажи — в колонках по авторам. Если мы используем обычное ЛЕВОЕ СОЕДИНЕНИЕ в одном запросе, и на одну позицию номенклатуры приходится несколько авторов из правой таблицы, то количество строк в результирующей выборке увеличивается пропорционально количеству записей в правой таблице.

Проанализируем последствия такого подхода для СКД:

Дублирование ресурсов: Если в левой таблице был остаток 10 штук, а в правой нашлось 3 записи по разным авторам, СКД получит 3 строки, в каждой из которых будет остаток 10. При расчете общего итога по полю КоличествоОстаток система выдаст 30 вместо 10.
Пустые пересечения в таблице: Кросс-таблица в СКД работает по принципу координат. Данные выводятся в ячейку только в том случае, если в итоговом наборе записей существует комбинация значений «ГруппировкаСтрок + ГруппировкаКолонок». Если связь настроена некорректно, ресурс может «прилипнуть» только к итогам, не попадая в детализацию пересечений.

Решение №1: Использование объединения наборов данных (Dataset Union)

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

Рассмотрим пример структуры такого запроса:


ВЫБРАТЬ
    Остатки.Номенклатура КАК Номенклатура,
    Остатки.Склад КАК Склад,
    NULL КАК Автор,
    Остатки.КоличествоОстаток КАК Остаток,
    0 КАК СуммаПродаж
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки КАК Остатки

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    Продажи.Номенклатура,
    Продажи.Склад,
    Продажи.Автор,
    0,
    Продажи.СуммаВыручки
ИЗ
    РегистрНакопления.ВыручкаИПродажи.Обороты КАК Продажи

Преимущества этого метода:

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

Решение №2: Связи наборов данных (Dataset Links)

Если специфика задачи требует наличия двух отдельных наборов данных, воспользуемся механизмом Связи наборов данных на соответствующей вкладке в СКД. Это принципиально отличается от SQL-Join. Когда мы связываем Набор1 (ведущий) и Набор2 (ведомый), СКД выполняет отдельный запрос к ведомому набору для каждой строки ведущего набора, передавая параметры связи.

Выясним правила настройки таких связей:

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

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

Как обеспечить вывод ресурсов на пересечении группировок

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

Проверим следующие настройки:

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

Виртуальная группировка по пустой строке

Рассмотрим продвинутый прием для кастомизации макета, упомянутый опытными разработчиками. Иногда требуется вывести ресурсы, которые логически не относятся к вертикальной группировке (автору), в ту же область шапки. Для этого в структуру отчета добавляется группировка с детальным выражением "" (пустая строка).

Это позволяет:

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

Резюмируем: Для корректного вывода отчета в таблицу при необходимости связи «один ко многим» всегда отдаем предпочтение Объединению (Union) или Связям наборов данных внутри СКД. Избегаем прямого LEFT JOIN в тексте запроса, если планируется расчет итоговых сумм по левой таблице.