Есть запрос. Приблизительно такой:

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

И тут у меня возникает такое ощущение, что если ИСТИНА будет и в &ВыводитьВсе, и в &ВыводитьПоСотруднику, и в &ВыводитьПоПользователю, то все эти условия будут выполняться (ну кроме ИНАЧЕ, естественно). Я не прав?

(0) эээ

это не так делается

(0) слишком много параметров. Вообще для этого отборы есть. Но если хочется параметрами, то надо делать отдельные условия.

пиоверяй на пустое значение

(0) плохое решение, очень плохое

первое успешное (истина) выполнится - остальные нах

(0) Ты не прав.

это как Если, какое первое истина, то и отработает, остальное нет

(0) прав. но это можно проверить на форме отчета, чтобы пользователь не наставил неправильных комбинаций флажков

(6) Кто же спорит? ) Это всего лишь попытка быстро переписать решение из оригинала, чтобы можно было понять основную суть.
А в реальности там идет сравнение типа

КОГДА &ВыводитьПоГруппеСотрудников1
ТОГДА Сотрудник в(&СписокСотрудников1)
КОГДА &ВыводитьПоГруппеСотрудников2
ТОГДА Сотрудник в(&СписокСотрудников2) ,  и т.д.

Т.е. в самих условиях все правильно, тут просто где-то прочитал, что конструкции в запросе "ВЫБОР КОГДА КОГДА ИНАЧЕ" не то же самое, что конструкции в коде "ЕСЛИ ИНАЧЕЕСЛИ ИНАЧЕ", вот и спросил.

(11) все равно это бред

(11) Условия проверяются по порядку, если какое-то сработало далее условия не проверяются.

(12) Почему бред?

(3) Отборы нужны, если понятно, какой отбор нам нужен. А тут мы в поисках.

В любом случае, можно сделать несколько отдельных запросов по разным условиям, а потом в событии ПриСозданииНаСервере подменять запрос тем, который нам нужен.

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

(13)(9) Спасибо, вот именно это я и хотел уточнить.

(14) В динамическом списке лучше установить отбор штатными методами, а не мудрить с запросом

Например, в БСП есть процедура
ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка

(17)это очень тупой метод он в рабочих местах самое слабое место дико тормозит

(18) Даже и не знаю, что сказать? Может не в бобине дело?

(19) Ну открой типовую и глянь - ох или не надо делать более одного отбор??? там ведь в цикле вначале один затем второй

(20) Вы к тому, что указанный метод сначала рекурсивно ищет, а не установлен ли уже ранее отбор по этому полю и только потом меняет или добавляет его? А по мне - так правильно делает.
Но, если вы уверены, что такого отбора нет, можете сразу использовать ОбщегоНазначенияКлиентСервер.ДобавитьЭлементКомпоновки или, если вам этот элемент отбора уже известен используйте ОбщегоНазначенияКлиентСервер.ИзменитьЭлементыОтбора
В общем, всё в ваших руках :)

О, пошла битва магов!

кто подскажет отборы в СКД на каком уровне работают?

(23) Про уровни группировок спрашиваешь?

(24) Про все
Если в отборе пользователь нахреначил сложных условий с группами и через "." объектов-ссылок

Где и как реально это исполняется?
Сервер 1С сам крутит или все же запросы дополняет к СУБД?

(23) в субд прилетает условие

(21) Я к тому что в типовом рм при настройке списка благодаря этому любой отбор работает пол   минуты на пустом месте

(26) я столкнулся с тем что если в отборе добавлять условия через точку
например Объект.Организция = Значение
где объект это Измерение РС
то пипец тормозит

а если это же сделать в исходных запросах (в ИсточникДанных1) то нет

(0) "ИНАЧЕ Ответственный = ЛОЖЬ (т.е. ничего не выводить)
КОНЕЦ"
--------------------
Ответственный тут при чем? если не надо ничего выводить - просто "... ИНАЧЕ ЛОЖЬ КОНЕЦ"

(28) Особенно если измерение составных типов, да?

(30) угадал ))

(31) юзайте ВЫРАЗИТЬ