Справочники и Данные · 13 мин
Зачем нужны иерархические справочники в 1С
Разбираем, зачем нужны иерархические справочники в 1С, как выбрать тип иерархии, настроить группы и избежать типичных ошибок при работе с данными.
Иерархический справочник в 1С — это справочник, элементы которого можно объединять в группы и подгруппы, образуя древовидную структуру. Вместо плоского списка из тысяч позиций пользователь видит понятное дерево: «Товары → Электроника → Ноутбуки → Игровые ноутбуки». Без такой структуры поиск нужной позиции в базе с большим ассортиментом превращается в рутину, а отчёты теряют аналитическую ценность.
Практическая ценность иерархии проявляется в трёх вещах: быстрый поиск и навигация по данным, корректная группировка в отчётах и проводках, а также разграничение прав и ответственности между сотрудниками. Например, менеджер по закупкам видит только свою ветку номенклатуры, а бухгалтер строит оборотно-сальдовую ведомость с детализацией по группам контрагентов.
При этом иерархия — не универсальное решение. Неправильно выбранный тип иерархии или избыточная глубина вложенности создают проблемы: дубли групп, невозможность перенести элементы без потери связей, замедление выборок. Ниже разберём, как устроены иерархические справочники, какой тип выбрать под конкретную задачу и как проверить, что структура работает правильно.
Как устроена иерархия в справочниках 1С
Технически иерархия реализуется через реквизит «Родитель» (Parent), который платформа автоматически добавляет к справочнику при включении свойства «Иерархический». Каждый элемент ссылается на группу-родителя, а элементы верхнего уровня имеют пустого родителя. Такая модель позволяет строить дерево произвольной глубины без дополнительных таблиц.
Платформа поддерживает два принципиально разных вида иерархии: «иерархия групп и элементов» и «иерархия элементов». В первом случае справочник делится на группы (папки) и элементы, и элемент может лежать только в группе. Во втором случае любой элемент может быть родителем другого элемента — классический пример: справочник «Сотрудники», где руководитель и подчинённые хранятся в одном списке.
Выбор вида иерархии задаётся в конфигураторе на этапе проектирования и изменить его потом можно, но с осторожностью: при смене типа существующие данные могут потребовать ручной перестройки. Поэтому решение принимают до начала наполнения справочника.
Какие задачи решает иерархия на практике
Первая и самая очевидная задача — навигация. Когда в справочнике номенклатуры десятки тысяч позиций, плоский список неработоспособен: пользователь вынужден каждый раз пользоваться поиском по подстроке. Дерево групп позволяет сузить область поиска до нужной категории за два-три клика.
Вторая задача — аналитика в отчётах. Большинство типовых отчётов 1С умеют группировать данные по иерархии справочника: например, отчёт по продажам можно свернуть до уровня «группа товаров» и развернуть до конкретной позиции. Без иерархии такая гибкость недоступна — пришлось бы строить отдельные отчёты или использовать произвольные отборы.
Третья задача — наследование настроек. Во многих конфигурациях параметры, заданные для группы, применяются к вложенным элементам: счета учёта, ставки НДС, правила ценообразования. Это сокращает ручной труд при заведении новых позиций: достаточно поместить элемент в правильную группу, и основные настройки подтянутся автоматически.
Если список не помещается на несколько экранов, плоская структура тормозит работу
Номенклатура по типам, контрагенты по регионам, затраты по статьям
Руководство просит сводки по категориям, а не по отдельным позициям
Каждый менеджер работает со своей веткой каталога
Иерархия групп и элементов против иерархии элементов
Иерархия групп и элементов подходит для классификации: товаров, услуг, статей расходов, видов операций. Группа здесь — это «папка», она не участвует в документах как самостоятельный объект. В документе нельзя выбрать группу «Ноутбуки» вместо конкретного товара — платформа это контролирует автоматически, если в параметрах выбора установлен соответствующий отбор.
Иерархия элементов нужна, когда родитель — такой же полноценный объект, как и потомок. Типичный сценарий — подразделения организации: у отдела есть родительское управление, у управления — департамент, и каждый уровень можно указать в документе. Другой пример — контрагенты с головной компанией и филиалами.
Ошибочный выбор вида иерархии — частая проблема. Если для номенклатуры включить иерархию элементов, пользователи начнут создавать «товары внутри товаров», и отчёты по остаткам станут неочевидными. Если для подразделений выбрать иерархию групп, в группу нельзя будет принять сотрудника на должность — группы не участвуют в кадровых документах.
Выбор вида иерархии
Подходит для классификации: номенклатура, статьи затрат, виды документов. Группа — только папка, в документах не выбирается. Ограничение: нельзя указать группу как объект учёта.
Подходит, когда родитель — полноценный объект: подразделения, сотрудники, контрагенты с филиалами. Ограничение: нет визуального разделения на папки, структура может выглядеть менее очевидно.
Подходит для коротких списков без категорий: валюты, ставки, единицы измерения. Лишняя иерархия здесь только усложнит интерфейс.
Как включить и настроить иерархию
В типовых конфигурациях вид иерархии основных справочников уже задан разработчиками, и менять его не требуется. Настройка сводится к проектированию самой структуры групп. Делать это стоит до массового заведения данных: переносить тысячи элементов между группами после заполнения — трудоёмкая операция.
При проектировании структуры придерживайтесь правила: группа должна отвечать на один вопрос. «Телевизоры Samsung 55 дюймов» — плохая группа, потому что смешивает бренд и характеристику. Лучше: группа «Телевизоры», а бренд и диагональ — реквизиты элемента или дополнительные свойства. Глубину дерева разумно ограничить тремя-пятью уровнями: более глубокие структуры тяжело воспринимаются и замедляют навигацию.
Если вы разрабатываете собственный справочник в конфигураторе, последовательность такая: открыть свойства объекта, установить флажок «Иерархический», выбрать вид иерархии, при необходимости ограничить количество уровней. После обновления конфигурации в форме списка появится дерево групп.
- 1Определите, какие данные будут храниться, и проверьте, делятся ли они на устойчивые категории
- 2Выберите вид иерархии: группы и элементы — для классификации, элементы — для объектов с подчинением
- 3Спроектируйте дерево групп на бумаге: не глубже 3–5 уровней, без смешения признаков в одной группе
- 4Создайте группы в пользовательском режиме или включите иерархию в конфигураторе для нового справочника
- 5Заведите несколько тестовых элементов и проверьте отображение в форме списка и в отчётах
- 6Перенесите остальные данные и настройте права доступа к группам при необходимости
Типичные ошибки и их последствия
Самая распространённая ошибка — создание дублей групп с похожими названиями: «Товары», «Товар», «ТОВАРЫ». Со временем элементы расползаются по всем трём веткам, и отчёты по группам перестают сходиться. Профилактика проста: назначьте ответственного за структуру справочника и ограничьте право создания групп верхнего уровня.
Вторая ошибка — использование иерархии там, где нужен реквизит. Если признак элемента может меняться (например, «акционный товар» или «менеджер по контрагенту»), делать из него группу нельзя: при смене признака придётся перемещать элементы, а история в отчётах по группам исказится. Изменяемые признаки храните в реквизитах, иерархию оставьте для стабильной классификации.
Третья ошибка — удаление групп с вложенными элементами без проверки. В зависимости от настроек конфигурации элементы могут остаться без родителя или пометка на удаление заблокируется ссылками из документов. Перед удалением группы сначала переместите элементы в другую ветку.
Как проверить, что структура работает правильно
После настройки проверьте три вещи. Во-первых, форму списка: дерево групп должно отображаться, разворачиваться без ошибок, а элементы — попадать в свои группы при фильтрации. Во-вторых, отчёты: постройте типовой отчёт с группировкой по справочнику и убедитесь, что итоги по группам сходятся с суммой по элементам. В-третьих, ввод новых элементов: проверьте, что пользователь может выбрать только элемент, а не группу, там, где это требуется по логике учёта.
Полезный приём — периодический аудит структуры. Раз в квартал проверяйте: нет ли элементов в корне, которым положена группа; нет ли пустых групп-дублей; не выросла ли какая-то ветка до неуправляемых размеров. В типовых конфигурациях для поиска дублей есть штатные обработки, а список элементов без родителя виден прямо в форме списка при отключённом отборе по группе.
Контрольные точки после настройки
Дерево групп отображается, элементы открываются из своих групп
Элементы валяются в корне, дерево пустое или не разворачивается
Сумма итогов по группам равна общему итогу
Часть данных выпадает из группировки или дублируется
Доступны только элементы, группы не выбираются (для иерархии групп)
В документ можно подставить группу вместо элемента
Нет дублей, пустых и одноэлементных веток
Несколько групп с одинаковым смыслом, ветки по одной позиции
Ограничения и когда иерархия не нужна
Иерархия не бесплатна: каждый запрос с учётом родителя добавляет соединения в SQL-запросах, а глубокие деревья замедляют открытие форм списка. Для справочников с несколькими десятками элементов (валюты, единицы измерения, причины отказов) иерархия не даёт ничего, кроме лишнего клика при выборе.
Также помните, что один элемент может иметь только одного родителя. Если товар логично относится к двум категориям одновременно («Подарки» и «Электроника»), иерархия эту задачу не решит — нужны дополнительные реквизиты, категории или свойства. Попытка эмулировать множественную принадлежность через дубли элементов приводит к раздвоению учёта остатков.
Как выбрать действие
FAQ: частые вопросы об иерархических справочниках
Можно ли изменить вид иерархии у уже заполненного справочника?
Технически да, в конфигураторе вид иерархии переключается, но на практике это рискованная операция. При смене с «иерархии элементов» на «иерархию групп» элементы, у которых родителем был другой элемент, потребуют ручного перераспределения. Перед изменением сделайте резервную копию и проверьте результат на тестовой базе.
Что будет с документами, если переместить элемент в другую группу?
Сами документы не изменятся — в них хранится ссылка на элемент, а не на группу. Но отчёты с группировкой по иерархии покажут этот элемент уже в новой ветке, включая прошлые периоды. Если историческая отчётность должна остаться неизменной, перемещения нужно планировать и фиксировать.
Как найти элементы, которые не попали ни в одну группу?
Откройте форму списка справочника и отключите отбор по группе или перейдите в корень дерева — элементы с пустым родителем отобразятся на верхнем уровне. В некоторых конфигурациях есть штатные обработки поиска дублей и «потерянных» элементов в разделе администрирования.
Влияет ли глубина иерархии на скорость работы?
Да, умеренно. Каждый запрос с учётом иерархии («элемент и все его потомки») требует рекурсивного обхода, и при глубине более пяти-семи уровней на больших объёмах это заметно в отчётах и при открытии форм. Держите дерево в пределах трёх-пяти уровней — этого достаточно для подавляющего большинства классификаций.
Можно ли разграничить права по группам справочника?
Да, механизм RLS (ограничение доступа на уровне записей) позволяет настроить доступ по группам: например, менеджер видит и редактирует только свою ветку номенклатуры. Настройка выполняется в ролях конфигурации или через профили групп доступа в типовых решениях, где такой механизм предусмотрен.
Чем иерархия отличается от подчинённого справочника?
Иерархия — это связь элемента с родителем внутри одного справочника. Подчинённый справочник — отдельный объект, каждый элемент которого принадлежит владельцу из другого справочника (например, «Договоры» подчинены «Контрагентам»). Это разные механизмы, и они часто применяются вместе.
Что важно запомнить
Иерархические справочники структурируют большие объёмы данных, дают корректную группировку в отчётах и упрощают навигацию. Выбирайте иерархию групп для классификации, иерархию элементов — для объектов с подчинением. Проектируйте дерево до загрузки данных, ограничивайте глубину тремя-пятью уровнями и не используйте группы для изменяемых признаков.