Почему не работает конструктор запросов при выборке из табличной части в 1С и как правильно получить дополнительные реквизиты?

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

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

Выясним причины сбоя в конструкторе запросов

Разберем основные причины, почему конструктор запросов в конфигураторе может вызывать ошибки или не видеть табличные части объектов:

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

Анализ ошибок в исходном запросе

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

1. Неявное превращение соединения во внутреннее (INNER JOIN): Если используется ПОЛНОЕ СОЕДИНЕНИЕ или ЛЕВОЕ СОЕДИНЕНИЕ, но условия на свойства присоединяемых таблиц помещаются в общую секцию ГДЕ (например, ГДЕ Доп1.Свойство.Наименование = "..."), то записи со значением NULL автоматически отсекаются. В результате логика соединения полностью ломается: если у какого-либо документа не заполнен хотя бы один из запрашиваемых дополнительных реквизитов, весь документ целиком выпадает из итоговой выборки.
2. Обращение к наименованию через точку (Свойство.Наименование): Такое обращение заставляет платформу выполнять дополнительное соединение с таблицей ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения при обработке каждой строки. Кроме того, поиск по наименованию нестабилен: если пользователь в режиме «Предприятие» изменит название доп. реквизита, отчет перестанет работать.
3. Низкая производительность: Множественное соединение одной и той же табличной части самой с собой создает существенную нагрузку на СУБД и приводит к декартову произведению строк.

Рассмотрим правильные варианты построения таких запросов.

Способ 1. Выборка через группировку и агрегатные функции

Наиболее эффективным и быстродействующим способом разворачивания строк табличной части в колонки является использование агрегатных функций (МАКСИМУМ) с условным оператором ВЫБОР и группировкой по ссылке документа.

При таком подходе мы выполняем всего одно левое соединение с табличной частью ДополнительныеРеквизиты, а сами дополнительные свойства передаем в качестве параметров запроса:

ВЫБРАТЬ
	Документ.Ссылка КАК Ссылка,
	МАКСИМУМ(ВЫБОР КОГДА ДопРеквизиты.Свойство = &СвойствоВидБГ ТОГДА ДопРеквизиты.Значение КОНЕЦ) КАК ВидБГ,
	МАКСИМУМ(ВЫБОР КОГДА ДопРеквизиты.Свойство = &СвойствоБенефициар ТОГДА ДопРеквизиты.Значение КОНЕЦ) КАК Бенефициар,
	МАКСИМУМ(ВЫБОР КОГДА ДопРеквизиты.Свойство = &СвойствоПринципал ТОГДА ДопРеквизиты.Значение КОНЕЦ) КАК Принципал,
	МАКСИМУМ(ВЫБОР КОГДА ДопРеквизиты.Свойство = &СвойствоГарант ТОГДА ДопРеквизиты.Значение КОНЕЦ) КАК Гарант
ИЗ
	Справочник.ВнутренниеДокументы КАК Документ
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ВнутренниеДокументы.ДополнительныеРеквизиты КАК ДопРеквизиты
		ПО ДопРеквизиты.Ссылка = Документ.Ссылка
ГДЕ
	Документ.ВидДокумента.Родитель.Наименование = "Банковские гарантии"
	И НЕ Документ.ПометкаУдаления
СГРУППИРОВАТЬ ПО
	Документ.Ссылка

В данном запросе параметр &СвойствоВидБГ и другие параметры должны содержать конкретные ссылки на элементы плана видов характеристик ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.

Способ 2. Левое соединение с условиями в секции ПО

Если по логике задачи необходимо использовать соединение табличной части с самой собой несколько раз, критически важно перенести условия отбора по свойствам непосредственно в условие связи ПО, а не оставлять их в секции ГДЕ.

Рассмотрим пример правильного написания левого соединения:

ВЫБРАТЬ
	Документ.Ссылка КАК Ссылка,
	Доп1.Значение КАК ВидБГ,
	Доп2.Значение КАК Бенефициар
ИЗ
	Справочник.ВнутренниеДокументы КАК Документ
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ВнутренниеДокументы.ДополнительныеРеквизиты КАК Доп1
		ПО Доп1.Ссылка = Документ.Ссылка 
		И Доп1.Свойство = &СвойствоВидБГ
	ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ВнутренниеДокументы.ДополнительныеРеквизиты КАК Доп2
		ПО Доп2.Ссылка = Документ.Ссылка 
		И Доп2.Свойство = &СвойствоБенефициар
ГДЕ
	НЕ Документ.ПометкаУдаления

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

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

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

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

1. В схеме компоновки данных на вкладке «Наборы данных» составляем простой запрос к основному справочнику без каких-либо соединений с табличными частями:
   Скопировать код

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

2. Переходим на вкладку «Характеристики» и добавляем новую строку со следующими настройками:
   1. Тип объекта: СправочникСсылка.ВнутренниеДокументы
   2. Источник видов характеристик: ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения
   3. Источник значений: табличная часть ДополнительныеРеквизиты (поля Ссылка, Свойство, Значение)
3. После выполнения настройки все дополнительные реквизиты будут автоматически доступны в конструкторе настроек СКД как дочерние поля объекта (через точку от поля Ссылка). При формировании отчета СКД сама сформирует оптимальный SQL-запрос.

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