При разработке отчетов на базе Системы компоновки данных (СКД) программисты часто сталкиваются с задачей вывода дополнительных реквизитов, а иногда и динамического добавления полей и ресурсов в структуру отчета. Эти реквизиты не являются жестко заданными полями в структуре справочника, а хранятся в табличных частях (для дополнительных реквизитов) или в регистрах сведений (для дополнительных сведений). Платформа 1С предоставляет удобный механизм для их отображения через вкладку «Характеристики» в конструкторе схемы компоновки данных. Однако на практике новички часто сталкиваются с тем, что после настройки поля не появляются в списке доступных. Проанализируем ситуацию и разберем пошагово, как правильно настроить этот механизм.
Для того чтобы система «поняла», какие дополнительные поля нужно «приклеить» к объекту (например, к Справочнику.Номенклатура), ей необходимо указать два источника данных:
ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения.ДополнительныеРеквизиты самого справочника.Рассмотрим подробнее, как заполнить таблицу на вкладке «Характеристики». Выясним назначение каждой колонки, так как ошибка в любой из них приведет к тому, что поля не отобразятся в дереве доступных полей.
Тип владельца: Здесь мы указываем объект, к которому относятся характеристики. В нашем случае это СправочникСсылка.Номенклатура. Это критически важно: СКД будет искать характеристики только для полей, имеющих именно этот тип данных.
Источник видов характеристик: Выбираем вариант «Запрос» или «Таблица». Если мы используем типовую конфигурацию (БП, УТ, ERP), и не усложняем задачу (например, когда применяются две разных схемы в отчете СКД), лучше выбрать запрос к Плану видов характеристик. Посмотрим на пример простого запроса для выбора видов:
ВЫБРАТЬ
Ссылка,
Наименование,
ТипЗначения
ИЗ
ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения
ГДЕ
НЕ ПометкаУдаления
В параметрах этого источника укажем:
Ссылка (уникальный идентификатор свойства).Наименование (то, как пользователь увидит название поля в отчете).ТипЗначения (позволяет СКД правильно подбирать элементы управления для фильтров).Проанализируем ситуацию, когда дополнительные реквизиты хранятся в табличной части справочника. Нам нужно написать запрос, который свяжет объект, само свойство и его значение. При написании таких запросов также полезна проверка на лишнюю выборку и разыменование полей составного типа. Посмотрим на структуру такого запроса:
ВЫБРАТЬ
Номенклатура.Ссылка КАК Объект,
Номенклатура.Свойство КАК Характеристика,
Номенклатура.Значение КАК Значение
ИЗ
Справочник.Номенклатура.ДополнительныеРеквизиты КАК Номенклатура
Важный момент: в настройках источника значений необходимо правильно сопоставить поля:
Объект (ссылка на номенклатуру, к которой относится значение).Характеристика (ссылка на элемент ПВХ).Значение (хранимые данные).Если вы выполнили настройки, но при нажатии на «плюсик» рядом с Номенклатурой в списке доступных полей ничего не появилось, разберем возможные причины.
1. Отсутствие флага «Автозаполнение». На вкладке «Наборы данных» проверьте, включена ли галочка Автозаполнение для вашего основного запроса. Если она выключена, СКД не будет автоматически добавлять новые поля в дерево, и их придется прописывать в расширении языка запросов вручную через фигурные скобки.
2. Использование расширения языка запросов. В некоторых случаях платформе требуется явное указание на использование характеристик. Рассмотрим, как это выглядит в тексте основного запроса:
ВЫБРАТЬ
Номенклатура.Ссылка КАК Ссылка
ИЗ
Справочник.Номенклатура КАК Номенклатура
{ХАРАКТЕРИСТИКИ
ТИП(Справочник.Номенклатура)
ВИДЫХАРАКТЕРИСТИК (ВЫБРАТЬ Ссылка, Наименование, ТипЗначения ИЗ ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения)
ПОЛЕКЛЮЧА Ссылка
ПОЛЕИМЕНИ Наименование
ПОЛЕТИПАЗНАЧЕНИЯ ТипЗначения
ЗНАЧЕНИЯХАРАКТЕРИСТИК (ВЫБРАТЬ Ссылка КАК Объект, Свойство КАК Характеристика, Значение ИЗ Справочник.Номенклатура.ДополнительныеРеквизиты)
ПОЛЕОБЪЕКТА Объект
ПОЛЕХАРАКТЕРИСТИКИ Характеристика
ПОЛЕЗНАЧЕНИЯ Значение }
3. Проблема типизации поля «Значение». Поле Значение в табличной части обычно имеет составной тип. Иногда СКД не может корректно определить тип данных «на лету». Чтобы помочь системе, можно использовать функцию ВЫРАЗИТЬ в запросе источника значений, если вы точно знаете типы данных ваших характеристик.
4. Роль прав доступа (RLS). Если вы настраиваете отчет под полными правами, а пользователь их не видит — проверьте права доступа на План видов характеристик и на табличную часть справочника. Если у пользователя нет прав на чтение этих объектов и не включен привилегированный режим СКД, характеристики не будут отображаться, даже если настройки верны.
Если ваши данные хранятся не в табличной части, а в РегистреСведений.ДополнительныеСведения, то в качестве источника значений следует использовать запрос к этому регистру. Схожий принцип источников данных применяется, если вы пытаетесь преобразовать динамический список в отчет СКД. Выясним разницу в запросе:
ВЫБРАТЬ
ДополнительныеСведения.Объект,
ДополнительныеСведения.Свойство КАК Характеристика,
ДополнительныеСведения.Значение
ИЗ
РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения
ГДЕ
ДополнительныеСведения.Объект ССЫЛКА Справочник.Номенклатура
При такой настройке СКД будет брать данные из единого хранилища для всех объектов. Это особенно полезно, когда характеристики добавлены к разным типам справочников или документов.
Чтобы убедиться, что всё настроено верно, проделаем следующие действия:
Номенклатура (нажать на «+»), и дополнительные реквизиты будут идти в общем списке вместе с «Кодом», «Артикулом» и другими стандартными полями.Таким образом, использование вкладки «Характеристики» — это мощный инструмент, который избавляет от необходимости вручную прописывать десятки левых соединений в основном запросе. Правильная настройка связей между объектом, его свойствами и значениями позволяет пользователям (в том числе использующим пользовательскую СКД) самостоятельно выводить любые дополнительные данные в отчеты без изменения кода конфигурации.