Виды иерархии в системе 1С:Предприятие 8

В платформе 1С:Предприятие 8 иерархия — это встроенный механизм организации данных в древовидную структуру. Она реализуется в объектах метаданных «Справочник» и «План видов характеристик», а также косвенно поддерживается в планах счетов. Понимание видов иерархии критично при проектировании конфигурации: от выбранного типа зависит, как будут строиться отчёты, как работать отборы и как писать запросы с итогами по группам.

Платформа предлагает три базовых варианта иерархии для справочников: «Группы и элементы», «Элементы» и отказ от иерархии (плоский список). Дополнительно существует механизм подчинённых справочников — формально это не иерархия внутри одного объекта, но на практике она решает схожие задачи связи «родитель — потомок». Каждый вариант имеет свои ограничения по группировке, поиску и обмену данными.

Ошибка при выборе вида иерархии обходится дорого: изменение типа иерархии в заполненном справочнике требует миграции данных, а в типовых конфигурациях такое изменение вообще может нарушить логику обновления. Поэтому решение принимают на этапе проектирования, исходя из того, какую роль играют группы — только папки для навигации или полноценные объекты учёта.

Где в конфигураторе задаётся вид иерархии

Вид иерархии настраивается в конфигураторе в свойствах справочника на закладке «Иерархия». Там же включается флаг «Иерархический справочник», выбирается вид иерархии и при необходимости устанавливается ограничение на количество уровней вложенности. Для планов видов характеристик механизм аналогичен.

После включения иерархии у справочника появляется стандартный реквизит «Родитель» (Parent), который хранит ссылку на вышестоящий объект. Именно через этот реквизит строятся запросы с обходом дерева, проверки принадлежности к группе и итоги по иерархии в СКД.

Иерархия групп и элементов: классический вариант

Это наиболее распространённый вид. Справочник делится на два типа объектов: группы (папки) и элементы. Группы служат только для структурирования и не могут использоваться там, где ожидается элемент — например, группу номенклатуры нельзя указать в табличной части документа, если в типовой логике стоит проверка. Элементы, в свою очередь, не могут содержать потомков.

Типичный пример — справочник «Номенклатура» в торговых конфигурациях: папки «Товары», «Услуги», «Материалы» задают структуру, а конкретные позиции лежат внутри. В запросах группы и элементы различаются по полю «ЭтоГруппа» (IsFolder), что позволяет фильтровать выборку.

Ограничение варианта: если папка должна нести учётную нагрузку (например, по контрагенту-головной организации нужно видеть долг с учётом всех филиалов, но при этом выставлять счёт именно ей), модель «группы — только папки» не подходит, и приходится выбирать иерархию элементов.

ВЫБРАТЬ Номенклатура.Ссылка ГДЕ Номенклатура.ЭтоГруппа = ЛОЖЬ И Номенклатура.Родитель = &Группа

Иерархия элементов: когда папки не нужны

При виде иерархии «Элементы» любой объект справочника может быть одновременно родителем для других объектов и самостоятельной учётной единицей. Отдельного типа «группа» не существует — поле «ЭтоГруппа» всегда ложно. Дерево строится произвольно: у элемента могут быть потомки, у потомков — свои потомки.

Классический пример — справочник «Подразделения», где департамент, отдел и рабочая группа являются полноценными объектами учёта: на любой из них можно назначить сотрудника или повесить ответственность. Другой пример — «Статьи затрат» с детализацией от укрупнённой статьи к конкретной.

При выборе этого вида учитывайте, что пользователи смогут указывать в документах и родителей, и потомков. Если бизнес-логика требует выбирать только «листья» дерева, контроль придётся реализовывать программно — проверкой наличия дочерних элементов.

Подчинённые справочники: иерархия через владельца

Механизм подчинённых справочников реализует связь «один ко многим» между двумя разными объектами метаданных. У подчинённого справочника появляется стандартный реквизит «Владелец» (Owner), ссылающийся на элемент родительского справочника. Примеры из типовых решений: «Договоры контрагентов» подчинены «Контрагентам», «Банковские счета» — «Организациям».

Формально это не иерархия — владелец и подчинённый объект принадлежат разным таблицам и разным типам. Но функционально механизм решает ту же задачу: организует данные по принципу «родитель — потомок», позволяет открывать список подчинённых объектов отбором по владельцу и строить отчёты с группировкой.

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

Ограничение уровней и особенности планов счетов

В свойствах иерархического справочника можно задать «Количество уровней иерархии». Значение 0 означает неограниченную вложенность. Ограничение уровней полезно, когда структура регламентирована — например, классификатор с фиксированной глубиной, — и снижает риск случайного создания избыточной вложенности пользователями.

Планы счетов используют собственную модель: иерархия там реализуется через признак «Забалансовый» и порядковый номер счёта (код), а субсчета связаны с родительским счётом по маске кода. Фактически это иерархия элементов, но обход дерева выполняется не через реквизит «Родитель», а через соотношение кодов счетов, что важно учитывать при написании запросов к бухгалтерским итогам.

Планы видов характеристик поддерживают те же два вида иерархии, что и справочники, — «Группы и элементы» и «Элементы». Выбор делается по тем же критериям: если группа характеристик должна сама назначаться объекту, используйте иерархию элементов.

Работа с иерархией в запросах и отчётах

Для проверки принадлежности элемента группе с учётом всех уровней вложенности используется оператор «В ИЕРАРХИИ» — он охватывает не только прямых потомков, но и всю ветку дерева. Это стандартный способ отбора, например, всей номенклатуры группы «Мебель» независимо от глубины вложенности папок.

Для построения отчётов с группировкой по дереву в СКД применяется итог по иерархии поля, а в обычных запросах — конструкция «ИТОГИ ПО ... ТОЛЬКО ИЕРАРХИЯ». Она формирует записи итогов для каждого узла дерева, что позволяет вывести суммы по группам без рекурсивных обходов в коде.

1. 1
   Убедитесь, что справочник иерархический и у элементов заполнен реквизит «Родитель»
2. 2
   В запросе используйте условие: Ссылка В ИЕРАРХИИ(&Группа)
3. 3
   Передайте в параметр ссылку на группу или элемент-родителя
4. 4
   Проверьте результат на элементе из вложенной подгруппы — он должен попасть в выборку

Типичные ошибки и ограничения

Самая частая ошибка проектирования — выбор вида «Группы и элементы» там, где родитель должен быть объектом учёта. Переделка на лету невозможна: при смене вида иерархии платформа не превратит группы в элементы автоматически, потребуется обработка переноса с пересозданием ссылок или аккуратной заменой ссылок во всех связанных объектах.

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

Третья группа проблем связана с обменом данными: при синхронизации иерархических справочников сначала должен загружаться родитель, иначе потомок получит пустого родителя или «битую» ссылку. В планах обмена это решается порядком выгрузки и механизмом разрешения коллизий.

Как выбрать вид иерархии под задачу

Критерий выбора простой: ответьте на вопрос, может ли родительский узел сам участвовать в учёте. Если нет — это папка, выбирайте «Группы и элементы». Если да — выбирайте «Элементы». Если потомок имеет собственный состав реквизитов и документы движения — делайте подчинённый справочник.

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

Проверить корректность выбранной структуры можно простым тестом: создайте три уровня вложенности, введите документ с элементом нижнего уровня и постройте отчёт с группировкой по иерархии. Если итоги сходятся на каждом уровне и отбор «В ИЕРАРХИИ» возвращает полную ветку — структура спроектирована верно.

Частые вопросы