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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(8) не поняли, что нужно
(9) да, все верно, куча правил
(10) Операция не разрешена в предложении ГДЕ

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

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

(12) Самый простой вариант знаешь какой?
Забить на условия в запросах и просто кодом статусы менять

Причем сами "правила" хранить в виде текстов "скриптов" в базе
Которые банально будут исполняться для каждого документа
В которых доступны нужные данные (сам документ и прочее) как входящие параметры, а на выходе функции (или процедуры с выходными параметрами) скрипта нужный статус(ы)

Один хрен чтобы поправить правила нужен будет спец - так логично делать сразу удобно и наиболее гибко
На ограничиваясь некими условиями/правилами

(12) Кто там нам чего-то не разрешает? Давайте разберём. Может Вы поделитесь прикладной частью, без этих "реквизит1=б"? Может Вы начнёте нас воспринимать, как советчиков, а не просто как восстановителей пароля?

(13)
по каждому документу куча заказов может быть и в цикле просто кодом будет долго.
ну и поддерживаемость такая себе.
самое быстрое было как раз запросом в том числе по макету. в итоге пока добавила новые условия по (3), остальное по старому алгоритму.
если бы была возможность текстовое условие подтянутое как результат запроса, пульнуть в условие запроса, было бы проще и красивее. и быстрее

(15) Может цикл будет нормально? Вы подумайте, Вы замерьте.