Как реализовать проверку динамических условий из макета в запросе 1С?

При разработке сложных систем автоматизации часто возникает задача динамического определения статусов объектов (например, заказов) в зависимости от параметров связанных документов. Когда условий становится много (десятки строк в макете или таблице), жесткое кодирование каждого правила превращается в проблему поддержки. Рассмотрим ситуацию, когда у нас есть макет с текстовыми описаниями условий, и нам необходимо заставить запрос 1С учитывать эти условия для изменения данных.

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

Основная сложность заключается в том, что язык запросов 1С является статическим. Мы не можем просто передать строку "Реквизит1 = 10" в параметр запроса и ожидать, что платформа выполнит её как часть логического выражения в блоке ГДЕ или ВЫБОР. Попытка сделать это напрямую приводит к ошибке "Операция не разрешена в предложении ГДЕ", так как СУБД ожидает логический результат (Истина/Ложь), а получает строку.

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

Решение 1: Программная генерация текста запроса

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

Разберем этот процесс по шагам:

1. Обходим строки макета, где хранятся условия.
2. Формируем фрагменты текста для блока ВЫБОР.
3. Заменяем шаблонную переменную в основном тексте запроса на собранный блок.

Посмотрим на пример реализации такого подхода:

// Подготовим текст для условий
ТекстВыбора = "";
Для Каждого СтрокаУсловия Из ТаблицаПравил Цикл
    // СтрокаУсловия.Условие содержит например: "Реквизит1 = &Значение1"
    ТекстВыбора = ТекстВыбора + "
    |    КОГДА ТипДокумента = &Тип" + СтрокаУсловия.Номер + " И (" + СтрокаУсловия.ТекстУсловия + ") 
    |    ТОГДА &Статус" + СтрокаУсловия.Номер;
КонецЦикла;

ТекстЗапроса = 
"ВЫБРАТЬ
|    Заказы.Ссылка,
|    ВЫБОР " + ТекстВыбора + "
|        ИНАЧЕ Заказы.Статус
|    КОНЕЦ КАК НовыйСтатус
|ИЗ
|    Документ.ЗаказПокупателя КАК Заказы";

Важный нюанс: Чтобы избежать ошибок при выполнении, убедитесь, что имена реквизитов в текстовых условиях (например, "Реквизит1") совпадают с именами полей в выборке запроса или псевдонимами таблиц.

Решение 2: Использование Системы компоновки данных (СКД)

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

Проанализируем ситуацию: СКД умеет парсить строки и сопоставлять их с набором данных. Рассмотрим алгоритм использования этого метода:

1. Создаем временную таблицу значений с данными документов и заказов.
2. Передаем эту таблицу в СКД как внешний набор данных.
3. Добавляем в схему вычисляемые поля, где в качестве выражения подставляем текст условия из макета.
4. СКД автоматически выполнит расчет для каждой строки таблицы.

Такой подход избавляет от необходимости вручную склеивать строки запроса и защищает от синтаксических ошибок SQL, так как проверку берет на себя процессор компоновки.

Решение 3: Декомпозиция через временные таблицы

Если условий в макете действительно много (более 40–50), один гигантский запрос с вложенными ВЫБОР КОГДА может стать «тяжелым» для оптимизатора СУБД. В этом случае проанализируем стратегию разделения:

Вместо одного запроса мы можем программно создать серию запросов, каждый из которых обрабатывает свою группу условий и помещает результат во временную таблицу. Затем мы просто объединяем (UNION ALL) результаты или соединяем их по ключу документа.

// Пример логики с временными таблицами
МенеджерВТ = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВТ;

// Шаг 1: Собираем все данные во временную таблицу один раз
Запрос.Текст = "ВЫБРАТЬ * ПОМЕСТИТЬ ВТ_ИсходныеДанные ИЗ ...";
Запрос.Выполнить();

// Шаг 2: Для каждого правила выполняем фильтрацию
Для Каждого Правило Из МассивПравил Цикл
    Запрос.Текст = "ВЫБРАТЬ Ссылка, &Статус ПОМЕСТИТЬ ВТ_Результаты ИЗ ВТ_ИсходныеДанные ГДЕ " + Правило.Условие;
    Запрос.УстановитьПараметр("Статус", Правило.НовыйСтатус);
    Запрос.Выполнить();
КонецЦикла;

Оптимизация и рекомендации

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

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

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

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