Как вывести дополнительные реквизиты в корень списка полей СКД

← На главную

При разработке отчетов на базе Системы компоновки данных (СКД) в 1С часто возникает задача вывода дополнительных реквизитов и сведений. Механизм дополнительных реквизитов активно используется в типовых конфигурациях (таких как УТ 11, ERP, КА, УНФ) и позволяет пользователям динамически расширять состав свойств объектов без изменения конфигурации.

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

Часть 1. Анализ и исправление ошибки в описании характеристик СКД

Рассмотрим ситуацию, с которой столкнулся автор темы. Он попытался описать характеристики через специализированное расширение языка запросов {ХАРАКТЕРИСТИКИ}, но столкнулся с тем, что поля характеристик вообще не появились в компоновщике. Давайте выясним причину этой проблемы.

Посмотрим на исходный запрос, который написал разработчик:


ВЫБРАТЬ
    КартыЛояльности.Ссылка КАК Ссылка,
    КартыЛояльности.Наименование КАК Наименование,
    КартыЛояльности.Штрихкод КАК Штрихкод,
    КартыЛояльности.Статус КАК Статус
ИЗ
    Справочник.КартыЛояльности КАК КартыЛояльности
{ХАРАКТЕРИСТИКИ
    ТИП(Справочник.КартыЛояльности)
    ВИДЫХАРАКТЕРИСТИК ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения
    ПОЛЕКЛЮЧА Ссылка
    ПОЛЕИМЕНИ Представление
    ПОЛЕТИПАЗНАЧЕНИЯ ТипЗначения
    ЗНАЧЕНИЯХАРАКТЕРИСТИК (ВЫБРАТЬ
            КартыЛояльностиДополнительныеРеквизиты.Свойство КАК Свойство,
            КартыЛояльностиДополнительныеРеквизиты.Значение КАК Значение,
            КартыЛояльностиДополнительныеРеквизиты.Ссылка КАК Ссылка
        ИЗ
            Справочник.КартыЛояльности.ДополнительныеРеквизиты КАК КартыЛояльностиДополнительныеРеквизиты)
    ПОЛЕОБЪЕКТА Свойство
    ПОЛЕВИДА Свойство
    ПОЛЕЗНАЧЕНИЯ Значение }

Проанализируем параметры связи характеристик в этом коде. Обратите внимание на строки:

ПОЛЕОБЪЕКТА Свойство
ПОЛЕВИДА Свойство

В этом кроется критическая ошибка. Давайте разберем назначение этих параметров:

ПОЛЕОБЪЕКТА — указывает на поле в запросе значений характеристик, которое связывает значение с конкретным элементом-владельцем (в нашем случае — это ссылка на элемент справочника КартыЛояльности). В табличной части дополнительных реквизитов это поле всегда называется Ссылка.
ПОЛЕВИДА — указывает на конкретное свойство из плана видов характеристик (ПВХ). В табличной части это поле называется Свойство.
ПОЛЕЗНАЧЕНИЯ — указывает на само значение свойства. В табличной части это поле называется Значение.

В коде автора параметр ПОЛЕОБЪЕКТА ошибочно ссылался на поле Свойство. Из-за этого платформа пыталась сопоставить владельца характеристики со значением самого свойства ПВХ, связь нарушалась, и СКД не отображала характеристики.

Для исправления этой ошибки нам необходимо заменить значение параметра ПОЛЕОБЪЕКТА на Ссылка. Правильный вариант описания характеристик в запросе СКД выглядит следующим образом:


{ХАРАКТЕРИСТИКИ
    ТИП(Справочник.КартыЛояльности)
    ВИДЫХАРАКТЕРИСТИК ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения
    ПОЛЕКЛЮЧА Ссылка
    ПОЛЕИМЕНИ Представление
    ПОЛЕТИПАЗНАЧЕНИЯ ТипЗначения
    ЗНАЧЕНИЯХАРАКТЕРИСТИК (ВЫБРАТЬ
            КартыЛояльностиДополнительныеРеквизиты.Свойство КАК Свойство,
            КартыЛояльностиДополнительныеРеквизиты.Значение КАК Значение,
            КартыЛояльностиДополнительныеРеквизиты.Ссылка КАК Ссылка
        ИЗ
            Справочник.КартыЛояльности.ДополнительныеРеквизиты КАК КартыЛояльностиДополнительныеРеквизиты)
    ПОЛЕОБЪЕКТА Ссылка   // Исправлено со "Свойство" на "Ссылка"
    ПОЛЕВИДА Свойство
    ПОЛЕЗНАЧЕНИЯ Значение }

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

Часть 2. Способы вывода дополнительных реквизитов в корень списка полей

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

Способ 1. Использование механизма «Вычисляемых полей» СКД

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

Давайте выполним настройку по шагам:

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

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

Способ 2. Левое соединение в тексте запроса (Статический метод)

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

Рассмотрим пример реализации такого запроса:


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

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

Преимущества метода:

Высокая производительность за счет явного левого соединения в СУБД.
Поля изначально находятся в корне без дополнительных настроек СКД.

Недостатки метода:

Потеря динамичности. Если пользователи создадут новые дополнительные реквизиты в режиме «1С:Предприятие», они не появятся в отчете автоматически — потребуется изменять запрос.

Способ 3. Изменение настроек расположения реквизитов на уровне вывода отчета

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

Разберем, как это настроить в пользовательском режиме или в конфигураторе:

Перейдите на вкладку «Настройки» в СКД, затем откройте вкладку «Другие настройки» (в самом низу окна настроек).
Найдите параметр «Расположение реквизитов» (в англоязычной версии — Placement of attributes).
Установите значение этого параметра в положение «Отдельно» (Separately).

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

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

← На главную