Проверка на заполненность в запросах 1С: полное руководство

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

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

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

Фундаментальные понятия пустоты в 1С

Прежде чем переходить к синтаксису, необходимо четко усвоить природу пустого значения в контексте СУБД, используемой платформой. В мире SQL и, соответственно, в запросах 1С, отсутствие значения обозначается термином NULL. Это не ноль, не пустая строка и не ложь. Это состояние «неизвестно» или «не применимо».

Когда вы создаете новый документ или справочник, некоторые реквизиты могут оставаться незаполненными. В базе данных физически в этих ячейках ничего не хранится, там стоит маркер NULL. Если вы попытаетесь сравнить такое поле с чем-либо обычным способом, результат будет непредсказуемым для новичка. Любое сравнение NULL с любым значением (даже с другим NULL) возвращает НЕИЗВЕСТНО, а не ИСТИНА или ЛОЖЬ.

Особое внимание стоит уделить ссылочным типам данных. Если в документе не указан контрагент, то в поле хранится NULL, а не пустая ссылка. Однако, если вы программно запишете в поле пустую строку для текстового реквизита, это уже будет не NULL, а конкретное значение длиной 0 символов. Различать эти состояния критически важно при формировании условий отбора.

⚠️ Внимание: Никогда не используйте оператор = для проверки на пустоту. Выражение Где Поле = NULL всегда вернет пустую выборку, так как в логике баз данных NULL не равен самому себе. Используйте только специализированные операторы ЕСТЬ NULL или НЕ ЕСТЬ NULL.

Синтаксис операторов ЕСТЬ NULL и НЕ ЕСТЬ NULL

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

Оператор ЕСТЬ NULL используется, когда вам нужно найти записи, где конкретное поле не заполнено. Это часто требуется для поиска документов, по которым еще не провели оплату, или товаров, у которых не указан штрихкод. Синтаксически это выглядит очень лаконично и читается как обычный русский текст.

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

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

Если вам нужно проверить заполненность нескольких полей одновременно, необходимо использовать логические связки И или ИЛИ. Комбинирование условий позволяет строить сложные фильтры, точно соответствующие бизнес-требованиям заказчика.

⚠️ Внимание: Операторы чувствительны к типу данных. Проверка ЕСТЬ NULL для числового поля сработает корректно, но если в этом поле записан ноль, условие не выполнится. Ноль — это число, а NULL — это отсутствие числа.

Альтернативные методы проверки через функцию ИСЛ

Хотя операторы ЕСТЬ NULL являются предпочтительными, в арсенале разработчика 1С есть и другие инструменты. Функция ИСПОЛЬЗУЕТСЯВИДЕО (или чаще просто проверка через ИспользуетВид в коде) в запросах трансформируется в использование функции ИСТ или аналогов, но классическим «обходным» путем считается применение функции ИЗЛЕЧИТЬ или сравнение с результатом функции ИЗЛЕЧИТЬ.

Однако, самым близким аналогом, который иногда встречается в старом коде или специфических задачах, является конструкция с использованием функции ИЗЛЕЧИТЬ (в англоязычной версии ISNULL, но в русском запросе 1С такой функции нет в явном виде для условий, есть ИЗЛЕЧИТЬ для замены). Более релевантным примером альтернативы является проверка через приведение типов или использование временных таблиц, но это избыточно.

Тем не менее, существует метод проверки через функцию ИЗЛЕЧИТЬ в сочетании с подстановкой значения. Если мы заменим NULL на какое-то заведомо невозможное значение, мы сможем отфильтровать его обычным сравнением. Но это плохая практика, так как она усложняет чтение кода и может привести к ошибкам, если «невозможное» значение вдруг появится в базе.

Более грамотной альтернативой в сложных вычислениях является использование оператора ИЗЛЕЧИТЬ (или ISNULL в диалекте SQL Server, если пишете нативный запрос, но в 1С это ИЗЛЕЧИТЬ не работает в условии ГДЕ напрямую как фильтр NULL). В запросах 1С единственной полноценной альтернативой является логика приложения, но внутри запроса лучше придерживаться канона.

Почему не стоит использовать замены значений?

Замена NULL на 0 или пустую строку перед сравнением заставляет СУБД выполнять дополнительные вычисления для каждой строки. Это отключает использование индексов по полю и приводит к полному сканированию таблицы (Table Scan), что критически замедляет работу на больших объемах данных.

Специфика работы со ссылочными и табличными частями

