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

Результат
Цена    Регистратор
308,64    Установка цен 000000013 от 01.01.2023 23:59:59
293,94    Установка цен 000000015 от 01.04.2022 0:00:01

Где я накосячил?

Номенклатуру выведи и поймешь

(1) Выводил. Я его в консоль загнал, выбрал только одну номенклатуру. Ну добавляется еще вывод одной и той же номенклатуры.

(2) как-то не верится. Ну попробуй ради эксперимента не И Номенклатура В (&Номенклатура) а И Номенклатура = &Номенклатура.
Если затуп останется, пересчитать итоги, возможно даже ТИИ. У меня за все время только 1 раз таблицы итогов сбоили(тоже записи двоились и вообще полная дичь), ТИИ+пересчет и все.

(3) Про ТИИ я не подумал.

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

ПС. На флоте контракт закончился, вернулся в 1с?

(5) Ага, встречался с тем, что франчевый разработчик в измерения добавил все поля. Ну, на всякий случай, и чтобы обработка не ругалась на ключевые поля :)

(5) Шабашки делаю. Все равно делать часто нечего.

(6) У меня их всего четыре. Все в запросе участвуют.

(8) Регистратор - это явное измерение чтоли?

(9) Нет, обычное.
Щас ТИИ заканчивается уже, и доки установки цен перепроведу.

(0) Срез последних работает по всем измерениям.

(11) Это я в курсе. Но я нифиг ничего криминального не вижу. Или сначало срез делается, а потом отбор и мне малину Перечисление.ВидЦен.Территория портит?

(8) Где это все 4? Я вижу 3: ВидЦены, Партнер, Номенклатура
Куда четвертое дел?

Там случайно нет измерения "ХарактеристикаНоменклатуры" ?

(0)Всё правильно, возвращается последняя цена по каждому из регистраторов.

(13) Дык регистратор же, он там по умолчанию.

(15) Этож с какого перепоя то?

(17)Срез последних всегда так работал, уже не раз обсуждалось.

(15) Ты пьян что ли?

А срез последних курсов валют вернет последние записи на каждый день, да?

(19)Ага, с утра накатываю)

(20)В курсах валют ОДНО Измерение Валюта.

(21) Выборка регистратора в срезе возможна и вернет тот регистратор, который сделал последнюю запись

(16) Регистратор не измерение, это скорее расширение/уточнение периода

(0) вид цены - перечисление, что за конфа такая?

(0) Срез последних в 1С - это срез не совсем последних. Накосячил не ты, а разработчики платформы, которым было лень GROUP BY прописать как следует

(26) Ты задрал уже со своими стонами

(23)ВЫБРАТЬ
    ЦеныНоменклатурыСрезПоследних.ВидЦены КАК ВидЦены,
    ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
ИЗ
    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, Номенклатура = &Номенклатура) КАК ЦеныНоменклатурыСрезПоследних

Выполни в УТ 11-й такой запрос для любой номенклатуры, где несколько видов цен. Что вернет?

(28) Несколько записей, столько, сколько видов цен
А что?

(29)Чем это отличается, от случая, о котором пишет автор? В данном случае у него Регистратор точно такое же измерение, как и Вид цены.

(0) Напиши сам нормальный срез. Там всего три строчки

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

(30) Регистратор  - НЕ измерение

(30) Блеать
Читай (24)

(32) Задокументировано, кстати, другое

(33)Почему у меня в конструкторе его нет?

(32)Описание:
Предназначена для получения наиболее поздних записей регистра сведений на указанную дату (включительно). Включает только активные записи. По каждой комбинации измерений будет найдена наиболее поздняя запись, но не более поздняя, чем указанная дата.
В режиме совместимости Версия8_3_17 и ниже включает записи независимо от признака активности.

(36)Понял, надо дату явно ставить параметром.

(0) Номенклатура В (&Номенклатура)
Тебе нужна в результате одна номенклатура или несколько?

(16) Может у тебя кривой регистр, не подчиненный регистратору. И регистратор добавлено как измерение?

Если нужна одна номенклатура:

ВЫБРАТЬ ПЕРВЫЕ 1 ... ИЗ РегистрСведений.ЦеныНоменклатуры ГДЕ ... УПОРЯДОЧИТЬ ПО

Если несколько:

