Произвольная иерархия в СКД: вывод дерева значений

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

Произвольная иерархия в СКД

Относительно недавно попал на доработку отчет, содержащий приличное количество кода, который в итоге был выброшен полностью, поскольку возможностей системы компоновки данных вполне хватило для получения необходимого результата. Большая часть этого кода как раз отвечала за построение иерархической структуры. К сожалению, этому разработчику продемонстрировать возможности СКД возможности нет. Но поделиться со всеми остальными коллегами, интересующимися данной темой, это всегда пожалуйста :)

В СКД можно реализовать следующие варианты построения иерархии:
- к основному набору данных достраивается иерархическая структура;
- рекурсивное построение иерархии по одному набору данных.
В этом посте я хочу рассмотреть второй вариант на примере ресурсных спецификаций в демо-базе 1С:ERP 2.

Реализация иерархии в перечислениях

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