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