Где определить тип документа в запросе 1С

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

Тип документа в контексте запроса — это не просто строка, а ссылка на объект метаданных. Ошибка в понимании этого механизма приводит к тому, что запрос либо возвращает пустой результат, либо вызывает ошибку выполнения типа "Конвертация значений не поддерживается". Необходимо четко различать ситуацию, когда вы фильтруете уже существующую ссылку, и ситуацию, когда вы формируете условие для поля с неопределенным типом.

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

Использование свойства ИмяСсылки в условиях отбора

Самый распространенный сценарий — это фильтрация данных в таблице значений или в регистре, где поле имеет составной тип "ДокументСсылка.ЛюбойДокумент". В таких случаях платформа не позволяет напрямую сравнивать ссылку со строкой. Вам необходимо использовать специальное свойство ИмяСсылки. Это свойство доступно для любых объектов-ссылок и возвращает строковое представление типа метаданных.

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

Рассмотрим пример кода, где мы выбираем только накладные из общего списка движений:

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

Здесь мы явно указываем, что нас интересуют только те записи, где тип ссылки соответствует документу реализации. Это работает быстрее, чем получение всех записей и последующая фильтрация в коде 1С, так как отбор происходит на уровне СУБД. Однако стоит помнить, что использование ИмяСсылки в условии ГДЕ может препятствовать использованию индексов по самому полю ссылки в некоторых редких случаях оптимизации сервера, хотя для составных типов это часто единственный путь.

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

Работа с параметрами запроса и типами данных

Часто тип документа требуется передать в запрос из внешнего кода через параметр. Это особенно актуально при создании универсальных отчетов или обработок, которые должны работать с разными видами документов в зависимости от выбора пользователя. В этом случае вы не можете жестко прописать имя типа в тексте запроса.

Для решения этой задачи используется механизм параметров. Вы объявляете параметр в тексте запроса, а в коде 1С присваиваете ему значение. Здесь кроется важный нюанс: что именно передавать в параметр? Можно передать саму ссылку на документ, а можно передать значение типа ОписаниеТипов или строку с именем типа.

Если вы передаете ссылку, то в запросе вы можете использовать конструкцию ТИПЗНАЧЕНИЯ (в новых версиях платформы) или сравнивать ИмяСсылки параметра с именем типа. Однако более гибкий подход — это передача строкового идентификатора типа.

• 📄 Передавайте строку "ДокументСсылка.ЗаказКлиента", если хотите жестко фильтровать по типу.
• 🔗 Передавайте конкретную ссылку на документ, если нужно найти записи, связанные именно с этим экземпляром.
• ⚙️ Используйте параметр типа Массив, если нужно отфильтровать сразу по нескольким типам документов в одном запросе.

Пример установки параметра в коде 1С:

Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ ... ГДЕ Ссылка.ИмяСсылки = &ТипДокумента";
Запрос.УстановитьПараметр("ТипДокумента", "ДокументСсылка.ПоступлениеТоваровУслуг");

Почему не стоит передавать Тип в параметр напрямую?

Передача объекта типа "Тип" в параметр запроса возможна, но сравнение типа ссылки с объектом типа "Тип" внутри запроса часто приводит к ошибкам конвертации или требует явного приведения типов, что усложняет чтение кода. Проще сравнивать строковые имена.

При работе с параметрами также следует опасаться SQL-инъекций, хотя в 1С механизм параметров защищает от этого автоматически. Главное — не формировать текст запроса конкатенацией строк, подставляя туда имя типа напрямую из переменных пользователя, если это не контролируемые данные.

Функция ТипЗнч внутри текста запроса

В некоторых версиях платформы и конфигураций разработчики пытаются использовать функцию ТипЗнч() непосредственно внутри текста запроса для динамического определения типа. Это мощный инструмент, но его применение внутри запроса ограничено.

Функция ТипЗнч возвращает описание типа значения. В контексте запроса она может быть использована для полей, которые могут принимать значения разных типов (например, поле "ВидСубконто" или произвольные поля в регистрах сведений). Однако для ссылок на документы предпочтительнее использовать свойство ИмяСсылки, так как оно работает стабильнее и понятнее для оптимизатора запросов.

⚠️ Внимание: Использование функции ТипЗнч() внутри запроса для больших выборок может существенно снизить производительность, так как требует вычисления типа для каждой строки результата перед применением отбора.

