В запросе пришлось добавить ЕСТЬNULL

    "ВЫБРАТЬ
    |    ТБ.Цена КАК БазоваяЦена,
    |    ТЦ.Цена КАК Цена,
    |    &НоваяЦена КАК НоваяЦена,
    |    ТБ.Номенклатура КАК Номенклатура,
    |    ТБ.Характеристика КАК Характеристика,
    |    ТБ.ЕдиницаИзмерения КАК ЕдиницаИзмерения
    |ИЗ
    |    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ) КАК ТБ
    |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦен) КАК ТЦ
    |        ПО ТБ.Номенклатура = ТЦ.Номенклатура
    |            И ТБ.Характеристика = ТЦ.Характеристика
    |ГДЕ
    |    ЕСТЬNULL(ТЦ.Цена, 0) <> &НоваяЦена";    


Новая цена - это сложное условие, зависящее от ТБ.Цена.

По сути, если старая цена ТЦ.Цена <> новой расчетной цене, то по этой позиции должна записываться новая цена.

Но не работало, попадали только те записи, где была хоть одна запись по цене, т.е. перерасчет цен работал, а добавление новой цены не работало.

Почему так? Оно что, считало что NULL <> Произвольное число - всегда истина?

Про именование переменных, это вечный спор о вечном. :-)

(169) и почему же?

(172) ответ в (40), (46), (47).

(172) Я ответил на вопрос: Почему?

(171) это про комменты
А именование +- регламентировано

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

По запросам ещё проще. Конструкции стандартные, количество операторов наверное меньше чем команд в ассемблере.
Комментировать особо не чего. Тут практически не алгоритм, а описание результата. Если таблиц штук пять или меньше и связи простые, то фиолетово какие будут имена у таблиц. FROM всегда где-то рядом. Можно просто т1, т2...
Если есть вложенная одинокая таблица в подзапросе, то внутри можно просто т. По умолчанию предлагает ВложенныйЗапрос, но проще просто т.

Т.е.
Выбрать
     ИмяТаблицы1.Поле1
    ,ИмяТаблицы2.Поле1
ИЗ
     ИмяТаблицы1 как ИмяТаблицы1
    ,(выбрать т.Поле1 из КакаяТоТаблица как т где т.Поле1 = 0) как ИмяТаблицы2

Я про алиас "т" таблицы "КакаяТоТаблица", который внутри подзапроса.

(176) "По запросам ещё проще" - ага, когда 100500 таблиц во менеджерах временных таблиц. А потом еще всякие вложенные таблицы внутри вложенных таблиц и все обезличенные - ммм какая красота, как же все легко читается и понятно, что автор хотел в этом запросе)

(177) Прикинь и это только в 1С такой треш. А знаешь почему? SQL стандарт 10-ти летней давности. + Недостаток функционала в тех же функциях. Математические функции только добавили.

Это я к чему. Ко скольким физическим таблицам обращается этот километровый запрос?

(176)  я не спрашивал, нужны ли комментарии

(179) Извини, но я так понял твой пост.

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

(181) Какая ещё сложная логика? А чем речь?

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

вот такое авно в том или ином виде растеклось по 100500 модулям в типовых конфигурациях


    Сумма * ВЫБОР
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18_118)
            ТОГДА 0.18
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10_110)
            ТОГДА 0.1
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС0)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.БезНДС)
            ТОГДА 0
        КОГДА Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20)
                ИЛИ Номенклатура.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20_120)
            ТОГДА 0.2
        ИНАЧЕ 0
    КОНЕЦ КАК СуммаНДС

(184) это вы еще лесенку с родителями не скинули))

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

(183) "портянки выбор когда... тогда..." - Для простых конструкций есть короткая конструкция IIF(Условие, РезультатЕслиИстина, РезультатЕслиЛожь), но только не в 1С.
"переливания данных через пятнадцать временных таблиц" - это как правило из-за отсутствия оконных функций, а так же простых функций без временных таблиц RANK(),  DENSE_RANK(), ROW_NUMBER().

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

(186) Нет. Подобные задачи не в 1С тоже решают с помощью SQL запроса, но выглядит это всё компактно и понятно.

(187) какие "подобные"? я не говорил ни о каких то конкретных задачах