ВЫБРАТЬ Т1.Номенклатура, Т1.Регистратор, Т1.Цена
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Т1
ГДЕ Т1.Период В (ВЫБРАТЬ МАКСИМУМ(Т2.Период) ИЗ РегистрСведений.ЦеныНоменклатуры КАК Т2 ГДЕ Т2.Номенклатура=Т1.Номенклатура)
И Т1.Номенклатура В (&Номенклатура)
И Т1.ВидЦены = ЗНАЧЕНИЕ(Перечисление.ВидЦен.Территория)
И Т1.Партнер = &Партнер

(0) Напиши уже список всех своих четырех измерений

(0) У тебя измерения: Партнёр, ВидЦены, Номенклатура, "Нечто 4" и ресурс Цена?
Опиши словами: что именно ты хотел получить таким запросом?

(43) Последние цены (вместе с регистратором) для каждой номенклатуры. Какие еще варианты?

(44) и где номенклатура в запросе, у ТС цена и регистратор? Больше похоже на ожидание "Хочу самую последнюю цену из указанных номенклатурин у конкретного Партнера"

43+ вот это в параметрах регистра:
ВидЦены = ЗНАЧЕНИЕ(Перечисление.ВидЦен.Территория)
И Партнер = &Партнер
И Номенклатура В (&Номенклатура)) КАК ЦеныНоменклатурыСрезПоследних

Отбирает данные по приведенным условиям и потом лепит срез последних из выбранного (в т.ч. и с учётом Номенклатуры)

По идее, если перенести в ГДЕ Номенклатура В (&Номенклатура) - ты получишь последнюю цену без учёта измерения Номенклатура

На ИТС есть статья про различия в месте указания параметров

(45) Рукалицо, кругом одни профаны
Статья на ИТС про разницу в отборах НЕ ПО ИЗМЕРЕНИЯМ, для измерений результат будет одинаковым

(45) по измерениям правильно указывать в параметрах, результат будет одинаков.
А вот отборы на другие поля(не-измерения) будут давать другой результат по сравнению с отборами в условии ГДЕ.

(45) См. (1) и (2)

Да все просто, ТС не учел наличие четвертого измерения, например, ХарактеристикаНоменклатуры, или что там у него
И в итоге дубли записей

(45) 1С-овский срез последних всегда строит срез по всем измерениям. Если нужен срез по подмножеству измерений, тогда надо писать запрос к таблице регистра, а не к виртуальной таблице среза

(49) главное чтобы это не оказалась самопиской с ценой в измерениях

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

(46)(47) Не всегда одинаковый результат СрезаПоследних, на сколько помню, там вопрос в моменте построения СрезПоследних "Сначала отобрали, потом срез или сначала срез а потом отбор данных" + разный состав измерений для результирующего набора

(50) вроде как нет, срез строится по запрошенным измерениям, возможно, что мне просто так везло. И у ТС Регистратор вполне может быть 4-м измерением, а не стандартным

(53) Блин, еще раз, речь про разные результаты при разных вариантах отбора НЕ ПО ИЗМЕРЕНИЯМ
Всё
Точка

Отбор по курсам валют с отбором по евро и по курсу <= 50 в ПВТ вернет один результат
Отбор по курсам валют с отбором по евро и по курсу <= 50 в ГДЕ вернет другой результат
В первом случае будет срез по курсам евро, где курс был <= 50
Во втором случае будет срез по всем курсам евро, а потом уже выбранное отфильтруется, если курс > 50

(53) Рукалицо
Вроде как да
И у ТС регистратор скорее всего стандартный, хотя и да, есть вероятность 0.0000001, что нет, плюнем на эту вероятность

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

(56) А вот то, что ТС проигнорил характеристику, как раз вполне вероятен, бывает

+(57) Если хочется выбрать цены без характеристик, достаточно в ПВТ просто поставить отбор по пустой характеристике и все, все детализации уйдут

В копилку знаний
Вариант с ценой по конкретной характеристике чуть сложнее, но тоже прост
Делается срез 1 по пустой характеристике полное соединение срез 2 по конкретной характеристике, в поле цены ЕСТЬNULL(Срез2.Цена, Срез1.Цена), в остальных полях аналогично
Ну или с объединениям мутить и максимумом потом

(58) Зачем такие сложности? Один компактный коррелированный запрос решает проблему. См. (41)

(59) В (41) говно

