Как правильно выбрать характеристики номенклатуры и их свойства в запросе СКД в 1С:Управление торговлей 10.3?

Программист 1С v8.3 (Обычные формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При разработке отчетов на базе Системы компоновки данных (СКД) в конфигурации «Управление торговлей 10.3» (УТ 10.3) программисты часто сталкиваются с необходимостью вывода дополнительных свойств и характеристик товаров. Дополнительные свойства в этой конфигурации хранятся в регистре сведений ЗначенияСвойствОбъектов, а сами характеристики товаров — в справочнике ХарактеристикиНоменклатуры.

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

Способ 1. Исправление ошибки связи таблиц в ручном запросе

Рассмотрим ситуацию, с которой часто сталкиваются разработчики при написании запроса «в лоб». Посмотрим на исходный запрос, в котором значения свойств характеристик почему-то не заполнялись:


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

Проанализируем эту ситуацию и выясним причину ошибки. Проблема кроется в строке связи таблиц:

ПО ХарактеристикиНоменклатуры.Владелец = ЗначенияСвойствОбъектов.Объект

Реквизит Владелец справочника ХарактеристикиНоменклатуры ссылается на справочник Номенклатура. Таким образом, связывая таблицы по этому полю, мы пытаемся сопоставить объект свойства с самим товаром (номенклатурой), а не с его конкретной характеристикой. Если у самой номенклатуры нет свойств с таким же соответствием, или если мы хотели получить свойства именно конкретного размера/цвета (характеристики), то результатом запроса в колонках свойств будут пустые значения.

Для того чтобы получить свойства, назначенные непосредственно характеристике номенклатуры, нам необходимо связать регистр сведений по ссылке самой характеристики. Ведь именно ссылка на элемент справочника ХарактеристикиНоменклатуры выступает в качестве измерения Объект в регистре ЗначенияСвойствОбъектов.

Давайте посмотрим на исправленный и полностью работоспособный вариант запроса:


ВЫБРАТЬ
    Номенклатура.Ссылка КАК Ссылка,
    ХарактеристикиНоменклатуры.Ссылка КАК Характеристика,
    ЗначенияСвойствОбъектов.Объект КАК ОбъектСвойства,
    ЗначенияСвойствОбъектов.Свойство КАК Свойство,
    ЗначенияСвойствОбъектов.Значение КАК ЗначениеСвойства
ИЗ
    Справочник.Номенклатура КАК Номенклатура
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ХарактеристикиНоменклатуры КАК ХарактеристикиНоменклатуры
            ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
            ПО ХарактеристикиНоменклатуры.Ссылка = ЗначенияСвойствОбъектов.Объект
        ПО Номенклатура.Ссылка = ХарактеристикиНоменклатуры.Владелец
{ГДЕ
    (Номенклатура.Ссылка В ИЕРАРХИИ (&ВыбГр))}
УПОРЯДОЧИТЬ ПО
    ХарактеристикиНоменклатуры.Владелец

В этом варианте связь ПО ХарактеристикиНоменклатуры.Ссылка = ЗначенияСвойствОбъектов.Объект отрабатывает корректно, и мы получаем точное соответствие характеристик товара и их индивидуальных свойств.

Способ 2. Использование штатной вкладки «Характеристики» в СКД

Хотя ручное соединение таблиц в запросе решает задачу, оно имеет ряд существенных недостатков с точки зрения гибкости и производительности отчета. Опытные разработчики 1С рекомендуют использовать специализированный встроенный механизм СКД.

Рассмотрим подробнее, почему этот способ является более предпочтительным:

  1. Оптимизация производительности: СКД подключает таблицы свойств и значений динамически — только тогда, когда пользователь добавил эти поля в настройки вывода, группировки или отбора. Если свойства не используются в текущем сеансе формирования отчета, СУБД не делает лишних «тяжелых» левых соединений, что значительно ускоряет работу системы на больших базах.
  2. Удобство для конечных пользователей: Новые свойства, создаваемые пользователями непосредственно в режиме «1С:Предприятие» без изменения конфигурации, будут автоматически доступны в интерфейсе настройки отчета. Они отображаются как обычные реквизиты номенклатуры или характеристики (доступно раскрытие по «плюсику»).
  3. Чистота структуры схемы: Исходный текст запроса не загромождается многочисленными связями с регистрами сведений.

Разберем по шагам, как настроить данный механизм в конструкторе схемы компоновки данных.

Шаг 1. Переход на вкладку настройки

Откроем схему компоновки данных нашего отчета. На панели вкладок перейдем на вкладку «Характеристики». Нажмите кнопку добавления новой строки.

Шаг 2. Заполнение параметров для связи свойств

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

Вариант А. Настройка для получения дополнительных свойств самой Номенклатуры:

Вариант Б. Настройка для получения свойств Характеристик Номенклатуры:

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

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

Описание характеристик через расширение языка запросов

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


ВЫБРАТЬ
    Номенклатура.Ссылка КАК Ссылка
ИЗ
    Справочник.Номенклатура КАК Номенклатура

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

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

Важные нюансы и проблемы при работе с характеристиками

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

1. Оптимизация вывода свойств через Запрос-источник

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

Чтобы избежать этой путаницы, мы рекомендуем использовать в качестве источника видов характеристик не «Таблицу», а «Запрос». Давайте напишем оптимальный запрос для отбора только свойств, предназначенных для номенклатуры:


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

Этот запрос жестко ограничивает перечень выводимых в интерфейс настройки свойств только теми, у которых назначение соответствует справочнику номенклатуры. Аналогичный отбор можно сделать и для характеристик номенклатуры, используя соответствующее значение перечисления НазначенияСвойствКатегорийОбъектов.

2. Проблема подбора значений в отборах отчета

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

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

3. Неопределенный тип значения в ПВХ

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

← На главную