(187) так про то и речь, что 1сный SQL чрезвычайно ограниченный. На кой в него пихать то, что гораздо проще сделать на встроенном языке? Код на встроенном языке обладает несравнимо большей гибкостью, чем запросы. Ну получи ты данные из табличек, соедини их, а потом во встроенном языке прогони через код

(188) Любые подобные. Не решает же 1С какие-то задачи, которые решает только 1С. Скорее наоборот - 1С не решает многих задач, которые решают не на 1С. Собственно так можно не только про 1С говорить. Всегда есть какой-то аналогичный инструмент, который может решать аналогичные задачи.

(189) Запрос даст в общем случае более быстрый результат. Бывают какие-то исключения, но это как правило задачки олимпиадные, которые в промышленном коде не решают. :-)

(191) например, что запрос может ускорить в (184)?

(190) вообще слово "подобные" подразумевает сравнение
я говорю о сотруднике который пишет цикл или условие в одну строку или пихает всю логику в запрос, только лишь по той причине что в этот момент он чуствует себя тру-програмистом

Мне таки интересно Серёжа ответит на мой вопрос в (174).
"(172) Я ответил на вопрос: Почему?"

(191) общий случай - называется преждевременной оптимизацией, если ты понимаешь о чем я

(195) вот да, преждевременная оптимизация - отдельный вид зла. Который не намного лучше дублирования в коде. А уродливые запросы это прям комбо. Тут и дублирование (одно и то же растаскивается по множеству запросов), и преждевременная оптимизация

(192) Цепонуть сразу короткую таблицу, в которой напротив каждой ставки уже свой коэффициент: 0, 0.1, 0.18, 0.2...
По скорости внутреннее соединение короткой таблицы, будет быстро, а копипаста минимум.
Что бы не было по "100500 модулям в типовых конфигурациях". Таблица же статическая. При запуске создал и юзай везде.

При добавлении новой ставки в 17%, достаточно при запуске поправить создание таблицы. Код будет статичный.

(197) ну реальность-то таковая, что в тысяче запросов накрошили "выбор когда тогда" с конкретными ставками

(198) так не сделали этого сразу же. Поэтому добавление двух несчастных значений в перечисление привело к исправлениям в 100500 запросам. Самое интересное, отдельной таблички со ставками тут и не нужно было. Достаточно было при обходе выборки звать функцию вычисления ставки НДС. Если СКД, то в вычисляемых полях ту же функцию дёргать

Вот, запросная наркомания из типовой. Запрос сам себя дублирует

ВЫБРАТЬ
    ВЫБОР
        КОГДА КорректировкаПоступленияТовары.КоличествоДоИзменения >= КорректировкаПоступленияТовары.Количество
            ТОГДА &ИсправляемыйДокументПоступления
        ИНАЧЕ &СчетФактура
    КОНЕЦ КАК СчетФактура,
    &ИсправляемыйДокументПоступления КАК Партия,
    &Склад КАК Склад,
    ЗНАЧЕНИЕ(Перечисление.ВидыЦенностей.ПустаяСсылка) КАК ВидЦенности,
    КорректировкаПоступленияТовары.Номенклатура КАК Номенклатура,
    КорректировкаПоступленияТовары.СтавкаНДС КАК СтавкаНДС,
    КорректировкаПоступленияТовары.Количество - КорректировкаПоступленияТовары.КоличествоДоИзменения КАК Количество,
    ВЫБОР
        КОГДА НЕ КорректировкаПоступленияТовары.Ссылка.СуммаВключаетНДС
            ТОГДА КорректировкаПоступленияТовары.Сумма + КорректировкаПоступленияТовары.СуммаНДС - (КорректировкаПоступленияТовары.СуммаДоИзменения + КорректировкаПоступленияТовары.СуммаНДСДоИзменения)
        ИНАЧЕ КорректировкаПоступленияТовары.Сумма - КорректировкаПоступленияТовары.СуммаДоИзменения
    КОНЕЦ КАК Стоимость,
    КорректировкаПоступленияТовары.СчетУчета КАК СчетУчета,
    КорректировкаПоступленияТовары.СчетУчетаНДС КАК СчетУчетаНДС,
    КорректировкаПоступленияТовары.Ссылка.Дата КАК Период,
    КорректировкаПоступленияТовары.Ссылка.Организация КАК Организация,
    КорректировкаПоступленияТовары.НомерСтроки КАК НомерСтроки,
    КорректировкаПоступленияТовары.Ссылка КАК Регистратор,
    ЛОЖЬ КАК НоваяСтрока,
    ВЫБОР
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20_120)
            ТОГДА 20 / 120
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18_118)
            ТОГДА 18 / 118
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10_110)
            ТОГДА 10 / 110
        ИНАЧЕ 0
    КОНЕЦ КАК СтавкаНДСМножитель
