Как реализовать сквозную иерархию в подчиненном справочнике 1С?

При разработке и доработке конфигураций 1С часто возникает задача сгруппировать элементы подчиненного справочника (например, ДоговорыКонтрагентов или ДоговорыВзаиморасчетов) не по конкретным владельцам, а по общим сквозным признакам: территориям, типам взаиморасчетов, ответственным менеджерам или регионам. Рассмотрим, можно ли создать группы без владельца в подчиненном справочнике и как правильно решить задачу классификации данных.

Ограничения платформы 1С при работе с подчиненными справочниками

Проанализируем базовые правила и системные механизмы платформы 1С:Предприятие при работе с подчиненными справочниками:

1. Обязательность реквизита «Владелец»: для всех типов записей подчиненного справочника — как для элементов, так и для групп (если включена иерархия групп и элементов) — системное поле Владелец является строго обязательным. Создать группу с пустым владельцем в рамках стандартной логики невозможно.
2. Связь владельца и родителя: на уровне платформы жестко контролируется условие целостности Элемент.Владелец = Элемент.Родитель.Владелец. Нельзя переместить договор контрагента «А» в группу, принадлежащую контрагенту «Б» или группе контрагентов. При попытке программного или интерактивного назначения родителем группы другого владельца платформа выдает ошибку несовпадения владельцев либо ошибку «Зацикливание ссылок».
3. Иерархия внутри владельца: стандартный иерархический просмотр подчиненного справочника предназначен исключительно для внутренней структуры конкретного владельца, а не для сквозной классификации всех записей базы данных.

Вариант 1. Использование отдельного справочника-классификатора

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

Выполним следующие шаги:

1. Создадим отдельный независимый справочник с иерархией групп и элементов (например, Регионы, Территории или КатегорииДоговоров).
2. В подчиненный справочник добавим новый реквизит со ссылкой на созданный справочник-классификатор.
3. Если классифицирующий признак уже присутствует у владельца (например, территория указана в карточке контрагента), используем этот реквизит напрямую без дублирования информации в договорах.

Вариант 2. Построение произвольного дерева на форме списка через ДеревоЗначений

В обычном приложении для отображения договоров в виде единой сквозной структуры без отбора по конкретному владельцу можно использовать элемент управления ТабличноеПоле с типом данных ДеревоЗначений.

Посмотрим на пример заполнения дерева с группировкой по территориям и контрагентам с помощью запроса:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Договоры.Владелец КАК Контрагент,
    |	Договоры.Владелец.Территория КАК Территория,
    |	Договоры.Ссылка КАК Договор,
    |	Договоры.НомерДоговора КАК Номер,
    |	Договоры.Дата КАК Дата
    |ИЗ
    |	Справочник.ДоговорыКонтрагентов КАК Договоры
    |ИТОГИ ПО
    |	Территория,
    |	Контрагент";

РезультатЗапроса = Запрос.Выполнить();
ДеревоДоговоров = РезультатЗапроса.Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкам);
ЭлементыФормы.ТабличноеПолеДерево.Значение = ДеревоДоговоров;
ЭлементыФормы.ТабличноеПолеДерево.СоздатьКолонки();

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

Вариант 3. Использование отчета или формы на базе СКД

Если пользователям требуется регулярно анализировать договоры в различных разрезах без фиксированной структуры, оптимальным вариантом будет создание формы отчета на базе Системы компоновки данных (СКД).

Преимущества данного подхода:

1. Пользователь может самостоятельно перетаскивать группировки (территория, организация, вид расчетов, куратор) в настройках отчета без изменения конфигурации.
2. Обеспечивается расшифровка строк с переходом к реальным объектам конфигурации.
3. Сохраняется производительность при работе с большими объемами данных.