Если вы все же вынуждены использовать ТипЗнч, убедитесь, что вы сравниваете результат функции с корректным представлением типа. Часто возникает ошибка, когда разработчик сравнивает результат ТипЗнч со строкой, забывая, что функция возвращает объект типа Тип, а не строку.

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

ВЫБРАТЬ
Таблица.Поле
ИЗ
Таблица
ГДЕ
ТипЗнч(Таблица.Поле) = ТИП("ДокументСсылка.СчетФактураВыданный")

Здесь используется конструктор типа ТИП() внутри запроса. Это допустимый синтаксис, но он менее производителен, чем сравнение строк через ИмяСсылки. Используйте этот метод только тогда, когда поле не является ссылкой, а содержит произвольные данные.

Особенности работы с виртуальными таблицами регистров

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

В этом случае вопрос "где тип документа" решается исключительно через свойство ИмяСсылки поля Регистратор. Попытка обратиться к конкретным полям документа без предварительной фильтрации по типу приведет к ошибке, так как сервер не знает структуру объекта до момента выполнения запроса.

Типичная ошибка новичков — попытка сделать JOIN с таблицей документа без условия по типу. Запрос должен выглядеть следующим образом:

Этап	Действие	Результат
1	Выборка из регистра	Получение всех движений
2	Условие ГДЕ Регистратор.ИмяСсылки	Фильтрация по типу "ЧекККМ"
3	Соединение (ЛЕВОЕ СОЕДИНЕНИЕ)	Получение дополнительных реквизитов чека

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

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

Конвертация типов и частые ошибки

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

В тексте запроса типы должны быть согласованы. Если вы сравниваете ИмяСсылки (которое всегда строка) с параметром, параметр тоже должен быть строкой. Попытка передать в этот параметр объект ДокументСсылка вызовет ошибку выполнения.

• ❌ Ошибка: Передача ссылки в параметр, который сравнивается со строкой имени типа.
• ✅ Решение: Использовать метод .ИмяСсылки у передаваемой ссылки перед установкой параметра.
• ⚠️ Нюанс: Пустая ссылка имеет имя типа, но её использование в запросах может быть специфичным в зависимости от версии платформы.

Еще одна распространенная ошибка связана с использованием констант. Если в запросе используется константа типа "ДокументСсылка.ЛюбойДокумент", проверить её тип можно только через ИмяСсылки. Прямое сравнение константы с типом невозможно без приведения.

⚠️ Внимание: В запросах нельзя использовать операторы объектного доступа (точку) для вызова методов, кроме разрешенных свойств like ИмяСсылки. Попытка вызвать метод GetType() внутри запроса приведет к синтаксической ошибке.

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

Оптимизация и производительность при фильтрации по типу

Вопрос производительности при фильтрации по типу документа стоит особенно остро в высоконагруженных системах. Неправильное использование условий может привести к полному сканированию таблиц (Table Scan), что недопустимо для больших объемов данных.

Использование ИмяСсылки в условии ГДЕ обычно позволяет серверу 1С использовать индекс по полю ссылки, так как внутренне это поле часто хранится с информацией о типе. Однако, если условие написано сложно (например, с использованием функций над полем), индекс может не сработать.

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

Также стоит учитывать, что в распределенных информационных базах (РИБ) типы документов могут иметь разные уникальные идентификаторы. Сравнение по ИмяСсылки в этом случае остается надежным способом, так как имя метаданных в узлах РИБ должно быть идентичным.

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

Можно ли использовать wildcard (звездочку) для типа документа?

Нет, в стандартном языке запросов 1С нельзя использовать шаблоны типа "ДокументСсылка.*" для выбора всех документов определенной подгруппы. Необходимо перечислять типы явно через оператор ИЛИ или использовать группировку в коде.

Как получить тип документа, если поле имеет тип "ХранилищеЗначения"?

Для поля типа ХранилищеЗначения свойство ИмяСсылки недоступно напрямую в запросе. Вам нужно выгрузить данные и определить тип в коде 1С с помощью функции ТипЗнч(), либо использовать специфические функции расширения (если доступны в вашей версии платформы).

Почему запрос не видит новый тип документа после обновления конфигурации?

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

Влияет ли длина имени типа документа на производительность?

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

Можно ли фильтровать по типу в операторе ВЫБРАТЬ РАЗЛИЧНЫЕ?

Да, условие по типу документа (через ИмяСсылки) может быть использовано вместе с ключевым словом РАЗЛИЧНЫЕ. Оно применяется на этапе фильтрации строк перед удалением дублей, что является корректным с точки зрения логики выполнения запроса.