ИЗ
    Документ.КорректировкаПоступления.Товары КАК КорректировкаПоступленияТовары
ГДЕ
    КорректировкаПоступленияТовары.Ссылка = &Ссылка
    И (КорректировкаПоступленияТовары.КоличествоДоИзменения - КорректировкаПоступленияТовары.Количество <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаНДСДоИзменения - КорректировкаПоступленияТовары.СуммаНДС <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаДоИзменения - КорректировкаПоступленияТовары.Сумма <> 0)
    И КорректировкаПоступленияТовары.КоличествоДоИзменения <> 0
    И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    &СчетФактура,
    &ИсправляемыйДокументПоступления,
    &Склад,
    ЗНАЧЕНИЕ(Перечисление.ВидыЦенностей.ПустаяСсылка),
    КорректировкаПоступленияТовары.Номенклатура,
    КорректировкаПоступленияТовары.СтавкаНДС,
    КорректировкаПоступленияТовары.Количество,
    ВЫБОР
        КОГДА НЕ КорректировкаПоступленияТовары.Ссылка.СуммаВключаетНДС
            ТОГДА КорректировкаПоступленияТовары.Сумма + КорректировкаПоступленияТовары.СуммаНДС
        ИНАЧЕ КорректировкаПоступленияТовары.Сумма
    КОНЕЦ,
    КорректировкаПоступленияТовары.СчетУчета,
    КорректировкаПоступленияТовары.СчетУчетаНДС,
    КорректировкаПоступленияТовары.Ссылка.Дата,
    КорректировкаПоступленияТовары.Ссылка.Организация,
    КорректировкаПоступленияТовары.НомерСтроки,
    КорректировкаПоступленияТовары.Ссылка,
    ИСТИНА,
    ВЫБОР
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС20_120)
            ТОГДА 20 / 120
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС18_118)
            ТОГДА 18 / 118
        КОГДА КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10)
                ИЛИ КорректировкаПоступленияТовары.СтавкаНДС = ЗНАЧЕНИЕ(Перечисление.СтавкиНДС.НДС10_110)
            ТОГДА 10 / 110
        ИНАЧЕ 0
    КОНЕЦ
ИЗ
    Документ.КорректировкаПоступления.Товары КАК КорректировкаПоступленияТовары
ГДЕ
    КорректировкаПоступленияТовары.Ссылка = &Ссылка
    И (КорректировкаПоступленияТовары.КоличествоДоИзменения - КорректировкаПоступленияТовары.Количество <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаНДСДоИзменения - КорректировкаПоступленияТовары.СуммаНДС <> 0
            ИЛИ КорректировкаПоступленияТовары.СуммаДоИзменения - КорректировкаПоступленияТовары.Сумма <> 0)
    И КорректировкаПоступленияТовары.КоличествоДоИзменения = 0
    И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый

(199) СКД это в основном вывод результата в читабельном виде с динамическими группировками и колонками. Не нужно в СКД совать логику расчетную, которая не в отчет.
Не сделал, так зачем было править при добавлении ставки путем добавлении везде - сразу переписать. Это проблемы проектирования конфигураций 1С. Особенно в последнее время. Создадут кучу реквизитов, а потом удаляют и создают новые такие же.
Не знать заранее что в нашей стране ставка НДС может меняться хоть каждый день... Ну как бы не первый раз они меняются и не последний.

(200) а как надо было?

(201) проблема со ставками НДС не была бы проблемой, если бы 1сники не вычисляли её в запросе

(201) справочник все равно не поможет ибо жесткая привязка колонок к ставкам

(200) Я так понимаю разница тут:
В выбрать
ЛОЖЬ КАК НоваяСтрока,

и в условии

И КорректировкаПоступленияТовары.КоличествоДоИзменения = 0
    И НЕ КорректировкаПоступленияТовары.СчетУчета.Забалансовый

(202) Выбор когда добавь и радуйся.

(202) вангую КорректировкаПоступленияТовары.СтавкаНДС.Множитель и все - без всяких выбор когда))

