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

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

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

Ниже разобраны рабочие способы проверки, особенности типов данных, поведение NULL и типичные ошибки с примерами кода на встроенном языке запросов 1С.

Как устроена «пустота» строки в базе 1С

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

Первое состояние — собственно пустая строка (значение ""). Второе — строка из одного или нескольких пробелов, которые пользователь ввёл случайно или намеренно, чтобы «обойти» обязательность заполнения. Третье — NULL: значение отсутствует вовсе, это типично для полей, полученных левым соединением, или для реквизитов составного типа. Четвёртое — строка неограниченной длины, где платформа накладывает ограничения на сравнение в запросе.

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

Базовая проверка: сравнение с пустой строкой

Самый простой и самый распространённый вариант — прямое сравнение поля с пустой строкой в секции ГДЕ:

ВЫБРАТЬ
Контрагенты.Ссылка,
Контрагенты.Комментарий
ИЗ
Справочник.Контрагенты КАК Контрагенты
ГДЕ
Контрагенты.Комментарий = ""

Такой запрос вернёт всех контрагентов, у которых комментарий — именно пустая строка нулевой длины. Это работает быстро, индексируемо и читаемо. Для большинства реквизитов с типом «Строка» фиксированной длины этого достаточно.

Обратная проверка — отбор только заполненных значений — записывается через неравенство:

ГДЕ
Контрагенты.Комментарий <> ""

Важный нюанс: если реквизит имеет составной тип (например, строка и число), сравнение со строкой корректно отработает только для строковых значений. Записи, где хранится значение другого типа, в выборку не попадут ни при = "", ни при <> "".

Проверка через ПОДСТРОКА и строки неограниченной длины

Для реквизитов с типом «Строка» неограниченной длины (например, многострочные поля вроде «Дополнительная информация») прямое сравнение в запросе может быть недоступно или работать неочевидно — платформа ограничивает операции с такими полями в условиях и группировках.

Универсальный приём — взять первый символ функцией ПОДСТРОКА и сравнить его с пустой строкой. Если первого символа нет, значит строка пустая:

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

Альтернативный вариант — привести поле к строке фиксированной длины через ВЫРАЗИТЬ и дальше сравнивать как обычно:

ГДЕ
ВЫРАЗИТЬ(Номенклатура.Описание КАК СТРОКА(1)) = ""

Оба приёма дают одинаковый результат для проверки на пустоту. ВЫРАЗИТЬ дополнительно полезен, когда поле нужно не только проверить, но и вывести в результат запроса в усечённом виде или использовать в соединении. Учтите, что оба подхода отсекают содержимое дальше указанной длины — для проверки на пустоту это неважно, но для поиска по подстроке выбирайте длину с запасом.

ГДЕ
	ПОДСТРОКА(Таблица.Поле, 1, 1) = ""

Учёт NULL и соединений таблиц

NULL появляется в запросе в трёх типовых ситуациях: левое соединение, по которому не нашлось пары; обращение к реквизиту через точку от NULL-ссылки; реквизит составного типа, где в записи хранится значение другого типа. Во всех этих случаях сравнение с пустой строкой вернёт не ИСТИНА и не ЛОЖЬ, а NULL — и запись просто выпадет из результата.

Классическая ошибка выглядит так: разработчик пишет левое соединение и отбирает контрагентов без телефона:

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

Контрагенты, у которых в табличной части вообще нет строк, в результат не попадут — для них КИ.Представление равно NULL. Правильное условие комбинирует обе проверки:

ГДЕ
КИ.Представление ЕСТЬ NULL
ИЛИ КИ.Представление = ""

Если нужно в выборке заменить NULL на пустую строку для дальнейшей обработки или вывода, используйте ЕСТЬNULL:

ВЫБРАТЬ
ЕСТЬNULL(КИ.Представление, "") КАК Телефон

Строки из пробелов и «визуально пустые» значения

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

В языке запросов 1С нет функции СокрЛП, поэтому отловить такие значения напрямую сложно. Практические варианты:

• Отобрать кандидатов условием ПОДСТРОКА(Поле, 1, 1) = " " — найдёт строки, начинающиеся с пробела, и дальше обработать их в коде;
• Выгрузить результат без фильтра и проверять значения в модуле через СокрЛП(Значение) = "";
• Исправить данные разово обработкой, которая обрезает пробелы, и дальше работать с чистыми данными.

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

Проверка в параметрах виртуальных таблиц и динамических списках

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

При передаче условия через параметр запроса пустая строка передаётся как обычное значение:

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

Такой подход удобен, когда условие формируется динамически: один и тот же запрос может искать как пустые, так и конкретные значения в зависимости от переданного параметра. Для необязательных отборов комбинируйте с конструкцией ВЫБОР КОГДА &ОтборЗадан ТОГДА ... или схемой компоновки данных.

Проверка результата и отладка

После написания запроса проверьте его на контрольных данных. Создайте в тестовой базе несколько записей: с пустой строкой, с пробелом, с NULL (для составного реквизита) и с заполненным значением. Прогоните запрос и сверьте, какие записи попали в результат.

Быстрый способ увидеть реальное содержимое поля — вывести в запросе длину и первый символ:

ВЫБРАТЬ
Контрагенты.Ссылка,
ПОДСТРОКА(Контрагенты.Комментарий, 1, 10) КАК НачалоСтроки,
ВЫБОР
КОГДА Контрагенты.Комментарий ЕСТЬ NULL
ТОГДА "NULL"
КОГДА Контрагенты.Комментарий = ""
ТОГДА "Пустая"
ИНАЧЕ "Заполнена"
КОНЕЦ КАК Состояние
ИЗ
Справочник.Контрагенты КАК Контрагенты

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

Частые вопросы