Как правильно написать условие запроса, что реквизит у документа вообще существует?
(в запросе выбираются из регистра самые разные документы, и у некоторых из них этого реквизита вообще нет)
[CODE]ВЫБОР
    КОГДА ТоварыНаСкладахОбороты.Регистратор.Партнер Реквизит вообще существует ТОГДА то-то
    ИНАЧЕ то-то
КОНЕЦ[/CODE]
Нужно, чтобы выбирались все документы, у которых нет такого реквизита, и все документы, у которых он есть и Партнер не в СпискеЗначений.

-------------------------------------------------------------------------------

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

-------------------------------------------------------------------------------

Пока что вышел из положения таким нагромождением:
[CODE]ВЫБОР
    КОГДА ТоварыНаСкладахОбороты.Регистратор.Партнер.Ссылка В (&СписокЗначений)
            И (ТИПЗНАЧЕНИЯ(ТоварыНаСкладахОбороты.Регистратор) = ТИП(Документ.РеализацияТоваровУслуг)
                ИЛИ ТИПЗНАЧЕНИЯ(ТоварыНаСкладахОбороты.Регистратор) = ТИП(Документ.ВозвратТоваровОтКлиента)
                ИЛИ ТИПЗНАЧЕНИЯ(ТоварыНаСкладахОбороты.Регистратор) = ТИП(Документ.ПоступлениеТоваровУслуг)
                ИЛИ ТИПЗНАЧЕНИЯ(ТоварыНаСкладахОбороты.Регистратор) = ТИП(Документ.ВозвратТоваровПоставщику))
        ТОГДА ЛОЖЬ
    ИНАЧЕ ИСТИНА
КОНЕЦ[/CODE]

Запрос в 1с не может обращаться к метаданным

Посмотри в сторону не того, чтобы по документам шарится, а возможно есть реквизит у оборотов типа движение "внешнее" или "внутреннее", у внутренних "Партнера" вообще как класса м.б. не быть...
?

КОГДА НЕ ТоварыНаСкладахОбороты.Регистратор.Партнер ЕСТЬ NULL

(3) не надо так.
Передавайте лучше в запрос массив типов регистраторов, которые имеют поле партнер.

Последний вариант в (0) близок к истине, но еще не торт

(4) может ты и прав, так будет быстрее

"КОГДА ТоварыНаСкладахОбороты.Регистратор.Партнер.Ссылка В (&СписокЗначений)" // Зачем тебе обороты, если ты обращаешься к регистратору? Обращайся тогда уж к реальной таблице движений

(0) Создавай запрос программно (например, просто замена части запроса).
А пока запросы у тебя слишком кривые, что стоит только эта строка:
"КОГДА ТоварыНаСкладахОбороты.Регистратор.Партнер.Ссылка В (&СписокЗначений)"

Возможность в виртуальной таблице оборотов периодичность по регистратору включить и выбирать регистратор - это же троллинг со стороны 1С знатный

(0) можно так

Попытки

Твой запрос

Исключение
Значит нет реквизита
Конецпопытки

Документ.Реквизит Ссылка Справочник.НужныйСправочник
в Когда Тогда или в Где

Капец


НЕ ЕСТЬNULL(ТоварыНаСкладахОбороты.Регистратор.Партнер, Неопределено) В(&СписокПартнеров)


есть null тоже должно отработать

(+1) всегда делаю это на уровне кода
ТекстЗапроса = ТекстЗапроса  +
?( Метаданные.Документы[ ИмяДок ].Реквизиты.Найти( ИмяРек ) = Неопределено, " <> ", " Док.ИмяРек " )

(12) Спасибо!

Такой вариант работает:
ВЫБОР
    КОГДА ЕСТЬNULL(ТоварыНаСкладахОбороты.Регистратор.Партнер, НЕОПРЕДЕЛЕНО) В (&СписокЗначений)
        ТОГДА ЛОЖЬ
    ИНАЧЕ ИСТИНА
КОНЕЦ

(15) А чем тебя просто (12) не устраивает,  без ВЫБОР?

(14) Как в лужу пукнул

+(17) Впрочем, как и половина отписавшихся в ветке

(18) Рома, откуда столько спеси? Или это у всех хозяев маленьких франчайзи?

(15) работать то он работает, но не оптимально

если хотите оптимально тогда не через ВЫБОР КОГДА, а через ОБЪЕДИНИТЬ и УСЛОВИЕ

