Как добавить логическое условие в запрос 1С для вывода Истины или Лжи?

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

Способ 1: Прямое логическое сравнение

Самый простой и элегантный способ получить логический результат (Булево) в запросе — это использование прямого сравнения. Для быстрой отладки подобных конструкций можно использовать специализированные консоли. Рассмотрим ситуацию, когда нам нужно просто проверить равенство реквизита какому-либо числу. Проанализируем пример кода:

ВЫБРАТЬ
    Реквизит = 1 КАК Результат
ИЗ
    Справочник.ВашСправочник

В данном случае система 1С самостоятельно вычислит выражение и вернет тип Булево. Это наиболее производительный вариант, так как он транслируется в простую логическую операцию на уровне СУБД. Однако такой метод не всегда удобен, если логика проверки становится сложнее или если требуется возвращать не только ИСТИНА/ЛОЖЬ, но и другие значения.

Способ 2: Использование оператора ВЫБОР

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

ВЫБРАТЬ
    ВЫБОР
        КОГДА Таблица.Реквизит = 1 ТОГДА ИСТИНА
        ИНАЧЕ ЛОЖЬ
    КОНЕЦ КАК Результат
ИЗ
    Документ.ВашДокумент КАК Таблица

Важно помнить о разнице между типом данных и его представлением. Если вы напишете "Истина" в кавычках, запрос вернет строку. Если же вы используете ключевое слово ИСТИНА без кавычек, запрос вернет логический тип. Мы рекомендуем всегда возвращать Булево, а текстовое представление («Да/Нет») настраивать уже на уровне вывода данных в отчет или форму.

Работа с перечислениями через ЗНАЧЕНИЕ

Часто условие в запросе должно опираться не на число, а на конкретное значение перечисления. Выясним причину, почему это вызывает сложности у новичков. Для обращения к объектам метаданных внутри запроса используется специальная функция ЗНАЧЕНИЕ(). Посмотрим на правильный пример реализации:

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

Обратите внимание, что имя перечисления и его значение пишутся через точку внутри скобок ЗНАЧЕНИЕ(). Это жестко заданная константа в коде запроса. Если же статус должен определяться динамически, правильнее будет передать его через параметр &Статус.

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

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

1. Определение типа: Если в первой ветке ТОГДА стоит булево значение, все поле станет булевым.
2. Использование ВЫРАЗИТЬ: Если вы возвращаете строки разной длины, обязательно используйте ВЫРАЗИТЬ(Поле КАК СТРОКА(10)), иначе система может обрезать данные по длине самого первого значения.
3. Обработка NULL: Если данные поступают из левого соединения (Left Join), удаленный реквизит может вернуть NULL. В этом случае прямое сравнение может дать непредсказуемый результат. Рекомендуем использовать ЕСТЬNULL(Реквизит, 0) = 1.

Замена удаленного реквизита (заполнение «дырки»)

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

ВЫБРАТЬ
    ...,
    ЛОЖЬ КАК УдаленныйРеквизитБулево,
    0 КАК УдаленныйРеквизитЧисло,
    "" КАК УдаленныйРеквизитСтрока
ИЗ
    РегистрНакопления.Продажи

Такой подход позволяет сохранить структуру результата запроса, даже если логика данных полностью изменилась. Это особенно полезно при работе со сложными схемами компоновки данных (СКД), где поля могут быть завязаны на настройки оформления.

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

С точки зрения СУБД (будь то SQL Server или PostgreSQL), конструкции Реквизит = 1 и ВЫБОР практически идентичны. Транслятор запросов 1С преобразует их в SQL-команды CASE WHEN. Однако стоит избегать вложенных запросов внутри условий КОГДА, так как это заставит сервер выполнять отдельное вычисление для каждой строки основной выборки, что значительно замедлит работу системы. Всегда старайтесь предварительно подготовить данные во временных таблицах, а затем выполнять простые сравнения.

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