Как в динамическом списке явно указать тип поля при использовании объединения запросов

← На главную

Работа с динамическими списками в системе 1С:Предприятие 8.3 — это стандартная задача, однако она существенно усложняется, когда мы используем произвольные запросы с конструкцией ОБЪЕДИНИТЬ ВСЕ. Одной из наиболее острых проблем является корректное определение типов полей, особенно если в разных частях объединения данные принадлежат разным типам метаданных. Ситуация усугубляется, когда по техническим причинам нам приходится отключать флаг «Автозаполнение полей». В этой статье мы подробно разберем, как принудительно заставить систему видеть нужные типы данных и обеспечивать корректную работу списка.

Анализируем проблему типизации в объединениях

Разберем ситуацию: у нас есть динамический список, который собирает данные из двух разных документов, например, Документ.РеализацияТоваровУслуг и Документ.АктВыполненныхРабот. В обоих документах есть поле Заказ, но его типы различаются. При использовании ОБЪЕДИНИТЬ ВСЕ платформа 1С зачастую ориентируется на первый запрос в последовательности. Если в первом запросе поле имеет тип ДокументСсылка.ЗаказПокупателя, то и весь результирующий столбец в динамическом списке может быть ограничен этим типом, даже если во второй части объединения приходят ссылки на другие документы. Это приводит к тому, что данные из второй таблицы просто не отображаются или отображаются некорректно.

Решение 1: Использование конструкции ВЫРАЗИТЬ в тексте запроса

Самый надежный способ на уровне SQL-запроса — это явное приведение типа. Мы можем использовать функцию ВЫРАЗИТЬ, чтобы расширить или уточнить тип поля. Рассмотрим пример, где мы объединяем данные и хотим, чтобы поле Заказ стало составным типом.

Проанализируем следующий пример кода:


ВЫБРАТЬ
    Ссылка КАК Ссылка,
    ВЫРАЗИТЬ(Заказ КАК Документ.ЗаказПокупателя) КАК Заказ,
    Статус КАК Статус
ИЗ
    Документ.Документ1 КАК Документ1

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    Ссылка,
    ВЫРАЗИТЬ(Заказ КАК Документ.ЗаказПоставщику),
    Статус
ИЗ
    Документ.Документ2 КАК Документ2

Однако, если автозаполнение отключено, система может проигнорировать эти намеки. В таких случаях можно применить хитрость с «пустым» первым запросом, который никогда не вернет строк, но задаст эталонные типы для всей выборки. Для этого мы используем конструкцию ВЫРАЗИТЬ(NULL КАК ...).


ВЫБРАТЬ
    ВЫРАЗИТЬ(NULL КАК Документ.РеализацияТоваровУслуг) КАК Ссылка,
    ВЫРАЗИТЬ(NULL КАК Справочник.Валюты) КАК Валюта
ГДЕ
    ЛОЖЬ

ОБЪЕДИНИТЬ ВСЕ

// Далее основной запрос...

Решение 2: Ручное редактирование типов в настройках списка

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

Откроем окно настройки динамического списка в конфигураторе.
Перейдем на закладку «Поля» (она доступна при снятом флаге автозаполнения).
Найдем нужное нам поле (например, Заказ).
В колонке «Тип» нажмем на кнопку выбора (три точки).
В открывшемся окне выбора типов вручную отметим галочками все типы документов или справочников, которые могут встретиться в этом поле.

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

Решение 3: Работа с псевдонимами и секциями компоновки

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

Если мы используем объединение, крайне важно, чтобы псевдонимы полей во всех частях запроса совпадали. Если в первом запросе поле называется Заказ, а во втором ДокументОснование, система не сможет корректно сопоставить их типы без явного указания псевдонима КАК Заказ во второй части.

Рассмотрим правильную структуру с использованием секций {ВЫБРАТЬ} и {ГДЕ}:


ВЫБРАТЬ
    Док1.Ссылка КАК Ссылка,
    Док1.Заказ КАК Заказ,
    Док1.Статус КАК Статус
{ВЫБРАТЬ
    Ссылка.*,
    Заказ.*,
    Статус.*}
ИЗ
    Документ.Документ1 КАК Док1
{ГДЕ
    Док1.Ссылка.*,
    Док1.Заказ.*,
    Док1.Статус.*}

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    Док2.Ссылка,
    Док2.Заказ,
    Док2.Статус
ИЗ
    Документ.Документ2 КАК Док2
{ГДЕ
    Док2.Ссылка.*,
    Док2.Заказ.*,
    Док2.Статус.*}

Обратите внимание, что секция {ВЫБРАТЬ} обычно указывается один раз в первом запросе, а секции {ГДЕ} должны присутствовать в каждой части объединения, чтобы условия поиска и отборов накладывались на обе таблицы. Если при этом возникает ошибка «Не найдено ключевое поле», убедитесь, что в свойствах динамического списка в поле «Основная таблица» ничего не указано, либо явно выбрано поле Ссылка в качестве ключевого.

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

Иногда конфигуратор «кеширует» описание полей, и даже после внесения изменений в запрос типы остаются старыми. Проанализируем алгоритм «сброса» этого состояния:

Временно включим флаг «Автозаполнение полей».
Закроем окно редактирования запроса, нажав «ОК», чтобы система обновила внутреннюю структуру полей.
Снова откроем запрос и выключим «Автозаполнение полей».
Теперь список полей очистится или обновится, и мы сможем заново добавить нужные поля с корректными типами.