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

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

Понимание природы проблемы

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

Попытки исправить это с помощью функции ВычислитьВыражение для скрытия строк через условное оформление являются «костылями», которые не решают проблему дублирования данных на уровне расчетов ресурсов. Если отчет должен считать суммы, скрытые строки все равно будут учитываться, что искажает отчетность.

Метод 1: Подготовка данных на уровне запроса

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

Рассмотрим подход, при котором мы разделяем роли элементов:

1. Создаем два набора данных или используем Объединение в одном запросе.
2. Для записей, являющихся группами, мы не выводим детальные значения (показатели в них будут пустыми или нулевыми).
3. Для детальных записей, которые находятся на нижнем уровне, мы выводим только показатели.
4. Если одна и та же строка должна выступать и родителем, и элементом, мы дублируем эту запись в наборе данных с разными признаками, чтобы СКД воспринимала их как разные сущности.

Этот метод требует передачи в СКД всех комбинаций «элемент + период», чтобы при группировке по периоду и иерархии не возникало «пустых» иерархических веток.

Метод 2: Использование уникальной нумерации (УИД)

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

Пример настройки связи:

// В настройках наборов данных указываем:
// Источник: НаборДанных1
// Приемник: НаборДанных1
// Выражение источника: Ид
// Выражение приемника: ИдРодитель

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

Метод 3: Программный препроцессинг (Дерево значений)

В случаях, когда отчет требует сложной аналитики по периодам с нетривиальными итоговыми расчетами, оптимальным решением является подготовка данных вне СКД:

1. Формируем дерево значений в модуле объекта или менеджера с помощью запроса к базе данных.
2. Рассчитываем иерархические итоги по периодам программно.
3. Выгружаем полученное дерево в таблицу значений.
4. Передаем эту таблицу в СКД как «Набор данных - Объект».

В этом случае СКД выступает только как инструмент визуализации уже готовой структуры. Это исключает появление «лишних» строк, так как мы полностью управляем составом записей и их иерархическими связями.

Рекомендации по настройке

Для достижения «чистого» результата придерживайтесь следующих правил:

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

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