Как получить дополнительный реквизит регистратора составного типа в запросе 1С

← На главную

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

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

Причина проблемы и особенности работы платформы

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

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

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

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

Разберем по шагам, как работает данный подход:

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

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

Способ 2. Переход на механизм «Дополнительные сведения»

Проанализируем архитектурное различие между двумя механизмами БСП:

Дополнительные реквизиты — хранятся в табличных частях самих документов. Извлечь их для составного типа без обращения к десяткам таблиц невозможно.
Дополнительные сведения — хранятся централизованно в независимом регистре сведений РегистрСведений.ДополнительныеСведения.

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


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

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

Способ 3. Явное приведение типов (не рекомендуется)

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


ЛЕВОЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг.ДополнительныеРеквизиты КАК ТЧ_Приобретение
	ПО ПрочиеДоходы.Регистратор = ТЧ_Приобретение.Ссылка
	И ТЧ_Приобретение.Свойство = &СвойствоПроект
ЛЕВОЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг.ДополнительныеРеквизиты КАК ТЧ_Реализация
	ПО ПрочиеДоходы.Регистратор = ТЧ_Реализация.Ссылка
	И ТЧ_Реализация.Свойство = &СвойствоПроект

Важно: Этот подход крайне не рекомендуется к использованию. Добавление десятков левых соединений к табличным частям разных документов приводит к созданию огромного SQL-запроса. СУБД вынуждена выполнять сканирование 57 таблиц, что вызывает падение производительности и длительные задержки при расчете результатов.

Выводы и рекомендации

Для решения задачи получения дополнительных данных из регистратора составного типа рекомендуется руководствоваться следующими правилами:

Для произвольных запросов в подсистемах бюджетирования или произвольного источника данных СКД оптимально перевести аналитику в Дополнительные сведения и запрашивать данные из РегистрСведений.ДополнительныеСведения.
Для пользовательских отчетов СКД следует использовать штатный механизм Характеристик.
В рамках подсистемы бюджетирования 1С:ERP для сквозного учета рекомендуемся использовать встроенные сквозные аналитики (например, НаправлениеДеятельности или подсистему «Аналитики бюджетирования»), а не табличные части документов.