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

макет упрощенно выглядит так:
тип    условие                 новый статус
ртиу    "реквизит1 = а и реквизит2 = в"    статус2
ртиу    "реквизит1 = б и реквизит2 = ш"    статус3
птиу    "реквизит1 = с и реквизит5 = д"    статус5
птиу    "реквизит2 = п и реквизит3 = т"    статус1
заявка    "реквизит4 = истина"        статус4

если забить в макете текстовые условия, то при выполнении запроса валится ошибка
как можно реализовать такое?

(0) Схема компоновки данных в помощь, и не надо никаких макетов.
Точнее схема и будет макетом.

а можете немного конкретизировать, как именно?
пока не понимаю, как из результата запроса сделать сам его текст.

ВЫБОР КОГДА ... ТОГДА
КОНЕЦ

(3)
крайний вариант - в реальном макете строк 40 и колонок больше. очень раздутый запрос получится :(

Тебе же сказали СКД и даже условия отбора можно программно менять
Откуда их брать пофиг, лично я предпочел бы хранить в базе
Заполнять первоначально да из макетов или предопределенных/кода
А затем возможность менять в базе
И чтобы оно использовалось как правила/условия через СКД

(4) генерите запрос программно

(5)
скд сама по себе настолько обширная, что сказать: пользуйте скд - это все равно, что послать.
что именно в скд, где там? как запихать текст условий, полученный из макета в сам текст запроса, чтоб они проверялись?

(7) там макета вообще не надо, в СКД есть волшебная вкладочка "Отбор", где любые по сути условия можно прописать, гораздо круче чем в макете. Запрос самый общий исходный в источнике данных.

(8) У ТС задачка не просто отбор а по сути некие правила, которые отвечают за изменение статуса
Поэтому логично их хранить в базе

А еще сделать кнопочку проверки этих правил, на их непротиворечивость и т.д.
Чтобы не получилось что одновременно два разных статуса подходят для состояния документа

(0) Какая ошибка?

(9) там может и 2 статуса, там же надо заказы отбирать по статусам, поэтому статусов несколько может под вид докумена