Каталог решений - Чтоб в СКД по таблице значений был порядок!

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

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

Несмотря на правильное описание полей набора, задание порядка на уровне отчёта в целом не срабатывает. Ни через форму, ни кодом. Рассмотрение тела макета компоновки показывает, что порядок из настроек проигнорирован:

  ОсновнаяГруппировка=МакетКомпоновки.Тело.Получить(N); // по умолчанию имеет Идентификатор и Имя "Группировка"
  // её поле Порядок, т.е. коллекция выражений упорядочивания, будет пусто

Попытки как-либо программно изменить это ничего не дают:

  // допустим, основной набор по источнику называется "ОсновнойНабор" и в нём есть поле "Номенклатура"
  ЭлементПорядка=ОсновнаяГруппировка.Порядок.Добавить();
  // ЭлементПорядка.Автоупорядочение=Истина; // вызывает ошибку синтаксиса СКД
  // а, казалось бы, логичная попытка добавить
  ЭлементПорядка.Выражение="ОсновнойНабор.Номенклатура";
  // просто игнорируется, не вызывая никакой ошибки.

Таким же образом себя ведут настройки для ТелоИерархии и ИерархическийПорядок, если плоская выборка должна включать развёртку иерархии. Ни типизация, ни настройки роли поля набора на это поведение не влияют.

Детальные записи, как младшая и единственная группировка, внесённая нами по умолчанию, и автовыбранные поля на уровне группировки детальных записей, т.е. 

  Группировка=НастройкиСКД.Структура.Добавить(Тип("ГруппировкаКомпоновкиДанных"));
  ГруппировкаКД.Использование=Истина;
  
  ВыбПоле=ГруппировкаКД.Выбор.Элементы.Добавить(Тип("АвтоВыбранноеПолеКомпоновкиДанных"));
  ВыбПоле.Использование=Истина;
  

не считаются процессором за "настоящую" группировку. Не знаю уж, почему — макет компоновки строится без учёта наличия источника — но факт.

Значит, группировку надо прописать явно:

  ВыбПолеГр=ГруппировкаКД.ПоляГруппировки.Элементы.Добавить(Тип("ПолеГруппировкиКомпоновкиДанных"));
  ВыбПолеГр.Поле=Новый ПолеКомпоновкиДанных("Номенклатура"); // именно просто имя колонки таб.значений
  ВыбПолеГр.ТипГруппировки=ТипГруппировкиКомпоновкиДанных.Элементы; // тут уже в зависимости от потребности задачи
  ВыбПолеГр.Использование=Истина;
  

Там же сразу можно задать и порядок, если надо совсем жёстко и независимо от интерфейса:

  ЭлементПорядка=ГруппировкаКД.Порядок.Элементы.Добавить(Тип("ЭлементПорядкаКомпоновкиДанных"));
  // итд.

Если на форме размещён элемент порядка, связанный с компоновщиком, обрабатывающим вывод, то теперь он тоже "найдёт" эту свою группировку в структуре, и корректно отработает. Т.е. явная группировка по всем колонкам таблицы значений эмулирует детальные записи, что, кстати, видно по оформлению финального вывода.

Интересно, что при рассмотрении Тела и вложенных Тел из макета компоновки видно — в их коллекциях "Порядок" есть элементы, но, если вывести структуру на форму, табличка покажет, что у старшей группировки нет элемента порядка (только у отчёта в целом и у финальной).

Ещё более интересно, что, при задании сортировки "Номенклатура ВОЗР", в "Порядок" группировки компоновки данных, как элемента того же Тела, всё-таки добавится запись. Причём ровно как пытались делать программно, т.е.  ЭлементПорядка.Выражение = "ОсновнойНабор.Номенклатура"; но теперь оно сработает. И, у него будет включено автоупорядочивание. Причём на всех уровнях, если структура подразумевает несколько группировок вывода отчёта.

При сортировке по реквизитам картина ещё забавнее. Роль поля в наборе по умолчанию не запрещает сортировку по реквизитам, можем сортировать, например "Номенклатура.ТипТовара ВОЗР". Выражение элемента порядка в Теле будет иметь вид "НоменклатураРеквизиты.Номенклатура.ТипТовара", и без автоупорядочения. Без упоминания набора вообще. При этом дочерний набор  "НоменклатураРеквизиты" в явном виде в макете отсутствует.

А если говорить не о "последней" (или единственной) эмулирующей группировке, а о нескольких группировках вывода, то, кроме всегда добавляемых "<ИмяНабора>.<ИмяКолонки>" автоупорядочиваемых полей старших группировок, на промежуточных уровнях автоматически добавляются в Порядок соответствующего Тела ещё и такие записи:
"НоменклатураРеквизиты.Номенклатура.ТипТовара.ПолеУпорядочивания"
"НоменклатураРеквизиты.Номенклатура.ТипТовара.ПолеУпорядочивания2",
и они тоже всегда с выключенным автоупорядочением. 
Найти логику в составе этих записей мне пока не удалось. Их всегда две. Ни от глубины структуры, ни от свойств роли, ни от типизации не зависят. Возможно, это автодобавленные поля-индексы временной выборки для внутреннего представления и разыменования, или для разных направлений… Кто знает — пишите. Может, где-то в этой специфике скрывается недопустимость деревьев значений как источников СКД…

Если всё это давно известно, а я дремучий дикарь, то тухлые помидоры приветствуются.

Расписывать все нюансы не вижу смысла — на практике остальное либо очевидно, либо крайне редко нужно.

p.s. Интересно, как себя ведёт компоновщик макета в случае временных таблиц, подача которых на вход СКД с недавнего времени стала возможна.