(202) простейшим запросов выбрать данные из ТЧ, потом обойти в цикле, делая вычисления. Код стал бы и короче, и намного читабельнее. Самое главное, его не пришлось бы перепахивать при появлении новых ставок НДС

(205) во-во-во! Отдельный ребус найти разницу в этих двух почти одинаковых запросах. Отдельная удача не допустить ошибку при их доработке...

(207) Не проще. Если этот код при проведении, то вот эти туды-сюды данных ооооочень медленно.
И зачем вычислять, если можно просто соединить и получить нужный коэффициент сразу. Вопрос только в отсутствии таблицы, построенной по статическим данным "Перечисление.СтавкаНДС". Создать служебный РС строить его при запуске 1С и не жужжать.

(207) для типовой это сомнительные плюсы

(209) а зачем туды-сюды? Один раз получил данные запросом, и шлифуй их в коде. Один фиг ты притащишь эти данные на сервер, чтобы запихать в наборы записей

>>И зачем вычислять

Вот и у меня вопрос. Зачем делать вычисления в запросе? Они уродливые и приводят к дублированию

"Строить при запуске 1С" - имеется ввиду при необходимости. При обновлении, например, когда это необходимо.

Мне таки интересно Серёжа ответит на мой вопрос в (174).

Звучал он примерно так: "(172) Я ответил на вопрос: Почему?".

(210) это так кажется, оттого что слаще брюквы ничего не едовал, краше типового кода ничего не видовал. К сожалению, копаться в дерьмовом и задублированном коде настолько привычно для нашего брата 1сника, что давно стало обыденностью

(0)
Хорошо когда о причине введения функции ЕстьNULL() задумываешься не после собеседования, а в результате тестирования своего запроса.
Опыт ценен. Лучше поздно (с несколькими сертификатами), чем никогда.

Казалось бы парадокс "NULL <> NULL", но с другой стороны отсутствие значения в разных физических таблицах дает один и тот же NULL.
И приравнивать их это терять физический смысл.
Ввели эту функцию, что бы разработчик обозначил пустые значения.

(0)
Убивать за такие запросы надо )))
Шутка. Не рационально.

Если "Характеристика" это измерение, то еще интереснее. )
Если оно не используется, то зачем в итоговую таблицу выбирать?
Если используется активно, то ... .

Если реквизит, то видимо другое дело.

Короче я в шоке ))). Вникать не хочется в чужую кухню.

Удачи Серега.

Да нет поспешил вроде норм. Конец дня.
Но все равно я бы по другому написал.
Все мы разные.

(217) взад беру.

(216) оставлю

Типа мое мнение ) Которое не имеет смысла )

Яркий пример что сертификаты ничего не гарантирую )

(218) Перфекционист что ли? НЕ люблю перфекционистов, они убогие стандарты 1с-разработки пишут.

(220) Мне таки интересно Серёжа ответит на мой вопрос в (174).
Звучал он примерно так: "(172) Я ответил на вопрос: Почему?".

Уже чисто спортивный интерес.

Если кто-то говорит,что в 1с сложные запросы,то пусть чистый sql посмотрит,где хранимые процедуры - вот где внсело и интересно,когда те же "модули",но внутри sql.

(222) а для чего смотреть некие абстрактные процедуры? Если смотреть то процедуры конкретные, в конкретных условиях разработки

(221) сформулируй вопрос целиком. Если ты считаешь, что IN лучше чем JOIN, то мы на разных сторонах силы. ОК?

(220)

Норм. Не обиделся.

Всегда потом можно деньги на оптимизации взять.
Кто-то костыли ставит. Кто-то снимает.
Так и зарабатываем.

Некоторые любят посидеть подождать пока запрос отработает )
Особенно если почасовка идет.

(224) У тебя в IN всего два значения и этот IN в параметрах виртуальной таблицы.
Можешь написать не IN а "Условие1" ИЛИ "Условие2". Опа, и нет никакого IN.

А у тебя две выборки из одного источника данных, да ещё и левое соединение потом. Ты соединяешь таблицу саму с собой, при этом таблица используется как есть.
Т.е. одно дело ты в таблице нашел МАКС или МИН или ещё что и потом соединяешь уже преобразованную таблицу с исходной таблицей. А другое дело просто саму исходную таблицу саму с собой - в этом нет никакого смысла. Она у тебя и при первой выборки уже есть.

