Часто в процессе разработки конфигураций на базе 1С:Предприятие возникает задача изменения визуального представления данных в справочнике. Пользователи просят добавить дополнительные уровни иерархии, чтобы удобнее группировать элементы списка. При этом возникает серьезная проблема: если мы поменяем физическую структуру справочника (например, переведем его в режим «Иерархия групп и элементов» и поменяем родителей), могут сломаться заложенные в системе алгоритмы, которые жестко опираются на текущее поле Родитель. Проанализируем ситуацию и разберем несколько безопасных способов создания визуальной иерархии на форме, не нарушая логику работы системы.
Самый простой и безопасный способ создать визуальную древовидную структуру без изменения данных — использовать встроенные возможности объекта ДинамическийСписок, который работает на базе Системы Компоновки Данных (СКД). Давайте посмотрим на этот механизм подробнее.
В настройках формы или непосредственно в пользовательском режиме (через меню «Еще» -> «Настроить список») на вкладке «Группировка» мы можем указать один или несколько реквизитов справочника. В результате список автоматически примет вид дерева, где в качестве узлов будут выступать значения этих реквизитов, а конечными листьями останутся сами элементы.
Плюсы данного подхода:
Родитель при этом никак не затрагивается, все старые алгоритмы поиска по родителю продолжают работать корректно.Особенности и ограничения: Глубокие многоуровневые группировки в динамическом списке могут замедлять отрисовку формы при больших объемах данных. Кроме того, в таком сгруппированном списке недоступен подсчет итогов по созданным узлам.
Как выяснили разработчики в ходе обсуждения данной проблемы, вывод сложных «многоэтажных» иерархий часто целесообразнее реализовывать не в рабочих формах списков, а в отдельных отчетах. Форма списка должна оставаться легковесной, так как ее основная задача — быстрый поиск и выбор элементов для подстановки в документы.
Рассмотрим, как мы можем решить задачу с помощью отчета:
Реквизит 1 -> Реквизит 2 -> Ссылка.В итоге пользователь получает идеальный инструмент для анализа структуры каталога, а физическая иерархия справочника остается в неприкосновенности.
Если пользователю все же необходимо полноценно работать со сложным деревом прямо в форме списка, разберем подход, который активно применяется в типовых конфигурациях (УТ, ERP, Комплексная автоматизация). Это так называемая «Альтернативная иерархия».
Как мы вместе можем реализовать это технически:
ВидыНоменклатуры или АльтернативныеГруппы), который будет содержать свою собственную независимую иерархию элементов или групп.При таком подходе мы даем пользователю удобную навигацию (слева дерево категорий, справа товары), не ломая при этом базовый реквизит Родитель у элементов справочника.
Если штатные возможности динамического списка вас не устраивают, мы можем пойти путем программного конструирования интерфейса. Для этого на форме размещается реквизит с типом ДеревоЗначений.
Разберем по шагам логику работы:
ДеревоЗначений, формируя любые «виртуальные» уровни иерархии, которые нам нужны.Важное предупреждение: Динамический список оптимизирован под работу с большими данными — он считывает из СУБД порциями только то, что видно на экране. А вот ДеревоЗначений генерируется и помещается в оперативную память сервера и клиента целиком. Если в вашем справочнике сотни тысяч элементов, попытка построить такое дерево приведет к длительному зависанию или ошибке нехватки памяти. Применяйте этот метод только для справочников с небольшим количеством записей.
В ходе поиска решения иногда всплывают «хакерские» методы. Один из них — смена типа справочника на «Иерархию групп и элементов» с последующей программной подменой GUID существующих элементов, превращающей их в группы. Выясним причину, почему этот метод крайне опасен для рабочей базы.
Если элемент справочника уже участвует в движениях регистров накопления или сведений, либо выбран в табличных частях проведенных документов, его принудительное превращение в группу (свойство ЭтоГруппа) нарушит ссылочную целостность и логику системы.
Во-первых, в большинстве типовых документов установлен строгий запрет на выбор групп в полях ввода. Документы перестанут открываться без ошибок или перепроводиться. Во-вторых, запросы разработчиков, которые используют конструкцию В ИЕРАРХИИ, начнут отрабатывать некорректно, так как они ожидают стандартное поведение иерархии платформы.
Итог: При решении задач визуализации всегда старайтесь использовать инструменты отображения (настройки Динамического списка, Систему Компоновки Данных, связанные списки), оставляя архитектуру хранения данных в первозданном виде.