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

При работе с типовыми конфигурациями «1С:Предприятие 8» (например, «Бухгалтерия предприятия 3.0») разработчики часто сталкиваются с интересной особенностью: в Оборотно-сальдовой ведомости (ОСВ) или других стандартных отчетах пользователи могут легко выбирать дополнительные реквизиты и сведения в качестве группировок, отборов или дополнительных полей. При этом, если мы откроем схему компоновки данных (СКД) этого отчета в Конфигураторе и детально изучим текст запроса, то не обнаружим там никаких упоминаний табличных частей дополнительных реквизитов или регистров сведений со свойствами.

В этой статье мы подробно разберем, как именно устроен этот механизм «под капотом» платформы 1С, как Библиотека стандартных подсистем (БСП) связывает метаданные с Системой компоновки данных и как вы можете применить это решение в своих собственных разработках.

В чем суть проблемы и почему запросы СКД остаются «чистыми»

Разберем ситуацию на классическом примере. Мы хотим построить отчет по справочнику Контрагенты или Номенклатура. У этих справочников в режиме «1С:Предприятие» пользователями созданы десятки дополнительных реквизитов (например, «Регион», «Группа надежности», «Важность клиента»).

Если бы мы решали эту задачу «в лоб» традиционными методами программирования, нам пришлось бы:

1. Вручную модифицировать текст запроса в СКД, добавляя левые соединения с табличной частью дополнительных реквизитов.
2. Использовать параметры для фильтрации конкретных свойств.
3. Постоянно переписывать схему при добавлении новых свойств пользователями.

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

Платформенный механизм характеристик в метаданных

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

Чтобы найти эти настройки, выполним следующие шаги в Конфигураторе:

1. Откроем дерево метаданных и найдем интересующий нас объект (например, справочник Контрагенты).
2. Нажмем на нем правой кнопкой мыши и выберем пункт контекстного меню Характеристики.
3. Перед нами откроется окно настройки характеристик для данного объекта метаданных.

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

Как это реализовано в БСП (на примере БП 3.0)

В конфигурациях, созданных на основе БСП (включая «Бухгалтерию предприятия 3.0»), за ведение дополнительных свойств отвечает специализированная подсистема «Свойства». Настройки характеристик в метаданных справочников выполняются по строго определенному шаблону БСП.

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

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

2. Источники значений характеристик:
Здесь БСП разделяет хранение на два типа:

• Дополнительные реквизиты (хранятся внутри самого объекта для обеспечения быстрой выборки и записи). Источником значений для них выступает одноименная табличная часть самого объекта. Например, для контрагентов это табличная часть Справочник.Контрагенты.ДополнительныеРеквизиты. Связь настраивается по ключевым полям: Ссылка (владелец), Свойство (вид характеристики) и Значение (само значение).
• Дополнительные сведения (хранятся отдельно от объекта, чтобы не вызывать блокировок при изменении сведений). Источником значений здесь выступает регистр сведений ДополнительныеСведения. Связь настраивается аналогично, но поле объекта связывается с измерением Объект регистра.

Правила приоритета СКД при работе с характеристиками

Проанализируем, как система компоновки данных решает, откуда ей брать информацию о характеристиках. У платформы существует четкая иерархия приоритетов:

1. Локальное описание в запросе СКД: Разработчик может непосредственно в тексте запроса конкретного отчета написать конструкцию {ХАРАКТЕРИСТИКИ ...} или заполнить соответствующую вкладку «Характеристики» в конструкторе СКД. В этом случае настройки из метаданных объекта будут полностью проигнорированы. Это полезно, если в конкретном отчете вам нужно переопределить стандартное поведение системы.
2. Глобальное описание в объектах метаданных: Если в схеме СКД конкретного отчета характеристики никак не описаны (как это сделано в ОСВ), платформа обращается к свойствам объектов метаданных, участвующих в запросе. Если у справочника настроена вкладка «Характеристики» в конфигураторе, то СКД автоматически расширяет доступные поля для этого справочника.

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

Пример явного описания характеристик в СКД

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

Посмотрим на пример такого запроса:

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

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

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

Что происходит на уровне СУБД (Трансляция в SQL)

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

Когда пользователь в режиме «1С:Предприятие» выбирает в ОСВ группировку по дополнительному свойству (например, по региону контрагента) или устанавливает по нему отбор, СУБД выполняет следующие действия:

• Платформа динамически модифицирует итоговый SQL-запрос.
• К основной таблице (справочнику контрагентов) применяется левое соединение (LEFT JOIN) с таблицей значений характеристик (табличной частью или регистром сведений).
• Соединение накладывается по условию совпадения ссылки объекта и конкретного идентификатора (ID) свойства в плане видов характеристик.

Важный нюанс производительности: Если в отчет одновременно выводится, к примеру, 5 различных дополнительных реквизитов, платформа построит 5 отдельных последовательных левых соединений (LEFT JOIN) к одной и той же таблице значений. На больших базах данных при формировании тяжелых отчетов это может приводить к заметному снижению скорости работы. Поэтому, если какое-то свойство становится критически важным для учета и используется постоянно во всех ключевых отчетах, имеет смысл рассмотреть возможность создания реального реквизита в метаданных конфигурации вместо использования механизма дополнительных свойств БСП.

Использование характеристик в Динамических списках

Описанный механизм характеристик в метаданных работает не только для отчетов СКД, но и для обычных динамических списков (например, в формах списков справочников или документов).

Если у динамического списка в свойствах включен флаг Автовыбор свойств (или если основная таблица запроса списка имеет настроенные характеристики в конфигураторе), пользователи могут через стандартное меню «Еще» -> «Изменить форму» выносить дополнительные свойства в виде колонок списка без какого-либо программирования. Платформа сама позаботится о связи таблиц и выводе актуальных данных на экран.