При разработке отчетов на системе компоновки данных (СКД) часто возникает ситуация, когда в одном варианте отчета выводятся данные документов вместе с их табличными частями (например, товарами), а для другого варианта требуется более компактный вид — только список документов без детализации по строкам. Однако после простого отключения колонок табличной части в выбранных полях пользователи сталкиваются с тем, что строки документов начинают дублироваться столько раз, сколько строк было в исходной табличной части. Выясним причину такого поведения платформы и подробно разберем все способы решения этой задачи.
Проанализируем механизм работы процессора компоновки данных. Если в тексте запроса набора данных выполняется выборка из табличной части или соединение шапки с подчиненными строками, СУБД возвращает плоскую таблицу. В этой таблице реквизиты шапки документа повторяются для каждой строки товаров.
Когда в структуре отчета используются Детальные записи, СКД выводит абсолютно каждую физическую строку результирующей выборки. Если мы просто убираем поле номенклатуры из выбранных полей, СКД перестает отображать саму колонку, но количество физических строк в выборке не уменьшается. Механизм детальных записей не выполняет автоматическую свертку одинаковых строк, поэтому мы получаем визуальные дубли документов.
Это самый быстрый, штатный и архитектурно правильный способ решения проблемы на уровне пользовательских или системных настроек конкретного варианта отчета. Разберем по шагам, как правильно перенастроить структуру:
Ссылка, Документ или Номер).При таком подходе компоновщик данных автоматически схлопнет одинаковые значения группировочных полей, и задваивание полностью исчезнет без изменения текста исходного запроса.
Если в отчет необходимо вывести большой набор различных реквизитов документа и нет желания настраивать сложную иерархию полей, применим группировку всех полей в одну строку. Рассмотрим порядок действий:
В этом случае СКД автоматически сгруппирует результат по всему списку нересурсных полей, выбранных для отображения, что позволит получить чистый список без дублей.
Если в схеме компоновки данных реализовано несколько вариантов отчетов (одни требуют детализации по товарам, а другие — только итоговых данных по документам), оптимальным решением является разделение данных на два независимых набора данных-запроса.
Разберем структуру такой схемы:
Ссылка = Ссылка (источник связи — НаборДанных1, приемник — НаборДанных2).Преимущество такого подхода заключается в том, что СКД оптимизирует исполнение запросов: если в текущем варианте отчета поля из НабораДанных2 не задействованы, второй запрос к табличной части вообще не будет выполняться СУБД. Это не только исключит задваивание строк, но и существенно повысит производительность формирования отчета.
Если отчет изначально строится вокруг одного набора данных и не предполагает вывода подчиненных строк ни в одном из вариантов, проанализируем текст исходного запроса. В случаях, когда дубли возникают из-за левых соединений, можно использовать ключевое слово РАЗЛИЧНЫЕ:
ВЫБРАТЬ РАЗЛИЧНЫЕ
РеализацияТоваровУслуг.Ссылка КАК Документ,
РеализацияТоваровУслуг.Контрагент КАК Контрагент,
РеализацияТоваровУслуг.СуммаДокумента КАК СуммаДокумента
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
Однако помните, что добавление РАЗЛИЧНЫЕ создает дополнительную нагрузку на сервер баз данных при сортировке и поиске уникальных записей, поэтому замена детальных записей на группировки в СКД чаще является более гибким и предпочтительным решением.
Обратим внимание на числовые показатели. Если в отчете выводятся суммы или количества, важно проверять настройки на вкладке Ресурсы. Если поле является ресурсом, то при использовании детальных записей с дублирующимися строками ресурс выведет значение для каждой строки без агрегации. При правильной замене детальных записей на группировку СКД рассчитает итоговые выражения по указанным формулам (например, Сумма(СуммаДокумента)), что гарантирует корректность числовых итогов в отчете.