(19) Ну вот смотри
В (0) человек накуролесил — это ладно, бывает, он потому и обратился к коллективному разуму, мол помогите, не могу сделать
Ну, пустое в (1) пропускаем
(2) почти по делу, если учитывать, что Злопчинский не кодер, могло бы и сработать
(3), (4), (5), (6) по делу, хотя насчет такой рекомендации бабушка еще надвое сказала, лучше так или нет, если говорить не только про оптимизацию производительности, но и, как минимум, про читабельность
(7), (8), (9), (10) вообще не в кассу
(11) по делу, хотя рекомендация не уверен, что верная
И после всего написанного веселее всего (14), который даже (0) не прочитал
Ну то есть по делу где-то половина и есть

А реакция моя — это не спесь, а чувство отвращения к тем, кто пишет всякую ерунду, когда по делу написать нечего, а что-нибудь написать хочется

(22) не на двое

Тогда (3) также неоптимально как и у тебя, зато читабельно

(20) Речь и не шла про оптимальность
Оптимальнее всего, думаю, было бы сделать то, что делает платформа 1С, то есть написать запрос, максимально приведенный к виду SQL, то есть самому сделать всякие левые соединения по типам регистраторов, разложить все по полочкам, из одних регистраторов брать поле, из других не брать и т. д.
Но в том-то и дела, что производительность — это один из критериев, далеко не всегда самый важный
Если речь идет про узкое место, где реальная проблема из-за скорости выполнения запроса, то это один случай
А если это код отчета, который пользователь будет запускать раз в пятилетку и ему подождать пару лишних миллисекунд не в падлу и база при этом не упадет от такого запроса, то тут уже важно и то, насколько такой код читабелен, и сколько ТС за его реализацию денег попросит и еще некоторые вещи, которые могли бы быть менее важны

(23) Так (3) — это как у меня и есть, в чем разница-то кроме ВЫБОРа?

но обычно делают как-то так если уж так хотят добиться оптимальности.  в конструкции ГДЕ следует написать следующее

Конструкция ВЫБРАТЬ

ГДЕ ВЫРАЗИТЬ(Регистратор.Контрагент КАК Документ.РеалиазацияТоваров).Контрагент В (СписокКонтр)

ОБЪЕДИНИТЬ

.........

ГДЕ ВЫРАЗИТЬ(Регистратор.Контрагент КАК Документ.ПоступлениеТоваров).Контрагент В (СписокКонтр)

а оптимальность здесь в следующем ВЫРАЗИТЬ составной тип превращает в конкретный тип и на СКЛ уйдет план к одной таблице а не 30 если регистратор используется у стольких документов.

(25) не нужен isnull, не нужно неопределено, не нужен список значений

Только is null. Всё. Но не оптимально

В (4) наиболее оптимальное решение

(29) наиболее оптимально это через ОБЪЕДЕНИТЬ и УСЛОВИЕ

(26) это если решать задачу, что будут передан еще и условие на контрагентов. А если расматривать только как задачу существования реквизита - то как в (4)

Просто условие ГДЕ ТипЗначения(Регситратор) В (СписокТиповИспользующихРеквизитКонтрагент)

(28) Ты бы прочитал (0) что ли повнимательнее, ту часть, где про "Партнер не в СпискеЗначений"

(22) ты типовые современные открывал?
Там вполне себе передается массив допустимых типов и все нормально читается

(33) Типовые — это на всю Россию, ясен пень, что там производительность гораздо важнее и бюджет больше, чем в отдельно взятой фирме на три калеки

(34) Рома начал отмазываться

(16) Да просто для наглядности.

Изменил на
НЕ ЕСТЬNULL(ТоварыНаСкладахОбороты.Регистратор.Партнер, НЕОПРЕДЕЛЕНО) В (&СписокЗначений)

(24) Именно так.
Высокое искусство - это, конечно, замечательно.
Только клиенты почему-то не собираются за него платить.
Что с них взять? Тёмные невежественные люди...
Когда меня пригласят на работу в газпром, обязательно начну приобщаться к высокому искусству.

А этот код, кстати, нужен для еженочной автоматической выгрузки.
Время выполнения несколько секунд.
Хотя даже если бы он выполнялся несколько часов, это клиента совершенно не интересовало бы, потому что пользователи вручную его не запускают.

Я ещё не сказал о том, кусок кода, про который я спросил, использую в секции ГДЕ запроса.
Вообще жуткая неоптимальность.

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