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