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

← На главную

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

Механизм коллизии пространств имен в СКД

В системе компоновки данных синтаксис обращения через точку в поле Путь к данным решает сразу две принципиально разные задачи:

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

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

Если у самого документа в метаданных конфигурации уже существует собственный реквизит с именем Статус, возникает конфликт приоритетов. Процессор компоновки данных отдает безусловный приоритет разыменованию метаданных ссылки. Вместо того чтобы подтянуть значение из второго набора по настроенной связи, платформа формирует неявное левое соединение к таблице документа и пытается прочитать значение физического реквизита Статус.

Если данный реквизит в документе исторически не заполняется, устарел или статус хранится в периодическом регистре, колонка в сформированном отчете остается пустой. Как только мы меняем путь к данным на Заказ.Статус1, платформа проверяет состав реквизитов документа, не находит там реквизита с таким именем, отключает разыменование ссылки и корректно читает данные из связанного набора данных.

Почему одинаковый отчет может по-разному работать в разных базах

Нередко разработчики замечают, что типовой или перенесенный отчет в тестовой базе работает корректно, а в рабочей — возвращает пустые колонки. Рассмотрим ключевые факторы такого поведения:

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

Варианты исправления проблемы

Рассмотрим по шагам основные способы решения проблемы в зависимости от ограничений конфигурации.

Способ 1. Использование уникального пути к данным с сохранением пользовательского заголовка

Это самый быстрый и надежный способ устранения коллизии без переработки структуры запросов:

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

В результате пользователь в режиме предприятия продолжит видеть поле Статус внутри группы Заказ, но платформа перестанет пытаться прочитать реквизит документа напрямую.

Способ 2. Вынос поля в отдельную группу

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

Вместо пути Заказ.Статус укажем путь вида СостояниеДокумента.Статус.
В дереве доступных полей СКД сформирует отдельную независимую папку, которая не имеет ссылочной природы и не вступает в конфликт с метаданными.

Способ 3. Переход на объединение наборов данных или соединение в запросе

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


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

Такой подход полностью снимает проблему коллизии наборов и значительно ускоряет формирование отчета.

Способ 4. Ограничение доступности реквизитов ссылки в первом наборе

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

В первом наборе данных выберем строку поля Заказ.
В свойствах поля найдем колонку Ограничение доступности полей-реквизитов.
Отметим флажком реквизит Статус, запретив платформе использовать его для разыменования.

Возможность исправления на уровне пользователя

Если конфигурация находится на полной поддержке без возможности внесения изменений в конфигураторе, исправить структуру путей через форму пользовательских настроек в режиме 1С:Предприятие невозможно, так как путь к данным зашит в XML-структуре схемы отчета. В этом случае правильным обходным решением будет сохранение схемы во внешний отчет, внесение корректировок в путь к данным и подключение отчета через механизм Дополнительные отчеты и обработки.