При работе с Системой компоновки данных (СКД) разработчики часто сталкиваются с ситуацией, когда связь двух наборов данных (например, «Запрос1» и «Запрос2») по логике должна работать как Левое соединение, но на практике ведет себя как Внутреннее. В результате, если во втором наборе данных нет соответствующей записи для первого, вся строка из итогового отчета исчезает. Разберем подробно, почему так происходит и как добиться корректного вывода данных.
Проанализируем самую распространенную ситуацию. В СКД механизм компоновки запросов работает динамически. Если вы связали два набора данных и установили отбор по полю, которое принадлежит второму набору (приемнику), система применит этот фильтр ко всему результату. Рассмотрим пример:
Если в пользовательских настройках или в схеме наложить отбор Склад = "Основной", то СКД исключит все записи, где Склад равен NULL (то есть те товары, по которым нет остатков). Визуально это выглядит как Inner Join. Чтобы избежать этого, отборы по полям второго набора следует использовать с осторожностью или проверять их на наличие пустых значений.
Выясним, как СКД передает данные между наборами. В отличие от обычного SQL-запроса, СКД сначала выполняет первый запрос, получает из него значения связывающих полей и передает их как параметры во второй запрос. Посмотрим на типичную ошибку в тексте второго запроса:
ВЫБРАТЬ
Продажи.Номенклатура,
Продажи.Количество
ИЗ
РегистрНакопления.Продажи КАК Продажи
ГДЕ
Продажи.Номенклатура = &НоменклатураСвязи
Если в настройках связи на закладке «Связи наборов данных» неверно указано соответствие в колонках «Параметр» и «Условие связи», или если второй запрос жестко фильтрует данные по этому параметру без учета возможности отсутствия данных, результат будет «обрезан» до внутреннего соединения. Важно убедиться, что второй запрос способен корректно обрабатывать передаваемые параметры.
В настройках связей наборов данных существует колонка «Обязательная связь». Разберем по шагам, на что она влияет. Если этот флаг установлен, СКД оптимизирует выполнение отчета, считая, что данные из второго набора критически важны. В некоторых случаях это заставляет систему игнорировать записи из первого набора, для которых не нашлось пары во втором. Проверьте этот флаг: для реализации классического «левого соединения» он, как правило, должен быть снят.
Проанализируем структуру настроек на закладке «Настройки». Если в иерархии группировок или в выбранных полях детальных записей присутствуют только поля из второго набора данных, СКД может не выводить строки первого набора, так как для них значения во втором наборе будут NULL, и системе «нечего показывать» согласно текущим настройкам. Чтобы увидеть все данные первого набора, обязательно добавьте хотя бы одно поле из него (например, Наименование или Код) в состав выбранных полей или в группировку.
Иногда связь не срабатывает из-за неявного несовпадения типов или некорректных выражений. Рассмотрим использование функций в колонках «Выражение источник» и «Выражение приемник». Если вы связываете поля разных типов (например, число и строку), связь не будет установлена, и данные не сопоставятся. Для решения проблемы можно использовать функции приведения типов или обработку пустых значений:
Пример выражения в связи:
ЕСТЬNULL(НоменклатураПриемник, ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка))
Как показывает практика (и случай автора темы), иногда проблема кроется не в логике настроек, а в техническом состоянии платформы. При частой разработке через дополнительные отчеты и обработки кэш 1С может сохранять старые варианты схемы или некорректные временные данные. Попробуем выполнить следующие действия:
%AppData%\1C\1cv8).Если отчет, запущенный через внешнюю обработку, продолжает выдавать неверный результат, попробуйте изменить имя файла или пересоздать схему в новом отчете. Это исключит влияние старых настроек, сохраненных в базе данных для этого конкретного идентификатора объекта.
Для реализации честного Левого соединения в СКД необходимо:
ГДЕ настроены через механизм связей СКД, а не жестко.