Как проверить тип значения в запросе 1С

О чём эта статья

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

Почему типы в запросах вообще важны

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

Типы в конфигураторе и в запросе: связь

Тип реквизита настраивается в конфигураторе, а в базе уже хранятся конкретные значения и их реальные типы — включая NULL и НЕОПРЕДЕЛЕНО для отсутствующих или не заполненных значений. В запросе к такому полю можно получить как обычный тип (СТРОКА, ЧИСЛО, Справочник.Сотрудники), так и специальные служебные типы, и именно функция проверки типа помогает отличить одно от другого. Поэтому перед сложной выборкой всегда полезно мысленно «посмотреть» на тип поля и понять, какие варианты встретятся в живых данных.

Основные инструменты: ТИПЗНАЧЕНИЯ, ТИП и ССЫЛКА

В языке запросов 1С для работы с типами есть целый небольшой «набор» функций и операторов: ТИПЗНАЧЕНИЯ, ТИП и логический оператор ССЫЛКА. Первая функция возвращает тип конкретного значения, вторая — позволяет получить значение типа по имени примитивного или ссылочного типа, а оператор ССЫЛКА проверяет, является ли выражение ссылкой на указанную таблицу. В связке они позволяют и просто вывести тип в выборку, и жёстко отфильтровать строки по нужному типу, и аккуратно разрулить составные реквизиты.

Функция ТИПЗНАЧЕНИЯ: идея и назначение

Функция ТИПЗНАЧЕНИЯ в запросе по смыслу полностью аналогична функции ТипЗнч встроенного языка: она принимает одно выражение и возвращает значение специального типа Тип, описывающее реальный тип этого выражения. Параметром функции может быть как поле таблицы (реквизит объекта), так и параметр запроса, вычисляемое выражение или даже результат другого вызова функции. Обычно результат ТИПЗНАЧЕНИЯ либо выводят в выборку для диагностики, либо сразу сравнивают с ТИП(…) в условиях отбора или в конструкции ВЫБОР.

Простейший пример с выводом типа в выборку

Рассмотрим документ «РеализацияТоваров», у которого есть реквизит «Контрагент» составного типа: СправочникСсылка.Контрагенты, СправочникСсылка.Сотрудники и, скажем, ФизЛицо. Иногда нужно просто увидеть, кто именно выступает покупателем в каждом документе, не заглядывая в форму документа руками. Тогда в запросе можно добавить отдельную колонку с типом покупателя, используя ТИПЗНАЧЕНИЯ.

Код запроса с выводом типов

ВЫБРАТЬ
	Реализация.Ссылка КАК Документ,
	Реализация.Контрагент КАК Контрагент,
	ТИПЗНАЧЕНИЯ(Реализация.Контрагент) КАК ТипКонтрагента
ИЗ
	Документ.РеализацияТоваров КАК Реализация

Такой запрос вернёт список документов с колонкой, в которой явно записано, какого типа был контрагент — сотрудник, контрагент из справочника или физическое лицо, и это сильно облегчает анализ базы и отладку логики скидок и прав доступа.

Как интерпретировать результат ТИПЗНАЧЕНИЯ

Результат ТИПЗНАЧЕНИЯ — это не строка с названием типа, а значение специального системного типа Тип, с которым дальше можно сравнивать, группировать и даже передавать в параметры. В выборке в режиме отладки вы увидите, например, «СправочникСсылка.Контрагенты» или «Строка», но для языка запросов это именно объект типа Тип, а не просто текстовая подпись. Благодаря этому можно строить строгие условия вида «ТИПЗНАЧЕНИЯ(Поле) = ТИП(СТРОКА)» и быть уверенным, что сравнение выполняется по сути, а не по совпадению текста.

Функция ТИП: как получить значение типа по имени

Функция ТИП в запросе принимает имя примитивного типа (СТРОКА, ЧИСЛО, ДАТА, БУЛЕВО) или имя таблицы метаданных, чтобы вернуть соответствующее значение типа Тип. Пример: ТИП(СТРОКА) вернёт тип для строковых значений, а ТИП(Справочник.ДополнительныеРасходы) — тип ссылки на элементы справочника «ДополнительныеРасходы». Именно с такими значениями потом удобно сравнивать результат ТИПЗНАЧЕНИЯ в условиях отбора.

Сравнение типов: классическая связка ТИПЗНАЧЕНИЯ + ТИП

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