(57)Спорим, что и без заполненной характеристики так будет?)

+(61)Проверяется на раз-два в любой базе, где есть Цены номенклатуры и нет хар-ик, у меня как раз такой вариант под рукой.

(61) Как так? Ты про что?

(62) Выдадутся все регистраторы или что?
Выражайся конкретнее

(64)Да, будет такая же выдача как у автора.

(65) И РС периодический и подчинен регистратору, в нем три измерения, отбор по одной номенклатуре, партнеру и виду цены, при этом цена менялась несколько раз?
И будет несколько записей?

+(65)Речь про стандартную УТ11, структура как в ней. P.s. Я так понимаю, в данном случае поле Регистратор просто еще одно измерение и не более, для подчиненных РС. Поэтому СрезПоследних для него даст точно такой же эффект как и для любого другого измерения(о чём и писал в (30))

(66)Тебе лень самому проверить?

(60) Оно работает

(68) я только что проверил эту дичь, не знаю даже зачем.
Вывелась одна запись. Неожиданно, да?

(70)Подтверждения будут?)

(68) Что проверить?
Ты же поспорить хотел

(71) серьезно? Типа скрина слать? На то, что периодический регистр сведеный выдаст последнуюю запись за указанный период?
Знаешь, нет. Пруфов не будет.

+(71)Для одного вида цен?

(71) Подтверждение того, что идиотские идеи — они только у тебя в голове?
Совсем народ охренел, не знают нихрена, еще и докажи им с картинками

(69) Работает
Неправильно, но работает, здесь не поспоришь

Критику принимаю - если указать в отборе отбор по виду цен, то действительно одна запись.

кажется он не лечится

(52) Насчет ничтожности - франч так и сделал: цену в измерения. Аргументация - чтобы можно было в одну секунду ставить разные цены :)

(79) рынок - быстро меняющаяся среда. цены прям моментально скачут туда сюда. и все это в пределах одной секунды =D

(79) Ну так а Панин собаку трахнул, или она его, я не знаю точно
И что?
Мы же про адекватных людей, а не фриков

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

И увидеть наконец, по какому измерению не установлен однозначный отбор

(76) В смысле неправильно? Этот запрос вернет то, что хотел ТС

(0) Ни в коем случае не выкладывай тут описание структуры регистра, а то слишком скучно будет.

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

(85) Оно работает, понимаешь? Я запустил и проверил

(81) Ну, если что-то работает неадекватно, то стоит проверить, не является ли это проделками неадекватных людей :)

(86) Ты хочешь, чтобы я тебе объяснил, где ты накосячил?

(88) У тебя не получится. Оно работает. Так, как надо ТС

(89) Ню ню

(89) То что написано в (41) не сработает, если по номенклатуре будет установлена последняя цена не по ВидЦены = ЗНАЧЕНИЕ(Перечисление.ВидЦен.Территория) или не по Партнер = &Партнер

Вообще непонятно, чего вы упираетесь. В (41) написана хрень. Это очевидно. И то, что у вас она где-то там "работает" не говорит вообще ни о чём. К примеру, если у вас в регистре всего одна запись, то вообще любой запрос к этому регистру будет "работать".

(90) (91) Да, вы правы. Поторопился и пропустил условия. Работающий запрос:

ВЫБРАТЬ Т1.Номенклатура, Т1.Регистратор, Т1.Цена
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Т1
ГДЕ Т1.Период В (
ВЫБРАТЬ МАКСИМУМ(Т2.Период) ИЗ РегистрСведений.ЦеныНоменклатуры КАК Т2
ГДЕ Т2.Номенклатура=Т1.Номенклатура
И   Т2.ВидЦены =Т1.ВидЦены
И   Т2.Партнер=Т1.Партнер
)
И Т1.Номенклатура В (&Номенклатура)
И Т1.ВидЦены = ЗНАЧЕНИЕ(Перечисление.ВидЦен.Территория)
И Т1.Партнер = &Партнер

(92) Заканчивай уже, твое желание натянуть сову на глобус и получить вместо нескольких записей одну давно понятно
Это не делает твое говнорешение не говнорешением

(93) Решение либо работает, либо не работает. А все остальное - дело вкуса

