При разработке в среде 1С:Предприятие 8.3 программисты часто сталкиваются с необходимостью программно получить дерево связей документов. Стандартным механизмом для этого является использование объекта метаданных КритерийОтбора. Однако нередко возникает ситуация: в интерфейсе программы (например, в «Бухгалтерии предприятия 3.0») структура подчиненности видна, а запрос к критерию отбора СвязанныеДокументы возвращает пустой результат. Давайте разберем по шагам, почему так происходит и как эффективно решать задачи поиска взаимосвязанных объектов.
Для начала рассмотрим типичный пример запроса, который может не выдавать ожидаемых данных. Предположим, мы хотим найти документ СписаниеСРасчетногоСчета, который связан с конкретным ПлатежнымПоручением.
ВЫБРАТЬ
СвязанныеДокументы.Ссылка КАК Ссылка,
&Значение КАК ИсходныйДокумент
ИЗ
КритерийОтбора.СвязанныеДокументы(&Значение) КАК СвязанныеДокументы
ГДЕ
ТипЗначения(СвязанныеДокументы.Ссылка) = ТИП(Документ.СписаниеСРасчетногоСчета)
На первый взгляд запрос выглядит корректно, но именно в нем заложены причины потенциальных проблем, связанных как с логикой работы платформы, так и с производительностью.
Основная причина, по которой запрос возвращает пустой результат, кроется в фундаментальном принципе работы критерия отбора. Проанализируем ситуацию: критерий отбора всегда ищет входящие ссылки. Это означает, что он находит только те объекты, которые «знают» о переданном в параметре документе.
Рассмотрим механизм взаимодействия на примере:
Платежное поручение).Списание с расчетного счета).ДокументОснование, в котором записана ссылка на документ «А».Если мы передадим в критерий отбора ссылку на документ «А», система просканирует все таблицы, входящие в состав критерия, и найдет документ «Б», так как он содержит ссылку на «А». Однако если мы передадим в параметр документ «Б», критерий отбора не вернет документ «А», потому что документ «А» ничего не знает о своем «потомке».
Вывод: Критерий отбора работает эффективно только для поиска подчиненных документов («вниз» по структуре). Если ваша задача — найти документ-основание (родителя), использование критерия отбора технически неверно.
Если направление поиска выбрано правильно, но данных всё равно нет, выясним причину в метаданных. Откроем конфигуратор и проанализируем настройки критерия СвязанныеДокументы:
Проанализируем ситуацию: если вы добавили в расширение или в основную конфигурацию новый документ или новый реквизит связи, но не отметили его «галочкой» в составе критерия отбора СвязанныеДокументы, платформа просто проигнорирует эти данные при выполнении запроса. Убедитесь, что реквизит ДокументОснование (или аналогичный) вашего целевого документа включен в этот состав.
В исходном коде использовалась конструкция ТипЗначения(СвязанныеДокументы.Ссылка) = ТИП(Документ.СписаниеСРасчетногоСчета). С точки зрения производительности это не самый лучший вариант. Рассмотрим, как оптимизировать этот участок кода.
При использовании ТипЗначения СУБД вынуждена вычислять тип для каждой найденной строки. Гораздо правильнее использовать оператор ССЫЛКА. Проанализируем исправленный вариант:
ВЫБРАТЬ
СвязанныеДокументы.Ссылка КАК Ссылка
ИЗ
КритерийОтбора.СвязанныеДокументы(&Значение) КАК СвязанныеДокументы
ГДЕ
СвязанныеДокументы.Ссылка ССЫЛКА Документ.СписаниеСРасчетногоСчета
Оператор ССЫЛКА работает на уровне метаданных и позволяет оптимизатору запросов сразу ограничить поиск нужной таблицей, что значительно ускоряет выполнение, особенно в крупных базах данных.
Как мы уже выяснили, критерии отбора могут быть медленными, так как платформа генерирует огромный UNION ALL по всем таблицам, входящим в состав критерия. Если структура связей вам заранее известна, мы рекомендуем отказаться от критерия отбора в пользу прямого запроса.
Пример поиска подчиненного документа:
ВЫБРАТЬ
Списание.Ссылка
ИЗ
Документ.СписаниеСРасчетногоСчета КАК Списание
ГДЕ
Списание.ДокументОснование = &Платежка
Пример поиска документа-основания:
ВЫБРАТЬ
Списание.ДокументОснование
ИЗ
Документ.СписаниеСРасчетногоСчета КАК Списание
ГДЕ
Списание.Ссылка = &ТекущееСписание
Такой подход всегда будет работать быстрее и предсказуемее, так как обращение идет к конкретной таблице по индексированному полю.
Важно понимать разницу между механизмом платформы и типовыми решениями (БП 3.0, ERP). Визуальное дерево «Структура подчиненности» часто строится программно с использованием функций Библиотеки стандартных подсистем (БСП).
Проанализируем, как это работает: программный код может собирать данные не только из критериев отбора, но и из специальных регистров сведений (например, СвязиДокументов) или путем прямого перебора реквизитов, которые не включены в критерий отбора. Поэтому отсутствие данных в критерии при их наличии на экране — это штатная ситуация, указывающая на то, что связь реализована иным способом.
Подводя итог нашему разбору, выделим ключевые правила работы со связанными документами:
ТипЗначения на оператор ССЫЛКА.