Пример отбора по строковому типу

Предположим, что в справочнике «ДополнительныеРасходы» есть реквизит «ВидРасхода» составного типа, в котором могут храниться либо строки, либо ссылки на другие справочники. Задача — выбрать только те дополнительные расходы, где признак задан строкой.

ВЫБРАТЬ
	ДополнительныеРасходы.Ссылка,
	ДополнительныеРасходы.Наименование,
	ДополнительныеРасходы.ВидРасхода,
	ТИПЗНАЧЕНИЯ(ДополнительныеРасходы.ВидРасхода) КАК ТипПризнака
ИЗ
	Справочник. ДополнительныеРасходы КАК ДополнительныеРасходы
ГДЕ
	ТИПЗНАЧЕНИЯ(ДополнительныеРасходы.ВидРасхода) = ТИП(СТРОКА)

Такой запрос вернёт только те строки, где реальный тип значения — строка, а все NULL, НЕОПРЕДЕЛЕНО и ссылочные значения аккуратно останутся за бортом.

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

Тот же приём легко адаптируется под ссылочные типы: вместо ТИП(СТРОКА) указываем ТИП(Справочник.Какой‑ТоСправочник). Например, отбираем дополнительные расходы, у которых вид расхода — ссылка на справочник «ВидыРасходов».

ГДЕ
	ТИПЗНАЧЕНИЯ(ДополнительныеРасходы.ВидРасхода) = ТИП(Справочник.ВидыРасходов)

Для платформы не важно, что в одном и том же реквизите часть строк хранит строки, часть — ссылки: проверка идёт по реальному типу значения, а не по типу реквизита в конфигураторе.

Оператор ССЫЛКА: короткий путь для ссылочных типов

Для ссылочных типов есть ещё один удобный инструмент — оператор ССЫЛКА, который проверяет, является ли выражение ссылкой на указанную таблицу метаданных. По смыслу он близок к связке «ТИПЗНАЧЕНИЯ(…) = ТИП(Справочник.… )», но короче и читается более естественно, когда речь идёт именно о ссылках. Слева от оператора указывается проверяемое выражение, справа — объект метаданных, например «Справочник.Цвета».

Пример с оператором ССЫЛКА

Вернёмся к реквизиту «ВидРасхода» в справочнике «ДополнительныеРасходы» и выберем только те записи, где он ссылается на элемент справочника «ВидыРасходов».

ВЫБРАТЬ
	ДополнительныеРасходы.Ссылка,
	ДополнительныеРасходы.Наименование,
	ДополнительныеРасходы.ОтличительныйПризнак
ИЗ
	Справочник. ДополнительныеРасходы КАК ДополнительныеРасходы
ГДЕ
	ДополнительныеРасходы. ВидРасхода ССЫЛКА Справочник.ВидыРасходов

Логика простая: если значение в поле — именно ссылка на элемент указанного справочника, строка попадёт в выборку, иначе — нет, что удобно и для фильтрации, и для последующего присоединения соответствующих таблиц по ссылкам.

Сравнение ТИПЗНАЧЕНИЯ+ ТИП и ССЫЛКА

Оператор ССЫЛКА — по сути, «сокращённая запись» проверки типа для ссылочных значений, аналог выражения «ТИПЗНАЧЕНИЯ(Поле) = ТИП(Справочник.… )». За ним всё равно скрывается типоведение, просто синтаксис короче и интуитивнее для тех, кто привык мыслить ссылками на справочники и документы. При этом для примитивных типов (строка, число, дата) альтернативы в виде ССЫЛКА нет, там по‑прежнему используется только связка ТИПЗНАЧЕНИЯ + ТИП.

Специальные типы: NULL и НЕОПРЕДЕЛЕНО

При работе с составными реквизитами в запросах важно помнить о двух «особых» значениях: NULL и НЕОПРЕДЕЛЕНО. NULL означает отсутствие самого поля в строке (например, когда реквизит не хранится для группы справочника), а НЕОПРЕДЕЛЕНО — когда поле есть, но значение у него не заполнено. Функция ТИПЗНАЧЕНИЯ возвращает для этих случаев отдельные типы, которые можно использовать в условиях и в отладке.

Как отобрать значения с NULL с помощью ЕСТЬ NULL

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

Отбор по НЕОПРЕДЕЛЕНО и безопасная фильтрация