Проверка заполненности в табличных частях документов имеет свои особенности. Часто возникает задача отобрать документы, в которых есть хотя бы одна строка с незаполненным реквизитом, или, наоборот, документы, где все строки заполнены. Здесь вступает в игру логика соединения таблиц (JOIN).

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

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

• 🔍 Всегда проверяйте наличие самой ссылки перед проверкой её реквизитов, если логика бизнеса требует строгой последовательности.
• 📉 Используйте ЛЕВОЕ СОЕДИНЕНИЕ в паре с ЕСТЬ NULL для поиска отсутствующих связанных объектов (например, товары без цен).
• 🚀 Избегайте проверок заполненности в условиях ПО при соединениях, если это возможно — переносите их в секцию ГДЕ для лучшей читаемости.

Рассмотрим пример поиска документов без спецификации. Мы соединяем документ с его табличной частью. Если строк нет, поля табличной части станут NULL, и фильтр ЕСТЬ NULL сработает идеально.

Тип проверки	Оператор	Производительность	Рекомендуемое использование
Прямая проверка	ЕСТЬ NULL	Высокая (использует индексы)	Основной метод фильтрации
Отрицание	НЕ ЕСТЬ NULL	Высокая	Исключение пустых записей
Левое соединение	ЛЕВОЕ СОЕДИНЕНИЕ + ЕСТЬ NULL	Средняя (зависит от объема)	Поиск отсутствующих связей
Функция ИЗЛЕЧИТЬ	ИЗЛЕЧИТЬ(Поле, 0) = 0	Низкая (требует вычислений)	Только для специфических расчетов

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

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

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

Сложности возникают при использовании составных условий. Если вы пишете ГДЕ (Поле1 НЕ ЕСТЬ NULL) ИЛИ (Поле2 НЕ ЕСТЬ NULL), оптимизатору может быть сложно построить эффективный план, и он выберет полное сканирование. В таких случаях иногда выгоднее разбить запрос на два отдельных и объединить результаты через ОБЪЕДИНИТЬ.

⚠️ Внимание: Интерфейс и механизм работы оптимизатора запросов могут меняться в новых версиях платформы 1С:Предприятие. Всегда сверяйте план выполнения запроса через консоль запросов или технологический журнал при работе с критически важными отчетами.

Типичные ошибки и способы их устранения

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

Другая частая проблема связана с агрегатными функциями. Функции СУММА, МИНИМУМ, МАКСИМУМ игнорируют значения NULL. Если вы суммируете поле, в котором у половины записей стоит NULL, результат будет верным (сумма только заполненных), но если там будут нули, они тоже участвуют в сумме. Путаница между этими состояниями ведет к финансовым расхождениям.

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

Практические примеры из жизни разработчика

Рассмотрим реальную задачу: необходимо вывести список контрагентов, у которых не заполнен ИНН, но при этом они не являются физическими лицами (у физических лиц ИНН может не запрашиваться, но в нашей базе они помечены флагом). Здесь нам понадобится комбинация проверки на NULL и обычного сравнения.

Второй пример: анализ полноты номенклатуры. Менеджеры жалуются, что в прайс-листе для клиентов попадают товары без картинок и без описания. Нам нужно найти такие позиции. Мы проверяем два поля: Картинка и Описание. Если хотя бы одно из них ЕСТЬ NULL, товар попадает в список на доработку.

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

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

Можно ли использовать оператор ISNULL из SQL в запросе 1С?

Нет, в языке запросов 1С:Предприятие синтаксис стандартизирован и не поддерживает нативные функции конкретной СУБД (например, T-SQL или PL/SQL) напрямую в тексте запроса. Необходимо использовать конструкции платформы: ЕСТЬ NULL, НЕ ЕСТЬ NULL или функцию ИЗЛЕЧИТЬ для замены значений, но не для фильтрации.

Почему запрос с "НЕ ЕСТЬ NULL" работает медленно на большой базе?

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

Как проверить, что ссылка не пустая, но объект по ней не проведен?

Сначала проверьте саму ссылку на НЕ ЕСТЬ NULL, чтобы убедиться, что она указана. Затем, если у объекта есть реквизит «Проведен» или «ПометкаУдаления», добавьте соответствующие условия в секцию ГДЕ через точечную нотацию (например, Документ.Проведен = ИСТИНА).

Влияет ли проверка на NULL на блокировку записей?

Сама по себе проверка на NULL в режиме «Только чтение» не устанавливает блокировок. Однако, если запрос выполняется в режиме управляемых блокировок и предполагает последующую запись, механизм блокировок сработает стандартным образом, независимо от условия фильтрации.