Какие варианты подчинения существуют в 1С:Предприятие 8

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

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

Ниже разобраны все основные варианты подчинения, доступные в платформе 1С:Предприятие 8.3: иерархия, подчинённые справочники, связи документов через реквизиты и критерии отбора, ввод на основании, а также программные способы установки связей. Для каждого варианта приведены условия применения, ограничения и типичные ошибки.

Иерархическое подчинение: родитель и группа

Самый простой вид подчинения — иерархия внутри одного справочника. Она включается свойством «Вид иерархии» в палитре свойств объекта: «Список» (без иерархии), «Иерархия групп и элементов» или «Иерархия элементов». У каждого элемента появляется системный реквизит Родитель, ссылающийся на группу или другой элемент того же справочника.

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

Проверить принадлежность элемента группе в запросе можно оператором В ИЕРАРХИИ(&Группа), а в коде — методом ПринадлежитЭлементу() или рекурсивным обходом родителей. Учтите ограничение: платформа не допускает зацикливания иерархии (элемент не может быть родителем самого себя), но глубокая вложенность замедляет обход и усложняет отчёты.

Подчинённые справочники: связь «владелец — элемент»

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

Типичные примеры из типовых конфигураций: «Единицы измерения» подчинены «Номенклатуре», «Договоры контрагентов» подчинены «Контрагентам», «Банковские счета» подчинены «Организациям». Элемент подчинённого справочника не имеет смысла без владельца — договор не существует вне контрагента.

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

Ключевые особенности поведения: при копировании владельца подчинённые элементы не копируются автоматически; при пометке владельца на удаление подчинённые элементы не помечаются сами — это делает обработка «Удаление помеченных объектов» или специальный код. В запросах отбор по владельцу выполняется простым условием ГДЕ Владелец = &Владелец.

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

Связь через реквизиты-ссылки и критерии отбора

Не всякая связь «главный — подчинённый» требует механизма владельцев. Часто достаточно обычного реквизита типа «ссылка»: например, в документе «Реализация товаров и услуг» реквизиты «Организация», «Контрагент», «Договор» — это ссылки, а не подчинение в понимании платформы.

Чтобы связанные объекты было удобно просматривать, используются критерии отбора. Критерий отбора объединяет объекты по общему реквизиту: например, критерий «Связанные документы» показывает все документы, где в реквизитах встречается конкретный контрагент или основание. В форме объекта появляется панель навигации по связанным объектам.

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

Ввод на основании и структура подчинённости документов

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

Настройка выполняется на закладке «Ввод на основании» в свойствах документа: указывается, на основании каких объектов документ вводится и какие объекты можно вводить на его основании. Для автозаполнения полей создаётся процедура ОбработкаЗаполнения в модуле объекта, где по данным основания заполняются реквизиты нового документа.

Процедура ОбработкаЗаполнения(ДанныеЗаполнения, СтандартнаяОбработка)
	Если ТипЗнч(ДанныеЗаполнения) = Тип("ДокументСсылка.ЗаказПокупателя") Тогда
		Контрагент = ДанныеЗаполнения.Контрагент;
		Договор = ДанныеЗаполнения.Договор;
		ДокументОснование = ДанныеЗаполнения.Ссылка;
	КонецЕсли;
КонецПроцедуры

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

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

Подчинение в планах счетов, планах видов характеристик и регистрах

Механизм владельцев работает не только для справочников. Планы счетов поддерживают субсчета — фактически иерархию: счёт 10.01 подчинён счёту 10. Признак «Забалансовый» и иерархия счетов влияют на построение оборотно-сальдовой ведомости.

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

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

Программная работа с подчинёнными объектами

Во встроенном языке подчинённость читается через системные реквизиты: Элемент.Владелец, Элемент.Родитель. Выборка подчинённых элементов выполняется методами Справочники.ИмяСправочника.Выбрать(, Владелец) или запросом с отбором по владельцу.

Для проверки связей документов удобнее запросы: выбрать все документы, у которых реквизит основания равен заданной ссылке. При больших объёмах данных убедитесь, что реквизит основания проиндексирован (свойство «Индексировать»), иначе поиск связанных документов будет выполняться полным сканированием таблицы.

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

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

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

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

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