Значение НЕОПРЕДЕЛЕНО в составных реквизитах обозначает, что поле существует, но пользователь не выбрал ни один из допустимых типов и ничего не ввёл. В таких строках функция ТИПЗНАЧЕНИЯ вернёт специальный тип для НЕОПРЕДЕЛЕНО, и это можно использовать в ГДЕ или ВЫБОР, чтобы отделить реальные заполненные значения от «ничего не выбрано». Это особенно критично в отчётах, где пустые значения не должны портить статистику.

Применение ТИПЗНАЧЕНИЯ в условном операторе ВЫБОР

Функция ТИПЗНАЧЕНИЯ очень часто используется внутри условного оператора ВЫБОР … КОГДА … ИНАЧЕ … КОНЕЦ. Такой приём позволяет прямо в запросе писать разную логику обработки одного и того же поля в зависимости от того, какого оно типа. В результате можно, например, рассчитать скидку, если покупатель — сотрудник, и не трогать сумму, если покупатель — внешний контрагент.

Пример расчёта скидки в запросе

Предположим, что скидка 10% предоставляется только сотрудникам, а все остальные покупают по полной цене. Тогда условный оператор в запросе может выглядеть примерно так:

ВЫБРАТЬ
	Реализация.Ссылка КАК Ссылка,
	Реализация.Контрагент КАК Контрагент,
	Реализация.СуммаДокумента КАК СуммаДокумента,
	ВЫБОР
		КОГДА ТИПЗНАЧЕНИЯ(Реализация.Контрагент) =
				ТИП(Справочник.Сотрудники)
			ТОГДА Реализация.СуммаДокумента - Реализация.СуммаДокумента * 0.1
		ИНАЧЕ Реализация.СуммаДокумента
	КОНЕЦ КАК СуммаСоСкидкой
ИЗ
	Документ.РеализацияТоваров КАК Реализация

Так логика скидки живёт прямо в запросе, не размазывается по коду обработки, и при этом надёжно опирается на проверку типа, а не на какие‑то флаги или текстовые признаки.

Небольшое отступление о читабельности запросов

Когда запросы начинают обрастать условиями по типам, ВЫБОРАми и вложенными выражениями, их очень легко превратить в нечитаемый «простыню». В практике помогает простое правило: сначала сделать диагностический вариант запроса с выводом всех ТИПЗНАЧЕНИЯ(…) отдельными колонками, посмотреть глазами, что реально лежит в базе, а уже потом затягивать эти же выражения в ГДЕ и ВЫБОР. Интересно, что иногда после такого диагностического этапа сама логика задачи меняется — видно, что данные живут не так, как задумано изначально.

Проверка типа параметров запроса

Проверять имеет смысл не только поля таблиц, но и параметры запроса, особенно если запрос используется в универсальных обработках и внешних отчётах. Параметр может прилететь строкой, ссылкой или вообще не быть установленным, и если сразу использовать его в сравнении, ошибка данных почти гарантирована. Гораздо надёжнее сначала в запросе определить тип параметра через ТИПЗНАЧЕНИЯ(&Параметр) и уже от этого плясать в ВЫБОР или условиях.

Пример с параметром произвольного типа

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

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

Если параметр не установлен или имеет неподходящий тип, условие в итоге даст ИСТИНА, и запрос просто не будет фильтровать по покупателю, что безопаснее, чем падение с ошибкой.

Использование типов в объединениях (ОБЪЕДИНИТЬ)

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

Пример подготовки данных к объединению

Представьте, что нужно собрать сводный отчёт по объектам разных видов, но при этом во всех выборках должна присутствовать колонка «Ключ» одного и того же ссылочного типа. Можно сделать вложенные запросы, в каждом из которых через ВЫБОР и ТИПЗНАЧЕНИЯ выбирать нужные варианты и приводить к единому типу с помощью ВЫРАЗИТЬ(… КАК Справочник.…). После этого объединение пройдёт без ошибок, а итоговый отчёт станет аккуратным и согласованным по колонкам.

Сочетание ТИПЗНАЧЕНИЯ и ВЫРАЗИТЬ

Функция ВЫРАЗИТЬ в запросах позволяет привести значение к указанному типу, если оно действительно может быть к нему приведено. В связке с ТИПЗНАЧЕНИЯ получается безопасный паттерн: сначала проверка типа, затем приведение. Такой подход спасает от ситуации, когда запрос «падает» на одной‑двух строках, в которых лежит значение другого типа, чем ожидалось.

