Вывод таблицы значений в табличный документ с помощью СКД многократно описан в книгах и публикациях. Действительно, удобно заранее по нужным принципам подготовить таблицу, задействовать все возможности СКД и красиво показать финальные данные. Но есть такие нюансы, которые могут ограничить функциональность, и важно знать правильное решение.
Эта заметка посвящена порядку. Сортировке. Допустим, есть таблица значений и определённый программно порядок, либо размещённый в интерфейсе элемент управления порядка компоновщика настроек.
Упорядочение можно задать в конструкторе, для каждого поля прописав выражение, направление, необходимость автоупорядочения. Это наследуется для полей в группировках, т.е. вложенные неявно получают включённое автоупорядочение вплоть до детальных записей, что наблюдаемо и удобно. При программной работе это не очевидно и, более того, для СКД по источнику не срабатывает. При компоновке макета по источнику процессор компоновки игнорирует указания автоупорядочения и требует прописывания в явном виде, для каждого уровня структуры выводимого таб.документа свой порядок. Поскольку часто встречается "плоский вывод" таблицы значений в детальные записи, рассмотрим его.
Несмотря на правильное описание полей набора, задание порядка на уровне отчёта в целом не срабатывает. Ни через форму, ни кодом. Рассмотрение тела макета компоновки показывает, что порядок из настроек проигнорирован:
ОсновнаяГруппировка=МакетКомпоновки.Тело.Получить(N); // по умолчанию имеет Идентификатор и Имя "Группировка"
// её поле Порядок, т.е. коллекция выражений упорядочивания, будет пусто
Попытки как-либо программно изменить это ничего не дают:
// допустим, основной набор по источнику называется "ОсновнойНабор" и в нём есть поле "Номенклатура"
ЭлементПорядка=ОсновнаяГруппировка.Порядок.Добавить();
// ЭлементПорядка.Автоупорядочение=Истина; // вызывает ошибку синтаксиса СКД
// а, казалось бы, логичная попытка добавить
ЭлементПорядка.Выражение="ОсновнойНабор.Номенклатура";
// просто игнорируется, не вызывая никакой ошибки.
Таким же образом себя ведут настройки для ТелоИерархии и ИерархическийПорядок, если плоская выборка должна включать развёртку иерархии. Ни типизация, ни настройки роли поля набора на это поведение не влияют.
Детальные записи, как младшая и единственная группировка, внесённая нами по умолчанию, и автовыбранные поля на уровне группировки детальных записей, т.е.
ГруппировкаКД=НастройкиСКД.Структура.Добавить(Тип("ГруппировкаКомпоновкиДанных"));
ГруппировкаКД.Использование=Истина;
ВыбПоле=ГруппировкаКД.Выбор.Элементы.Добавить(Тип("АвтоВыбранноеПолеКомпоновкиДанных"));
ВыбПоле.Использование=Истина;
не считаются процессором за "настоящую" группировку. Не знаю уж, почему - макет компоновки строится без учёта наличия источника - но факт.
Значит, группировку надо прописать явно:
ВыбПолеГр=ГруппировкаКД.ПоляГруппировки.Элементы.Добавить(Тип("ПолеГруппировкиКомпоновкиДанных"));
ВыбПолеГр.Поле=Новый ПолеКомпоновкиДанных("Номенклатура"); // именно просто имя колонки таб.значений
ВыбПолеГр.ТипГруппировки=ТипГруппировкиКомпоновкиДанных.Элементы; // тут уже в зависимости от потребности задачи
ВыбПолеГр.Использование=Истина;
Там же сразу можно задать и порядок, если надо совсем жёстко и независимо от интерфейса:
ЭлементПорядка=ГруппировкаКД.Порядок.Элементы.Добавить(Тип("ЭлементПорядкаКомпоновкиДанных"));
// итд.
Если на форме размещён элемент порядка, связанный с компоновщиком, обрабатывающим вывод, то теперь он тоже "найдёт" эту свою группировку в структуре, и корректно отработает. Т.е. явная группировка по всем колонкам таблицы значений эмулирует детальные записи, что, кстати, видно по оформлению финального вывода.
Интересно, что при рассмотрении Тела и вложенных Тел из макета компоновки видно - в их коллекциях "Порядок" есть элементы, но, если вывести структуру на форму, табличка покажет, что у старшей группировки нет элемента порядка (только у отчёта в целом и у финальной).
Ещё более интересно, что, при задании сортировки "Номенклатура ВОЗР", в "Порядок" группировки компоновки данных, как элемента того же Тела, всё-таки добавится запись. Причём ровно как пытались делать программно, т.е. ЭлементПорядка.Выражение = "ОсновнойНабор.Номенклатура"; но теперь оно сработает. И, у него будет включено автоупорядочивание. Причём на всех уровнях, если структура подразумевает несколько группировок вывода отчёта.
При сортировке по реквизитам картина ещё забавнее. Роль поля в наборе по умолчанию не запрещает сортировку по реквизитам, можем сортировать, например "Номенклатура.ТипТовара ВОЗР". Выражение элемента порядка в Теле будет иметь вид "НоменклатураРеквизиты.Номенклатура.ТипТовара", и без автоупорядочения. Без упоминания набора вообще. При этом дочерний набор "НоменклатураРеквизиты" в явном виде в макете отсутствует.
А если говорить не о "последней" (или единственной) эмулирующей группировке, а о нескольких группировках вывода, то, кроме всегда добавляемых "<ИмяНабора>.<ИмяКолонки>" автоупорядочиваемых полей старших группировок, на промежуточных уровнях автоматически добавляются в Порядок соответствующего Тела ещё и такие записи:
"НоменклатураРеквизиты.Номенклатура.ТипТовара.ПолеУпорядочивания"
"НоменклатураРеквизиты.Номенклатура.ТипТовара.ПолеУпорядочивания2",
и они тоже всегда с выключенным автоупорядочением.
Найти логику в составе этих записей мне пока не удалось. Их всегда две. Ни от глубины структуры, ни от свойств роли, ни от типизации не зависят. Возможно, это автодобавленные поля-индексы временной выборки для внутреннего представления и разыменования, или для разных направлений... Кто знает - пишите. Может, где-то в этой специфике скрывается недопустимость деревьев значений как источников СКД...
Если всё это давно известно, а я дремучий дикарь, то тухлые помидоры приветствуются.
Расписывать все нюансы не вижу смысла - на практике остальное либо очевидно, либо крайне редко нужно.
p.s. Интересно, как себя ведёт компоновщик макета в случае временных таблиц, подача которых на вход СКД с недавнего времени стала возможна.
