Подчиненные справочники в 1С: зачем нужны и что такое владелец

Подчиненный справочник — это справочник, каждый элемент которого жестко привязан к элементу другого справочника, называемого владельцем. Классический пример: справочник «Договоры контрагентов» подчинен справочнику «Контрагенты» — у каждого договора есть конкретный контрагент, и договор вне контрагента не существует. Такая структура встроена в платформу 1С и используется почти в каждой типовой конфигурации.

Понимание механизма владельца важно и пользователю, и разработчику. Пользователю — чтобы правильно вводить данные и находить их в интерфейсе. Разработчику — чтобы проектировать структуру метаданных, писать запросы и настраивать отборы без дублирования информации. Ошибки на этом уровне приводят к «висячим» элементам, дублям и запутанным отчетам.

В статье разберем, что такое владелец на уровне платформы, когда подчинение оправдано, а когда лучше использовать обычный реквизит-ссылку, как настроить и проверить подчиненный справочник, и какие ошибки встречаются чаще всего.

Что такое владелец справочника на уровне платформы

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

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

В коде доступ к владельцу выглядит просто:

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

Зачем нужны подчиненные справочники: практические задачи

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

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

Третья задача — упрощение отборов и отчетов. Отбор по владельцу — стандартная операция: получить все счета организации, все договоры контрагента, все единицы измерения товара. В динамических списках и СКД связь через владельца работает быстрее и прозрачнее, чем соединение через дополнительные реквизиты.

Подчиненный справочник или реквизит-ссылка: как выбрать

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

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

Отдельный случай — когда «подчиненные» данные должны ссылаться из документов. Например, договор выбирается в реализации. Здесь табличная часть не подойдет: на строку табличной части нельзя сделать ссылку. Нужен именно подчиненный справочник или самостоятельный справочник с реквизитом-ссылкой.

Как настроить подчиненный справочник в конфигураторе

Настройка выполняется в конфигураторе и занимает несколько минут. Важно продумать структуру заранее: изменение подчинения в рабочей базе с данными потребует обработки существующих элементов.

1. 1
   Откройте конфигуратор и найдите справочник, который должен стать подчиненным (например, «ДоговорыКонтрагентов»).
2. 2
   В свойствах справочника перейдите на закладку «Владельцы» и отметьте справочник-владелец (например, «Контрагенты»).
3. 3
   На закладке «Данные» проверьте, что реквизит «Владелец» появился автоматически — вручную его добавлять не нужно.
4. 4
   Настройте формы: в форме элемента владельца добавьте динамический список подчиненного справочника с отбором по владельцу (связь параметров отбора).
5. 5
   Обновите конфигурацию базы данных и проверьте создание нового элемента из карточки владельца.

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

Работа с подчиненными справочниками в пользовательском режиме

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

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

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

Типичные ошибки и риски

Самая распространенная ошибка — попытка удалить владельца, у которого есть подчиненные элементы. При включенном контроле ссылочной целостности платформа запретит удаление, но при пометке на удаление без контроля (например, через обработку) подчиненные элементы получат «битые» ссылки — объекты вида «Объект не найден».

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

Ограничения и альтернативы

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

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

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