Отбор по иерархическим справочникам и проверка ссылок

При работе с иерархическими справочниками часто приходится строить отборы по ссылкам с использованием В ИЕРАРХИИ и прочих операторов. Если реквизит составной и может содержать ссылки на разные справочники, то перед использованием В ИЕРАРХИИ разумно отфильтровать строки по оператору ССЫЛКА или через ТИПЗНАЧЕНИЯ = ТИП(Справочник.…). Это снижает риск неожиданных результатов, когда в отбор случайно попадают значения другого справочника.

Пример фильтра по иерархии с проверкой типа

Например, нужно выбрать все документы, где реквизит «Проект» может ссылаться и на иерархический справочник «Проекты», и на справочник «Сделки». Сначала фильтруем только проекты, затем применяем В ИЕРАРХИИ:

ГДЕ
	Документ.Проект ССЫЛКА Справочник.Проекты
	И Документ.Проект В ИЕРАРХИИ &КорневойПроект

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

Проверка типов в отчётах управленческого учёта

В прикладных решениях управленческий учёт часто строится на универсальных регистрах и наборах аналитик, где реквизиты намеренно имеют составные типы, чтобы модель была гибкой. В таких отчётах проверка типов в запросах — не «сладкая теория», а ежедневная рутина: иначе одни и те же колонки будут то строками, то ссылками, и результат отчёта станет непредсказуемым. Практика показывает, что грамотное использование ТИПЗНАЧЕНИЯ и ССЫЛКА резко снижает количество загадочных багов в отчётах.

Небольшое отступление про отладку запросов

Иногда самый быстрый способ найти ошибку в запросе — не читать его глазами, а временно добавить одну‑две диагностические колонки с ТИПЗНАЧЕНИЯ и выгрузить результат в таблицу значений. Пять минут — и видно, где тип «поехал», какое поле неожиданно стало NULL, а где пользователь умудрился ввести текст там, где вся логика ждала ссылку. Забавно, но иногда такие диагностические запросы потом превращаются в отдельные технические отчёты, которые с радостью используют администраторы.

Где ещё пригодится проверка типа значения

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

MoscowSoft: кому доверить сложные запросы

Если задача с типами в запросах вышла за рамки учебных примеров, всегда можно передать её тем, кто каждый день живёт в этом стеке. Компания MoscowSoft с 2019 года является партнёром фирмы 1С, а с 2023 года — аккредитованной ИТ‑компанией, и за это время успела вывести в реестр российского ПО более шестидесяти собственных программных продуктов. Такой опыт неизбежно отражается на подходе к запросам: там привыкли строить их так, чтобы выдерживали и большие объёмы данных, и сложную бизнес‑логику, и все капризы реальных пользователей.

Статья MoscowSoft о запросах как дополнительный ресурс

На сайте MoscowSoft можно найти подробный материал о механизме запросов 1С, синтаксисе и работе с объектными таблицами, который хорошо дополняет разговор о типах значений. В нём на примерах показывается, как устроены ссылочные таблицы, стандартное поле Ссылка и вложенные табличные части, а это именно та база, на которой потом легче понимать и проверку типов, и работу с операторами вроде ССЫЛКА.

Как тренироваться: маленькие задачки на типы

Освоить проверку типов проще всего на небольших тренировочных задачах: сделать запрос, который показывает тип каждого реквизита строки, затем запрос, который отбирает только строки со строковым признаком, затем запрос, который разносит значения по разным колонкам в зависимости от типа. Такие упражнения быстро прививают привычку не доверять типу «на глазок», а явно проверять его в условиях. В боевых конфигурациях эта привычка окупается многократно, особенно когда через год‑два к старым отчётам возвращаются с новыми требованиями.

Последнее отступление — уже почти философское

Если вдуматься, проверка типа значения в запросе — это не про «волшебную функцию», а про культуру работы с данными. Можно каждый раз надеяться, что пользователи заполнят всё «как надо», а администраторы никогда не поменяют настройки. А можно однажды принять, что данные живут своей жизнью, а задача разработчика 1С — смиренно и аккуратно учитывать это в каждом запросе. И тут возникает вопрос: в каком лагере вы хотите оказаться через пару лет — среди тех, кто правит отчёты по ночам, или среди тех, чьи отчёты просто работают?