Почему в 1С структура подчиненности документов строится не по времени и как исправить иерархию

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

Рассмотрим подробно механику работы платформы 1С при построении дерева подчиненности, выясним причины такого поведения и разберем варианты решения этой задачи.

Принцип формирования дерева подчиненности в 1С

Проанализируем, как платформа 1С строила и строит иерархию связанных документов. Главное правило, которое необходимо учитывать: время и дата создания документов абсолютно не влияют на их положение в дереве подчиненности. Иерархия выстраивается строго по направлениям ссылочных связей между объектами.

Построение дерева подчиненности выполняется платформой в два основных этапа:

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

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

Диагностика неочевидных связей

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

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

Проверить наличие ссылок во всех реквизитах и табличных частях можно с помощью обходного запроса по метаданным:

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

Запрос.УстановитьПараметр("ТекущийДокумент", СсылкаНаСчетПоставщика);
Результат = Запрос.Выполнить();

Способы сохранения технической связи без нарушения подчиненности

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

1. Хранение связи в виде строкового GUID

Вместо типа ДокументСсылка задайте для технического реквизита тип Строка (длиной 36 символов). В этот реквизит записывается уникальный идентификатор ссылочного объекта. Платформа не анализирует текстовые поля при формировании иерархии документов.

Пример записи и считывания ссылки через УникальныйИдентификатор():

// Запись технической ссылки в виде строки
СчетПокупателяОбъект.ТехническийРеквизитGUID = Строка(СчетПоставщикаСсылка.УникальныйИдентификатор());
СчетПокупателяОбъект.Записать();

// Восстановление ссылки из строки для проверки
ЗначениеGUID = Новый УникальныйИдентификатор(СчетПокупателяОбъект.ТехническийРеквизитGUID);
ИскомыйСчетПоставщика = Документы.СчетНаОплатуПоставщика.ПолучитьСсылку(ЗначениеGUID);

2. Использование независимого регистра сведений

Создайте независимый регистр сведений (например, ТехническиеСвязиДокументов) с измерениями ДокументОснование и СвязанныйДокумент с типом ДокументСсылка. Запись связей в отдельный регистр позволяет выполнять быстрые проверки запросом и при этом полностью изолирует данные от типового отчета подчиненности.

3. Исключение реквизита из состава критерия отбора

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