(199) там они молятся на то, чтобы все вычисления были в запросах. поэтому я и не уважаю стандарты 1С-совместимо. Это не практическое руководство, а религиозное

(194) таки сформулируй вопрос целиком, я запутался в твоих цикличных ссылках

(228) Чего его там формулировать. Зачем левое соединение таблицы самой с собой?

(227) Это в каком стандарте описано?

(227) бред же. Ты стандарты даже не читал

из стандартов, касательно твоих болячек в (0)

Псевдонимы источников данных в запросах

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

псевдонимы следует образовывать от терминов предметной области таким образом, чтобы было понятно, как источник данных будет использоваться в запросе;
псевдонимы следует образовывать путем удаления пробелов между словами. При этом каждое слово в имени пишется с прописной буквы (например, ТоварыНаСкладах). Предлоги и местоимения из одной буквы также пишутся прописными буквами;
псевдонимы запрещается начинать с подчеркивания;
псевдонимы не должны состоять из одного символа.

(232) а из двух можно, ггг? ну что за бред, что за иллюзии в голове этих писателей стандартов?

(233) бред это твой код, а в стандартах все нормально. Что, стандарт задевает твои говнокодерские привычки?

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

(228) И.... ? Опять я не сформулировал вопрос что ли?

(226) какой такой один источник? там две таблицы с разными видами цен.
Да, можно использовать:
РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ ИЛИ ВидЦен = &ВидЦен)

Но там надо не просто макс или мин цену определить, а иметь для расчета цену ВидЦенБ (от нее расчитывается новая цена) и сравинвать с ценой ВидЦен.

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

Но если ты считаешь что нет, будь добр, сделай рефакторинг этого запроса на:

РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦен = &ВидЦенБ ИЛИ ВидЦен = &ВидЦен)

(237) В (47) же написал уже.

(237) "Но там надо не просто макс или мин цену определить" - а где вообще макс или мин цена?

(238) э нет, дядя, ты напиши весь запрос, как минимум на СГРУППИРОВАТЬ ты уже попал. Не думаю, что твоя экономия на соединить дала тебе какой-то выигрыш. Весь запрос будет монструозным, в отличии от моего, а выигрыша по производительности не будет, план запроса будет ужасным.

Побаловался для практики )

"ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
|ПОМЕСТИТЬ НовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦены) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК БазоваяЦена,
|    ЦеныНоменклатурыСрезПоследних.Упаковка КАК ЕдиницаИзмерения
|ПОМЕСТИТЬ БазовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦеныБазовая) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    БазовыеЦены.Номенклатура КАК Номенклатура,
|    БазовыеЦены.Характеристика КАК Характеристика,
|    БазовыеЦены.БазоваяЦена КАК БазоваяЦена,
|    БазовыеЦены.ЕдиницаИзмерения КАК ЕдиницаИзмерения,
|    ЕстьNULL(НовыеЦены.Цена,0) КАК Цена
|ИЗ
|    БазовыеЦены КАК БазовыеЦены
|        ЛЕВОЕ СОЕДИНЕНИЕ НовыеЦены КАК НовыеЦены
|        ПО БазовыеЦены.Номенклатура = НовыеЦены.Номенклатура
|            И БазовыеЦены.Характеристика = НовыеЦены.Характеристика
|ГДЕ
|    ЕстьNULL(НовыеЦены.Цена,0) <> &НоваяЦена"

Можно еще запросы 1 и 2 переставить и выбирать только присутствующие пары Номенклатура + Характеристика из полученной таблицы предвосхищая левое соединение,
но очень похоже что экономии не будет.

"ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК БазоваяЦена,
|    ЦеныНоменклатурыСрезПоследних.Упаковка КАК ЕдиницаИзмерения
|ПОМЕСТИТЬ БазовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата, ВидЦены = &ВидЦеныБазовая) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    ЦеныНоменклатурыСрезПоследних.Номенклатура КАК Номенклатура,
|    ЦеныНоменклатурыСрезПоследних.Характеристика КАК Характеристика,
|    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
|ПОМЕСТИТЬ НовыеЦены
|ИЗ
|    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
|            &Дата,
|            ВидЦены = &ВидЦены
|                И (Номенклатура, Характеристика) В
|                    (ВЫБРАТЬ РАЗЛИЧНЫЕ
|                        БазовыеЦены.Номенклатура КАК Номенклатура,
|                        БазовыеЦены.Характеристика КАК Характеристика
|                    ИЗ
|                        БазовыеЦены КАК БазовыеЦены)) КАК ЦеныНоменклатурыСрезПоследних
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    БазовыеЦены.Номенклатура КАК Номенклатура,
|    БазовыеЦены.Характеристика КАК Характеристика,
|    БазовыеЦены.БазоваяЦена КАК БазоваяЦена,
|    БазовыеЦены.ЕдиницаИзмерения КАК ЕдиницаИзмерения,
|    ЕСТЬNULL(НовыеЦены.Цена, 0) КАК Цена
|ИЗ
|    БазовыеЦены КАК БазовыеЦены
|        ЛЕВОЕ СОЕДИНЕНИЕ НовыеЦены КАК НовыеЦены
|        ПО БазовыеЦены.Номенклатура = НовыеЦены.Номенклатура
|            И БазовыеЦены.Характеристика = НовыеЦены.Характеристика
|ГДЕ
|    ЕСТЬNULL(НовыеЦены.Цена, 0) <> &НоваяЦена"

&НоваяЦена КАК НоваяЦена,

Смысла не имеет. Если только не используется дальше.
Проще при переборе выборки подставить куда надо константу единую для всей выборки.

Возможно есть смысл из-за того при последнем варианте будет задействован первичный индекс.
Ну да не важно ))))

(240) Ты же даже не пробовал.

(0) Почему нет связи по "ЕдиницаИзмерения"?
В общем случае одна и та же номенклатура с ценой за килограмм и за центнер, упаковка и коробка 10 шт, и т.д.
Или в вашем случае у номенклатуры всегда одна "ЕдиницаИзмерения"? А вдруг кто-то двойника штук сделает?

(240) Для затравки....
Запрос по характеристикам

(240) не-а. Твой план запроса будет плохим, а его отработает оптимально

+(249) не гарантированно, но с большой долей вероятности будет плохим... Про это на ИТС написано, который ты не читал

https://its.1c.ru/db/v8std/content/655/hdoc

1.1. При написании запросов не следует использовать соединения с вложенными запросами. Следует соединять друг с другом только объекты метаданных или временные таблицы. Если запрос использует соединения с вложенными запросами, то его следует переписать с использованием временных таблиц (не важно с какой стороны соединения находится вложенный запрос), кроме случая, когда вложенный запрос сканирует мало записей
...
Оптимизатор сервера СУБД (независимо от того, какую СУБД вы используете) не всегда может правильно оптимизировать подобный запрос. В данном случае, проблемой для оптимизатора является выбор правильного способа соединения. Существуют несколько алгоритмов соединения двух выборок. Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке. В том случае, если вы соединяете две физические таблицы, СУБД может легко определить объем обоих выборок на основании имеющейся статистики. Если же одна из соединяемых выборок представляет собой вложенный запрос, то понять, какое количество записей она вернет, становится очень сложно. В этом случае СУБД может ошибиться с выбором плана, что приведет к катастрофическому падению производительности запроса.

И слился....

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

(247) в нашем случае не сделают.

(250) дружок, а где ты у меня вложенный запрос увидал? гггг

(254) Справа от левой таблицы и слева от правой )))

(255) не гони

(256) Срез последних - это не таблица, это запрос

(253) В ссылку в (248) зайди. Может что-то не очевидное увидишь.

"Не волнуйтесь, если что-то не работает. Если бы всё работало, вас бы уволили."

(254) открою тебе страшную тайну: все виртуальные таблицы в запросах 1с по-факту являются вложенными запросами. Стыдно гуриям такое не знать

(252) "Поэтому ты и не пишешь хотя бы примерный текст запроса" - написан примерный текст запроса ещё в (47).

(261) это только декларация намерений. ггг..

(260) вложенные запросы это то, что находится в операторе IN

(263) не только

Оператор IN не ошибается, если используется выборка из ВТ без условий, поэтому где-то когда-то был рекомендован к использованию. А в случае замены ИЛИ - прям обязан быть использованным

А виртуальные таблицы - это запрос с неизвестным объёмом результата

(263) не пиши ересь

Смотрю, кризис вайти неслабо тебя накрыл, раз элементарные вещи за столько лет не изучил

(263) Вложенный запрос - это запрос внутри запроса

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