Как исправить ошибку «Ожидается ТОГДА» в пользовательских полях Универсального отчета 1С?

При работе с Универсальным отчетом в системе 1С:Предприятие пользователи часто сталкиваются с необходимостью создания собственных вычисляемых колонок. Для этого используются «Пользовательские поля», где можно прописать логику с помощью функции ВЫБОР. Однако синтаксис этих полей отличается от стандартного языка запросов 1С, что приводит к неочевидным ошибкам, таким как «Ожидается ТОГДА». В этой статье мы подробно разберем, почему возникает эта ошибка и как правильно группировать условия.

Причина возникновения ошибки в пользовательских полях

Рассмотрим ситуацию: вы пытаетесь написать условие, в котором одно и то же поле должно соответствовать одному из нескольких значений. Проблема заключается в том, что парсер (обработчик текста), который анализирует формулы в пользовательских полях интерфейса, работает менее гибко, чем компилятор запросов в конфигураторе. Проанализируем типичную ошибку: когда вы добавляете оператор ИЛИ, система перестает понимать, где заканчивается блок условий и начинается блок исполнения ТОГДА.

Основные причины сбоя парсера:

1. Некорректная расстановка скобок: Сложные логические выражения требуют явного выделения приоритетов.
2. Переносы строк: В интерфейсных настройках 1С переносы строк в формулах иногда интерпретируются как конец инструкции.
3. Смешение типов данных: Если сравниваются значения разных типов без приведения.

Решение 1: Использование нескольких конструкций КОГДА

Если оператор ИЛИ вызывает ошибку, самым простым и надежным способом будет разбить условия на отдельные блоки КОГДА. Это гарантирует, что система корректно обработает каждое сравнение. Посмотрим на пример реализации:

ВЫБОР
    КОГДА [Счет Кт.Код счета] = "90.01.1" ТОГДА "Доходы"
    КОГДА [Счет Кт.Код счета] = "91.01"  ТОГДА "Доходы"
КОНЕЦ

В данном случае мы продублировали результат для разных условий. Этот метод наиболее стабилен, так как исключает двусмысленность при чтении формулы программой. Разберем подробнее: каждое КОГДА проверяется последовательно до первого совпадения. Если первое условие ложно, 1С переходит ко второму.

Решение 2: Группировка условий с помощью скобок

Если необходимо использовать именно ИЛИ (например, при сочетании разных полей в одном условии), критически важно использовать скобки. Проанализируем ситуацию: парсер ожидает увидеть ТОГДА сразу после первого логического выражения. Чтобы «объяснить» системе, что условие продолжается, мы заключаем весь блок в скобки.

Рассмотрим правильный синтаксис:

ВЫБОР
    КОГДА ([Счет Кт.Код счета] = "90.01.1" ИЛИ [Счет Кт.Код счета] = "91.01")
    ТОГДА "Доходы"
КОНЕЦ

Важный нюанс: Старайтесь писать всю конструкцию КОГДА (...) ТОГДА в одну строку, если это позволяет объем выражения. Это минимизирует риск ошибки распознавания символов переноса.

Решение 3: Оператор В (ИН) для списков значений

Когда одно поле проверяется на вхождение в список конкретных значений, использование ИЛИ — не самый эффективный путь. В Системе компоновки данных (СКД), на которой базируется Универсальный отчет, предусмотрен оператор В. Это аналог SQL-оператора IN.

Посмотрим на пример, который значительно сокращает код и снижает вероятность ошибки:

ВЫБОР
    КОГДА [Счет Кт.Код счета] В ("90.01.1", "91.01")
    ТОГДА "Доходы"
КОНЕЦ

Обратите внимание на синтаксические особенности:

• Поле заключается в квадратные скобки: [НазваниеПоля].
• Список значений обязательно берется в круглые скобки.
• Значения внутри списка разделяются запятыми.
• Строковые значения (коды счетов) всегда пишутся в кавычках.

Проверка нескольких разных полей (Оператор И)

Сложности возникают и при использовании логического И. Например, нам нужно проверить не только счет, но и конкретную аналитику (субконто). Выясним причину ошибки: часто пользователь забывает, что каждое условие должно быть завершенным сравнением.

Рассмотрим пример правильной проверки двух разных полей:

ВЫБОР
    КОГДА ([Счет Кт.Код счета] = "91.1" И [Вид субконто1 Кт.Наименование] = "Прочие доходы и расходы")
    ТОГДА "Доходы"
КОНЕЦ

Здесь также применяются двойные скобки, если условий становится больше двух. Проанализируем конструкцию: КОГДА ((Условие1 И Условие2) ИЛИ Условие3) ТОГДА. Такой подход позволяет строить сложную иерархическую логику в отчетах.

Особенности работы с NULL и пустыми значениями

При написании формул в вычисляемых полях часто забывают о том, что данные могут быть не заполнены. Если поле, которое вы проверяете, содержит NULL, то сравнение [Поле] = "Значение" вернет не ложь, а неопределенный результат, который может «сломать» всю логику ВЫБОР.

Для предотвращения таких ситуаций рекомендуется использовать функцию ЕстьNULL. Хотя в интерфейсных пользовательских полях она не всегда доступна в явном виде, хорошим тоном считается предварительная проверка на заполненность или использование оператора ПОДОБНО для строковых полей, так как он более устойчив к отсутствию данных.

Полезные советы по синтаксису пользовательских полей

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

1. Регистр операторов: Хотя официально 1С нечувствительна к регистру в формулах, практика показывает, что написание операторов ВЫБОР, КОГДА, ТОГДА, ИЛИ заглавными буквами помогает парсеру быстрее и точнее обрабатывать текст.
2. Квадратные скобки: В пользовательских полях, создаваемых через кнопку «Настройки» — «Пользовательские поля», названия полей всегда должны быть в квадратных скобках. Не путайте это с «Вычисляемыми полями» в конфигураторе, где скобки не нужны.
3. Минимизация сложности: Если логика становится слишком громоздкой (более 5-7 условий), постарайтесь перенести ее на уровень конфигуратора в схему компоновки данных. Интерфейсные поля предназначены для простых преобразований.
4. Типизация значений: Убедитесь, что вы сравниваете строку со строкой, а число с числом. Код счета в 1С — это всегда строка, поэтому использование кавычек "90.01" обязательно.

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