Среди множества статей, обзоров и курсов этот инструмент освещён достаточно мало, но и у него есть своя область применения, свои возможности и особенности.
По сути, это отдельные СКД, со своей логикой, источниками, наборами, параметрами, вычисляемыми полями и т.д., которые можно в капсулированном виде, как блоки, встраивать в другие отчёты. Между исходной СКД и вложенными в неё может не быть жёсткой бизнесовой, логической, технической связки. Исходная (старшая, ведущая, владелец) СКД не имеет доступа внутрь вложенных ни на каком этапе своей работы, а вложенные, в свою очередь, знают о старшей только самое основное - её поля и параметры. Компиляция всех их происходит от старшей к вложенным, поэтому вложенные могут оперировать её основными данными.
Вложенные СКД могут почти никак не пересекаться со старшей по набору полей. Более того, старшая необязательна, можно набрать результат просто из нескольких вложенных схем. Так, мы оперируем совсем разными множествами разных данных, сопрягая их единым действием в единый результат.
Применение
Вложенные СКД имеют смысл:
- Для быстрого заимствования одного отчёта в другой, для модульной сборки "мета-отчёта" из нескольких разнонаправленных подотчётов. Это не расшифровка, это именно одновременный показ - например, для руководителя - и кусочка продаж, и кусочка сальдо, и кусочка по з/п. Интеграция, которая иначе потребовала бы сборки из нескольких наборов данных и "изобретения велосипеда" по логике уже имеющихся в системе отчётов.
- Для служебного получения данных, имеющих разный состав полей, в рамках единой коллекции. Для "сборки" разных данных, с разной логикой их группировки, свёртки, отбора, в единую таблицу значений или дерево значений. Программное создание такой СКД позволяет легко собрать вместе, в плоском или иерархическом виде, результаты отчётов системы, выборок дин.списков, свои фрагменты и типовые, итд.
Вывод результата выполнения вложенных СКД удобен для работы с различными тета-соединениями, в т.ч. таблицы с самой собой; не всегда это можно сделать запросом (например, часть входящих данных - источники-объекты таблицы значений). Удобно для построения сложных таблиц значений и деревьев с неоднородным содержанием различных подветок и блоков, когда смысловые группировки верхнего уровня не должны сказываться на подуровнях-блоках. Состав колонок итоговой коллекции, скомпонованный из всех выбранных полей всех вложенных СКД, из самых разных наборов, компонуется быстро и более прозрачно, чем при сборке соединением разных наборов (особенно в пользовательском режиме - наглядно, прозрачно, управляемо). На больших объёмах может быть получен выигрыш по занимаемой памяти, т.к. результат обычной СКД с группировкой, выгруженный в коллекцию, заполняет все строки полей старшей группировки их значениями, а результат вложенных СКД заполняет для старшей - старшие, а для каждой вложенной - только её поля, прочие же, независимо от их наличия и типа в наборах, всегда имеют тип Неопределено. Именно "Неопределено", а не Null. Так та же коллекция значений "легче" по наполненности, иногда это критично, хотя иногда может и затруднить пост-обработку этой коллекции. Но, например, для обменов, в т.ч. с сериализацией коллекций, получение "полупустой" коллекции, сохраняющей при этом свой смысл, это удобно. Разница на примере деревьев:
Построенное вложенными СКД
Построенное "обычными" способами
Жаль, конечно, что вывод в коллекции возможен только для группировок, а не для, допустим, таблиц структуры, это бы ещё больше упростило компоновку.
Недостатком вложенных СКД является их низкая производительность. Каждая СКД компилирует результат по собственному макету компоновки без кэширования и без временных выборок, непосредственно на уровне процессоров вывода результата и, судя по замерам, имеет место банальный nested loop. Если поля соединения могут иметь различные типы (особенно для определяемых типов и субконто), скорость падает ещё на 7-15%, в итоге СКД с вложенными проигрывает аналогичным по идее простым запросам в разы и десятки раз.
Для примера - запрос с группировкой "Итоги по Номенклатура", получающий на верхнем уровне товары, а на вложенном их продажи, выполнялся 4 секунды, а СКД с вложенной по продажам - 11 минут. Товары: 37500 элементов справочника, продажи: 28200 записей в оборотном регистре за месяц.
В обоих случаях запрашивался минимум полей, СКД была простейшая. База серверная, SQL 2012. К сожалению, по моим наблюдениям, торможение растёт экспоненциально.
Выгрузка в дерево или в таблицу значений для вложенных СКД быстрее, чем в макет, стабильно на 10-15% (особенно если макеты таб.документа заданы явно).
Вложенные СКД могут давать меньшую нагрузку на сервер СУБД, особенно если их запросы просты, но гораздо большую на сервер приложения, т.к. компоновка итоговой выборки делается на нём.
Случаи некорректного поведения
- Просмотр структуры варианта настройки при участии вложенных СКД на некоторых релизах (8.3.6-8.3.8, 8.3.13, возможно и других) глючит, и показывает через раз не ту структуру, что на самом деле, а кусок. В таких случаях разумно перещёлкнуть туда-сюда закладки или переоткройте для обновления.
- Сбоит правка параметров в настройке вложенной СКД, сдвигаются редактируемые колонки. При навигации по структуре варианта, находясь на ветке вложенного отчёта, видим всё по нему, хотя в кнопке-переключателе под деревом структуры выделен пункт "Отчёт" - и не следует выбирать кнопку вложенного, даже если она доступна - это приводит к аварийному завершению работы 1С.
- Кнопка "Сохранить" меню "Файл" при открытом конструкторе вложенной СКД касается не исходного объекта метаданных, чья правка идёт (например, отчёта), и блокируется для всех случаев, кроме, например, запроса, который предлагает сохранять в независимый файл. Попытка открыть конструктор вложенной СКД в режиме Предприятие из конструктора старшей СКД может также аварийно завершить работу 1С.
- Правка вложенной СКД не ставит флаг модификации исходного объекта. Закрытие конструктора старшей СКД без вопросов закрывает конструкторы вложенных, в т.ч. если там было множество изменений. Будьте внимательны, сохраняйте изменения вложенных СКД принудительно.
- Единожды указав имя вложенной СКД, не рекомендуется менять его, т.к. при этом слетают абсолютно все настройки в варианте отчёта, т.е. корректной замены не происходит. Причём представление меняется корректно, в т.ч. для уже указанных вложенных отчётов в структуре варианта. В пользовательском варианте приоритетно имя отчёта, а не собственно вложенной СКД.
- Если с помощью кнопок переноса и драг-н-дропа мышью закинуть поля вложенной СКД в группировки старшей, и наоборот, то это получается и конструктор настройки это вроде бы поддерживает - но не исполняет (иногда даже без сообщений об ошибке, просто игнорирует).
Настройки
Отражением вложенной СКД в структуре варианта настройки является "Вложенный отчёт".
Собственные исходные настройки вложенной СКД менее приоритетны, чем указанные принудительно настройки вложенного отчёта в варианте отчёта. Во вложенных схемах можно вообще не делать свои настройки вариантов. "Родительская схема все равно будет отдельно хранить свои настройки для вложенной схемы" (с) Чистов
Старшая (ведущая) СКД, её поля, параметры и отборы представлены в настройках вложенных СКД папкой "ОбъектНастройкиВладелец".
В подавляющем большинстве случаев настройка, находящаяся в колонке "Настройки" на закладке вложенных СКД, не критична и не нужна. Она имеет смысл, если никакие настройки и отборы более нигде не заданы, и предоставляет значения параметров (и только их) по умолчанию в панели настроек варианта отчёта. По моим наблюдениям, отбор этой настройки вообще ни на что не влияет (хотя, возможно, этот вопрос нуждается в уточнении). Параметры также, по сути, игнорируются. Так, можно вообще ничего не задать в настройках вложенной, но задать в настройках варианта отчёта. Более того, если включить параметры в поля выборки (например, пользовательским полем), то видно, что, в отсутствие настроек варианта, параметры вложенного отчёта даже не инициализированы.
При этом, параметры вложенных СКД рекомендуется включать в доступные и снимать ограничение доступности. Иначе ни из структуры старшей СКД, ни из настроек вложенной их увидеть и менять будет нельзя.
Поэтому все дальнейшие упоминания отборов и параметров касаются только настройки варианта отчёта.
Параметры вложенных СКД рекомендуется задавать через параметры старшей, в т.ч. с использованием допустимых выражений языка СКД (например, "НачПериода" по
"ОбъектНастройкиВладелец.ПараметрыДанных.НачДата"). Причём по сути там фигурирует "ВыражениеКомпоновкиДанных" (а не строка), и выражения вида "&НачПериода", обращающиеся к явно указанным параметрам старшей СКД, работать не могут.
Если выборка вложенной СКД включена на некий уровень группировки, то соединение всегда левое - все записи старшей группировки и, согласно указанным отборам, соответствующие записи вложенной СКД. Если при включении на некий подуровень отборы не указаны, выполняется левое соединение каждой старшей записи со всеми вложенными записями. Причём неважно, какое поле слева в отборе, а какое справа.
Также выборка вложенной СКД может быть помещена сразу на верхний уровень, при этом отборы соединения со старшей СКД вообще не требуются; более того, для вывода вложенной на верхнем уровне такие отборы следует удалять/отключать. Даже на верхнем уровне никакие параметры и отборы,
заданные в настройке вложенной, не имеют значения.
В некоторых релизах наблюдается проблема - отсутствуют поля выборки вложенной СКД в ветке ОбъектНастройкиВладелец. Если вложенная СКД это запрос, следует их явно объявить через закладку редактора запроса "КомпоновкаДанных" для вложенной СКД (т.е. чтобы в ней была секция {} раздела "Условия"). Если же это объект-источник, следует явно типизировать поля набора.
В полях группировки в структуре и на закладке "Сортировка" поля ОбъектНастройкиВладелец недоступны. Т.е. они есть только в "Выбранные поля" и "Отборы".
Условное оформление полей вложенного отчёта позволяет упоминать старшие через ОбъектНастройкиВладелец (и как оформляемое поле, и как отбор условия), но срабатывание зависит от осмысленности операции - т.е. если отбор УО по старшему, а оформляем вложенное, то работает, и понятие "Везде" в этом случае шире, чем если и отбор, и оформляемое - вложенные, т.к. захватывает реально весь "подотчётный" блок. А вот прочие случаи условного оформления, даже если их позволит указать
конструктор, не отрабатывают.
"Другие настройки" всегда касаются сугубо вложенного отчёта и никак не пересекаются с настройками старших.
Служебные поля СКД (№ п/п, уровень) ориентируются по СКД, т.е. для старших группировок они свои, а для "подотчётных" блоков свои, в раздельных "координатах" и нумерациях.
В вычисляемых и пользовательских полях старшей СКД неприменимы и недоступны данные вложенных СКД (ни в Конфигураторе, ни в Предприятии). Данные существуют в разных "пространствах" и "встречаются" только при финальной компоновке, в макет или в коллекцию.
Пользовательские поля могут ввести в заблуждение: например, для поля "выбор" на уровне вложенного отчёта в отборах есть обращение к ОбъектНастройкиВладелец, и настройка сохраняется, но при исполнении это приводит к "Ошибка генерации макета по причине: Ошибка при получении информации"<старшее поле>, т.е. не работает.
Примечания
Количество вложенных СКД не ограничено.
К одной старшей группировке можно добавлять несколько вложенных отчётов, главное - их правильная привязка. Можно несколько раз вносить одну и ту же вложенную СКД как несколько вложенных отчётов, с разными связями, отборами, визуализацией. Находясь на одном уровне, вложенные "видят" только поля старшего, но не друг друга. Две вложенных СКД соподчинить друг другу нельзя (т.е. чтобы одна была вложенным отчётом другой), они всегда равноподчинённы.
1С поддерживает древовидную вложенность, т.е. у вложенной СКД в свою очередь могут быть вложенные. Для каждого открывается свой конструктор, поведение аналогично работе с обычной вложенной. На старшем уровне структуры варианта отчёта возможен вывод только "непосредственно" вложенных, их суб-вложения уже недоступны (они всегда иерархично подчиненные в структуре отчёта). Из вложенного отчёта любой "глубины" через разыменование доступны поля, отборы и параметры верхних данных, в т.ч. старших - например, "ОбъектНастройкиВладелец.ОбъектНастройкиВладелец.Товар". Выгрузка любой структуры сложности вложенных отчётов в таблицу значений и дерево значений выполняется корректно.
Решение одной проблемы
В интернет встречаются вопросы на тему оформления результатного макета отчёта, включающего вложенный. Вопрос формулируется так: "избавиться от пустых под-блоков вложенного отчёта", т.е. не выводить блоки вложенного для тех записей старшей группировки, для которых вложенный пуст.
Поскольку речь о левом соединении, то, очевидно, превратить его логику построения во внутреннее соединение не удастся, и в выгрузке в коллекцию всё неизменно. Но вот избавиться от визуально лишних под-блоков можно.
Дело в том, что при появлении в группировке вложенного отчёта все поля этой группировки выводятся строго и только в виде "наименование" - "значение" одна под другой, и этим можно воспользоваться - объявить для вложенной СКД свою суб-вложенную, для вложенного отчёта в структуре - свой вложенный. Тогда, очевидно, при пустых выборках суб-вложенного сам вложенный, вынужденно представляемый уже не как таблица, окажется принципиально пуст, и будет видна только запись данных старшего уровня. А логику визуализации непустых можно перенести уже на суб-вложенный.
Исполнение
Программно вложенные СКД доступны как элементы коллекции "ВложенныеСхемыКомпоновкиДанных" старшей СКД. Эта коллекция доступна для чтения и рассмотрения:
Для каждого влож Из Схема.ВложенныеСхемыКомпоновкиДанных Цикл
//влож.Имя - системное имя вложенной СКД
//влож.Заголовок - представление
//влож.Настройки // обычные НастройкиКомпоновкиДанных
// влож.Схема - собственно вложенная схема
КонецЦикла
Можно при желании удалять ненужные схемы. Однако, добавление и изменение в части самой СКД возможно лишь если "Схема" инициализировано. Если просто выполнить код
влож=Схема.ВложенныеСхемыКомпоновкиДанных.Добавить();
// влож.Схема при этом Неопределено
то поле "Схема" добавленного элемента коллекции будет не инициализировано, и штатными средствами языка 1С это сделать нельзя. Для копирования, вставки, инициализации СКД следует применять работу с xml. Схемы сериализуются, сохраняются в файлы, поэтому удобны для простых вставок друг в друга.
Имя вложенной СКД должно строго следовать нотации имён метаданных, иначе старшая СКД её нормально не воспримет (т.е. показать-то покажет и даже править даст, но при выполнении скажет, что "Не найдено описание вложенного объекта настройки").
Большинство полезных операций имеет смысл над структурой варианта отчёта, куда вставлены вложенные. В структуре на соответствующем уровне элемент будет иметь имя не Структура, а Настройки, и тип НастройкиВложенногоОбъектаКомпоновкиДанных, а уже в нём будут обычные настройки СКД. Можно использовать порядковые номера, можно через свойство ИдентификаторОбъекта. Например,
КомпоновщикНастроек.Настройки.Структура[N].Структура[М].Настройки.ПараметрыДанных;
// так же к коллекции "Отбор" итд.
В момент исполнения (построения) на уровне платформы 1С вложенный отчёт представлен объектом ВложенныйОбъектМакетаКомпоновкиДанных, расположенным внутри одной из группировок:
влоб=МакетКомпоновки.НаборыДанных[Х].Тело[N].Тело[М] // это ВложенныйОбъектМакетаКомпоновкиДанных, и дальше можно
// рассматривать его макет компоновки влоб.КомпоновкаДанных
Все макеты (и вывода, и компоновки) у вложенного отчёта свои, компоновка своя, но всё штатно, как и для обычной СКД - и отборы, и параметры.
Для вложенного отчёта определена коллекция "ЗначенияПараметров" типа ЗначенияПараметровМакетаКомпоновкиДанных, где каждый параметр это ЗначениеПараметраМакетаКомпоновкиДанных:
// параметр
// ОбъектНастройкиВладелецПараметрыДанныхКонДата, значение &КонДата, т.е. сам всё-таки разыменует, хотя нам так писать не даёт.
// отбор
// ОбъектНастройкиВладелецТовар и значение, например, "ОсновнойНабор.Товар"
Значения тут тоже не строки, а ВыражениеКомпоновкиДанных.
Не следует путать понятия вложенного отчёта с коллекцией ВложенныеНаборыДанных в наборе данных.
Ссылки
На ИС общие принципы работы с вложенными СКД описаны очень хорошо тут, см. также пример. Интересное применение здесь.