Как в СКД получить связанные документы через критерии отбора?

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

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

Почему прямое соединение в одном запросе невозможно?

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

ВЫБРАТЬ
    Обороты.ДокументДвижения КАК ДокСсылка,
    Связанные.Ссылка КАК СвязанныйДокумент
ИЗ
    РегистрНакопления.Казначейство.Обороты КАК Обороты
ЛЕВОЕ СОЕДИНЕНИЕ 
    КритерийОтбора.СвязанныеДокументы(&СсылкаДок) КАК Связанные
ПО 
    Обороты.ДокументДвижения = &СсылкаДок

Проблема заключается в том, что параметр &СсылкаДок в СКД является глобальным для всего запроса. Вы не можете передать в него значение Обороты.ДокументДвижения для каждой строки отдельно в рамках одного SELECT. Платформа ожидает конкретное значение ссылки еще до начала выполнения запроса. Если же использовать критерий отбора без параметров, запрос просто не пройдет валидацию, так как критерий отбора «под капотом» представляет собой массивное объединение (UNION ALL) множества таблиц, и без фильтра по конкретной ссылке такая выборка не имеет смысла.

Решение проблемы через связь наборов данных

Для решения этой задачи мы воспользуемся механизмом связи наборов данных СКД. Этот метод позволяет выполнить первый запрос, получить список документов, а затем для каждого документа из результата выполнить второй запрос, передавая ссылку в качестве параметра. Проанализируем пошаговый алгоритм настройки.

Шаг 1. Создание основного набора данных (НаборДанных1)

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

ВЫБРАТЬ
    КазначействоОбороты.ДокументДвижения КАК ДокументСсылка,
    КазначействоОбороты.СуммаОборот КАК Сумма
ИЗ
    РегистрНакопления.КазначействоДвиженияДенежныхСредств.Обороты КАК КазначействоОбороты

Шаг 2. Создание вспомогательного набора данных (НаборДанных2)

Добавим второй набор данных типа «Запрос». В нем мы будем обращаться исключительно к критерию отбора. Обратите внимание на использование параметра:

ВЫБРАТЬ
    СвязанныеДокументы.Ссылка КАК СвязанныйОбъект
ИЗ
    КритерийОтбора.СвязанныеДокументы(&ПарДок) КАК СвязанныеДокументы

Здесь &ПарДок — это произвольное имя параметра, которое мы будем использовать для связи.

Шаг 3. Настройка связи между наборами

Это самый важный этап. Перейдем на закладку «Связи наборов данных» и добавим новую строку:

1. Источник связи: НаборДанных1.
2. Приемник связи: НаборДанных2.
3. Условие связи: ДокументСсылка (поле из первого набора).
4. Параметры: в колонке параметров выберем наш параметр ПарДок.

Теперь для каждой строки НабораДанных1 система будет автоматически подставлять значение поля ДокументСсылка в параметр &ПарДок второго запроса и присоединять результат.

Оптимизация производительности: использование списков параметров

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

Если установить флаг в этой колонке, СКД попытается передать в подчиненный набор данных не одну ссылку, а массив ссылок. В этом случае во втором наборе данных запрос должен поддерживать работу с массивом (условие В (&ПарДок)). Однако стоит помнить, что виртуальные таблицы критериев отбора часто имеют внутренние ограничения на работу с массивами параметров, поэтому классический метод «один запрос на одну строку» является более универсальным, хоть и более медленным.

Почему иногда теряются связи при обычном соединении?

Рассмотрим ситуацию, когда разработчики пытаются избежать критериев отбора и соединяют таблицы по реквизиту ДокументОснование. Выясним причину, почему такой подход часто выдает неполные данные (теряет до 20% связей):

• Табличные части: Связь между документами может храниться не в шапке (реквизит ДокументОснование), а в строках табличных частей (например, реквизит Заказ или Сделка).
• Разные типы реквизитов: В типовых конфигурациях связь может осуществляться через специализированные поля, такие как ОбъектРасчетов или ДокументОплаты.
• Произвольные типы: Критерий отбора агрегирует все ссылки, включая те, что находятся в реквизитах с типом ЛюбаяСсылка.

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

Нюансы работы с направлением связи

Проанализируем еще один важный технический момент. Критерии отбора в 1С работают эффективно только в направлении «от родителя к потомку». То есть, передав в критерий ссылку на «Заказ клиента», вы получите все «Реализации», созданные на его основании. Если же вам нужно решить обратную задачу — найти для «Реализации» её «Заказ» (родителя), то использовать критерий отбора неэффективно. В этом случае правильнее просто обратиться к реквизиту ДокументОснование самого документа в первом наборе данных.

Таким образом, использование связей наборов данных в СКД для работы с критериями отбора является «золотым стандартом» при построении сложных отчетов по структуре подчиненности, позволяя сохранять гибкость настроек и полноту данных.