(92) Зачем городить свой "срез последних", если есть предусмотренный платформой метод?
И тут вопрос не во "вкусе".
К примеру, вы обращали внимание на параметр "Разрешить итоги: срез последних" в периодических регистрах сведений? Своим запросом из (92) вы намеренно лишаете себя возможности использования преимуществ предоставляемых этим параметром. Я уж не говорю про оптимальность запроса, про использование вложенного запроса в условиях и прочее и прочее.

Очевидно же, что у ТС проблема не в том, что он использует виртуальную таблицу среза последних вместо того, чтобы самому её писать. Его проблема в другом.

(95) В чем его проблема?

(96) С вероятностью 99% в том что у него не установлены однозначные отборы по всем измерениям регистра сведений. Поэтому срез последних возвращает количество записей соответствующее разным значениям всех измерений регистра с учётом наложенного отбора.
И 1% я оставлю на какие-то явления с некорректно работающей базой данных, платформы и т.п.

(97) Не установлен отбор по еще одному измерению. И дальше что?

(98) В смысле "и дальше что?"
И дальше то, что его запрос возвращает последние значения по всем измерениям регистра.
А ваш запрос выдаст вообще неверные данные, выбрав самое последнее значение только по установленным отборам (если по неучтённому измерению значения установлены на разные даты), либо точно так же выдаст множественные результаты.

(99) Смотрим (0)

308,64    Установка цен 000000013 от 01.01.2023 23:59:59
293,94    Установка цен 000000015 от 01.04.2022 0:00:01

Совершенно естественное и законное желание не видеть в результате данные годичной давности? Разве нет?
Вы можете сказать, что пользователь сам виноват, что не указал характеристику. А пользователь может сказать, что ему плевать на характеристики, он хочет видеть последнюю цену по номенклатуре. Он точно знает, что последние цены устанавливались относительно недавно. И появления данных от апреля прошлого года ему видится, как однозначный баг.
Вы можете, конечно, продолжать втирать пользователю про характеристики. Но лучше будет, если вы просто удовлетворите его реальную потребность, в соответствии с принципами фирмы 1С

(100) Мы можем лишь предполагать, что хочет пользователь, и как у него ведутся данные в базе.
Каждая задача имеет свой путь решения.
Утрированный пример:
Я хочу получить цену на цепочку. У мен есть характеристики: золотая, алюминиевая.
Золотая стоит примерно 10000, алюминиевая примерно 100 руб.
Так вышло, что золотую я не переоценивал давно, а алюминиевую буквально вчера.
Ваша реализация получения "самой последней цены" приведет к тому, что золотая цепочка будет продана за 100 руб.
Задача форума объяснить проблему ТС, а не давать ему условно работающее на его примере решение, но потенциально приводящую к фатальной ошибке.

(101) Озвученный мною принцип 1С (который я всецело поддерживаю) может быть сформулирован и так:
Не надо никого "лечить", если вас об этом прямо не просят. Вам говорят: нужна последняя цена по номенклатуре. Просто дайте ее и все. Ваше стремление показать себя умнее пользователя мешает удовлетворять его реальные потребности

(0) А попробуй заменить Номенклатура В (&Номенклатура) на Номенклатура = &Номенклатура

(102) Я не знаю, что за принцип 1С вы выдумали.

Я привел пример, к чему ваш подход может принести.

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

(94) Если так, то твое не работает

(98) И дальше все
Не установил отборы — получай много записей

(99) Да просто (98) известный упоротый, топит за то, что если не ставить по чему-то отбор, то из всех записей должен взяться максимум
Ну типа если у меня все сапоги стоят 100 рублей, а сапоги красные стоят 120 рублей, то программа при отборе по сапогам, но без отбора по характеристике должна выдать 100 или 120, что было позже установлено, а не две записи
Местный дурачок, не обращай внимания, он уже всем мозги проебал своим тупизмом

(104) Вы выступаете за то, чтобы всегда получать одну "цену"? Но штатный 1С-овский механизм вам этого не обеспечивает. Он не выдает всегда одну цену. Он выдает много цен. И даже тогда, когда можно было бы выдать одну

(108) Штатный механизм выдает срез последних по всем измерениям. Не его вина, что регистр спроектирован не в соответствии с возложенными задачами или некорректно используется.

P.S. Я перестал понимать, о чем, собственно, разговор? Вас не устраивает работа виртуальной таблицы СрехПоследрих? Не используйте её. Остальные пруцца.