Только сейчас обнаружил, что если в запросе будут не все измерения, то срез последних "превращается в тыкву". Например, измерения "поставщик", "номенклатура". Делаем запрос по одному измерению "номенклатура" и не получаем срез последних по этому измерению. Это действительно так? Или я что-то "неправильно готовлю" (версия платформы 8.3.18.1208)?

Срез РС всегда возвращается по всем сочетаниям измерений, в отличие от вирт. таблиц РН, например.

(1) Поленились, значит. Буду знать

(2) Кто поленился? Ты прочитать документацию?

(1) По РН вообще агрегируются ресурсы по не выбранным измерениям.

(2) > я что-то "неправильно готовлю"?
да

(3) Разработчики платформы, кто!

(5) Что именно? Вроде только что выяснили в (1), что срез именно таким образом недоделан. У вас есть какая-то другая информация? Какая?

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

(8) идеологи от фирмы 1С так решили

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

(9) ну построили такую модель, попробуйте предложить свою с мадемуазелями и преферансом

(8) Вы неправы. Срез последних никоим образом не зависит от уникальности. Исходные данные для получения среза всегда не уникальны

(9) Если бы решили. Просто поленились

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

Хыхы, ну да, конечно, один из важных элементов платформы именно разработчики захотели сделать именно таким.

Мне это напоминает ситуацию, когда из института приходит мальчик-кодер, видит корпоративную систему издалека и тут же заявляет, что делали её идиоты и надо всё переделывать.

(11) когда-то в молодости я писал свои модели, но все кончилось тем, что занимаюсь 1С-ом

Правила устанавливают те, у кого решение взлетело и выдержало испытание временем

(12) слышали про такое, что набор Период+Измерения являются уникальным ключом на уровне платформы?

(17) Вы упорствуете в заблуждении. Уникальность и срез - это две НЕЗАВИСИМЫХ друг от друга фичи.

Исходные данные
01.01.2021 ООО Ромашка Свистелка 100 руб.
01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.03.2021 ООО Ромашка Свистелка 106 руб.

Срез по двум измерениям
01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.03.2021 ООО Ромашка Свистелка 106 руб.

Срез по одному измерению
01.03.2021 Свистелка 106 руб.

В этом месте, если вы сделаете запрос к срезуПОСЛЕДНИХ с одним измерением 1С выдаст
01.02.2021 Свистелка 105 руб.
01.03.2021 Свистелка 106 руб.

(18) И это нормальная логика. К примеру: Есть некий Вася, который работает на 2 рабочих местах.
01.03.2020 Кабинет1 Вася
01.04.2020 Кабинет2 Вася

Если вы сделаете срез последних по этому регистру с отбором по Васе, то у вас выйдет 2 строчки, проще говоря 1ска сделает срез по каждому измерению (последний раз когда вася в кабинет1 и кабинет2 работал). Даже если вы не выберите поле кабинета, то все равно в результате будет 2 строчки.
Еще раз отмечу, что СрезПоследних в 1с представляет из себя последние данные на указанную дату для УНИКАЛЬНОЙ комбинации измерений.

(18) А потом у тебя будут исходные данные:
01.03.2021 ООО Ромашка Свистелка 106 руб.
01.03.2021 ООО Одуванчик Свистелка 105 руб.

И срез последних по твоей свистелке что должен будет вернуть? цены через запятую?

(20) по его "логике" последняя запись в таблице походу)

(0) Поддержу. Да что этот 1С себе позволяет! Придумывают не удобную для меня фигню.

(20) присоединюсь. Ровно это же хотел спросить

(19) Еще раз. Уникальность и срез - две независимых по самой своей природе фичи. Регистр сведений поддерживает уникальность - это одна его фича. Далее, регистр сведений, если поставить галку, может генерить срез последних. Это другая фича. Нет никакого смысла увязывать эти две фичи друг с другом. Нет такого правила, срез последних должен строиться по всем измерениям. Банальная лень разработчиков и просто дырка в платформе

(14) Продолжу еще раз. Сначала надо выполнить то, что в инструкции, а потом удивляться. Если ты отклоняешься от инструкции по разным причинам (незнание, несогласие и т.п.), то удивляться не нужно.

(24) Не надо трактовать понятия на свой лад. Тогда и не будет "дырок".

(24) Есть понятие Срезпоследних, у него есть свое определение данное 1с. В нем четко сказано, как срез отрабатывает. Но вы придумали свое определение срезу и удивляетесь, почему так не работает...

(20) Любую

(28) Поясни )

(28) нету такой функции в запросах 1с

(28) ну круто что, возьмем регистр цен номенклатуры и не отберем по виду цен, а потом возьмем любую на дату, круто же)

(28) А чего ты тогда паришься? Бери любую запись из того что тебе сейчас возвращает срезпоследних -))

(31) а если еще и в валюте есть цены, то еще круче))

(20) Спасибо! Навели на мысль, где я "не умею готовить"

(24) "Нет такого правила, срез последних должен строиться по всем измерениям"
Есть. И ничего ты с этим не поделаешь.

Вообще не понимаю, что тут можно обсуждать:
Разработчик предоставил нам механизм, который работает определенным образом. На этом всё.

(35) Это - не баг, это - фича ))))

(36) А поговорить? И вообще... 1С еще сырая (с)

(38) Воистину сырая

(37) напиши свой срез, за то время, как закидывать на вентилятор уже бы справился

(37) Это описанное в документации поведение. И если оно тебе не нравится - у тебя есть два пути.

Эхх придется самому срез писать.
Кстати не самая тривиальная задача

+40 раньше сталкивался, что на постгри запрос возвращал не последнюю запись, а тот же запрос на мсскл - последнюю
надо и тут похоливарить

Но конечно сеньор 1сник должен это с закрытыми глазами делать

(43) так ордер бай нужно таки указывать

(43) Это документировано тоже...

Напишите в 1с, что у них не хватает еще одной функции - срез совсем последних! )))

(28) Гениальное решение. Бери тогда МАКСИМУМ() или МИНИМУМ() и не парься.

(48) Эээ...

01.02.2021 Свистелка 105 руб.
01.03.2021 Свистелка 106 руб.

Все-таки не срез последних. А в случае (20) можно брать все записи, тогда будет

01.03.2021 Свистелка 105 руб.
01.03.2021 Свистелка 106 руб.

Или действительно МНИМУМ(МАКСИМУМ), тогда
01.03.2021 Свистелка 105 руб.
или
01.03.2021 Свистелка 106 руб.

И первое и второе и третье будут самыми настоящими срезами последних. Все таки - это дырка в платформе

(36) Язык 1С - это жест благотворительности со стороны разработчиков. Он существует, пока мы им пользуемся

(50) не жест

(49) не выдумывай, нет никакой дырки в платформе.
Срез работает логично и правильно.

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

(52)
Исходные данные
01.01.2021 ООО Ромашка Свистелка 100 руб.
01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.03.2021 ООО Ромашка Свистелка 106 руб.
01.03.2021 ООО Василек 107 руб.

Что больше похоже на срез последних?

01.02.2021 Свистелка 105 руб.
01.03.2021 Свистелка 106 руб.
01.03.2021 Василек 107 руб.

или

01.03.2021 Свистелка 106 руб.
01.03.2021 Василек 107 руб.

Исходные данные
01.01.2021 ООО Ромашка Свистелка 100 руб.
01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.03.2021 ООО Ромашка Свистелка 106 руб.
01.03.2021 ООО Василек Свистелка 107 руб.

Что больше похоже на срез последних?

01.02.2021 Свистелка 105 руб.
01.03.2021 Свистелка 106 руб.
01.03.2021 Свистелка 107 руб.

или

01.03.2021 Свистелка 106 руб.
01.03.2021 Свистелка 107 руб.

(54) Ни одно из. Это больше похоже на твои фантазии

(28) системный поход, че

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

(53) поясни про последнюю строку исходных данных. Там что, второе измерение - пустое?

(49) дырка в голове

(54) больше похоже на срез последних:
01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.03.2021 ООО Ромашка Свистелка 106 руб.
01.03.2021 ООО Василек Свистелка 107 руб.
- чем оно и является

(60) Но 1С выдает

01.02.2021 Свистелка 105 руб.
01.03.2021 Свистелка 106 руб.
01.03.2021 Свистелка 107 руб.

И это ни на что не похоже, согласитесь

(58) Исправил в (54)

(61) нет. Тут ты показываешь то что выдает твой запрос, а не срез последних.
Срез последних выдает (60), а уже ты выводишь только одно измерение из двух.

(63) именно так, но ТС не хочет это понять походу...

(63) Получается, что срез последних выдает не срез последних

(65) откуда вы взяли определение среза последних? Из своей "логики"?

(66) Из значения слова "последний"

(65) ты или тролишь или действительно не понимаешь

(67) последний для уникального сочетания измерений, что не так?

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

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

(69) А должен быть последний для заданного тобой набора измерений

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

в общем, есть метод, описанный и названный 1с. Этот метод отрабатывает, как и был задуман. Все что вы пишите, это ваши хотелки, которые при желании можете реализовать запросом.

(73) Должен тем, кто пользуется языком

(74) "Чтобы выключить компьютер, нажмите кнопку Пуск" (с)

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

(73) А ещё по нажатию на неё должен запускаться видимо пуск ракет, а то какого .. она называется "Пуск" а не "Выключение")))
(75) Докопаться до значения слова и это в русскоязычном языке. Чтоже с вами будет если программировать на англ.

(75) я пользуюсь. Реализация среза - правильная. То что ты хочешь - хрень.

(79) Но и я тоже пользуюсь

(80) всем не угодишь

(80) но ты проиграл ))

(81) А не надо всем

(82) А ты и вовсе не играл

(82) погоди, вот скоро будет новый убивца 1с с блекджеком и "правильным" срезом последних)

(0) Я так понимаю тебе нужны две таблицы:
То что сейчас называется срез - назвать НикальностьПоследних(), А то что ты хочешь назвать СрезПоследних()

(71) Срез последних формируется по всем реквизитам, заданным в структуре регистра. Только такой функционал заложен в платформу.
Это не дыра, и не ошибка. Это штатное поведение программы.

Если тебе нужно получать срез последних не по всем реквизитам - получай запросом.

К (86) Описался
"То что сейчас называется срез - назвать УникальностьПоследних(), А то что ты хочешь получить на выходе назвать СрезПоследних()".

(0) Представь что у тебя чистый SQL, и нет там никаких ни срезов последних, ни уникальностей последних. Красота! :-)
Из минусов, только то что в 1С нет чистого SQL, а есть сильно обрезанный. :-)

1С реализовала Срез последних так как задумали и назвали они это так как назвали.

(87) Это - штатная ошибка. Назовем это так )))

(90) Нет. Это максимум - не совсем корректно назвали Срез срезом.

(88) Зачем плодить лишние сущности? Достаточно того, чтобы срез последних выдавал действительно последние записи и все

(92) А если нужны уникальности последних?

(93) Задай в запросе полный комплект измерений

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

(95) Дай кейс на этот случай. Я пока не вижу - где это могло бы быть полезно

(0) 1С реализовала то, что реализовала. Другого пока ничего нет.
Пишите им (1С) на телеграмм канал, что бы вы хотели видеть в будущем. Такой канал от самой фирмы 1С есть.

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

(97) Я лучше в Спортлото напишу )))

(98) Мне кажется, что этот кейс слабее моего

(96) На самом деле всегда проектируют Рс так что бы нужен был срез по всем измерениям. Если вам нужен не по всем, то надо смотреть сам РС.

(96) просто поймите, чтобы получить одну запись верную надо полностью отобрать измерения. Тогда вы получите верный последний ресурс. Если же вы не отобрали, тогда что у вас может быть не верная 1 запись, что 1с выплюнет несколько записей, из которых вам нужна 1 а остальные не нужные. В общем, в любом кейсе вам все равно нужно указывать все измерения для получения верной 1 записи.

(99) Если не напишите, то они и не узнают о такой необходимости. Пишите им в 1С обязательно.

(103) Обязательно СС:Спортлото, Лига сексуальных реформ не забыть добавиьт...

(100) см. (101)
Если бы 1С поддерживал все конструкции стандартного SQL, то такими таблицами как СрезПоследних и СрезПервых вы бы не могли не пользоваться, а легко написать свой запрос, который бы вытащил необходимые вам данные. Сейчас тоже можно, но с левыми JOIN.

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

(100) Если брать ваше трактование среза, то в срезе Последних в платформе 1С сейчас есть возможность указать только Период и Условие (отбор), но нет возможности указать перечень измерений, в разрезе которых необходимо считать это срез. То что вы какие-то поля указываете в ВЫБРАТЬ, это не имеет ровным счетом никакого отношения в самому срезу, так как ВЫБРАТЬ выполняется уже позже на основе результата из Среза.
Надеюсь так понятно объяснил?

К (105) Описался
"вы бы МОГЛИ не пользоваться, "

(107) При том что автора (0) не поддерживаю, аргумент на самом деле слабый.
Например, в таблице остатков тоже не указываются измерения - но ресурсы тем не менее сворачиваются по задействованным измерениям.

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

(107) У ТС проблема с логикой. Он хочет "какую-нибудь" запись в случае совпадения периодов.

(109) Ещё раз прочитай внимательно (107).
1С реализовала срез последних так как она его реализовала. Если не в разрезе всех измерений необходимо вытаскивать срез, значит как-то странно спроектирован РС.

Что такое СрезПоследних с точки зрения чтения в языке запросов 1С - по большому счету это подзапрос. Реализован технически он иначе, но это НЕ с точки зрения его понимания при написании запроса.
Если упрощенно, то срез это вот такая некая запись:

ВЫБРАТЬ
     СРЕЗПОСЛЕДНИХ.Поле
    ,....
ИЗ
    (ВЫБРАТЬ
          т.Измерение1, т.Измерение2, ... ,т.ИзмерениеN
         ,т.Ресурс1, т.Ресурс2,...,т.РесурсN
         ,т.Реквизит1, т.Реквизит2,....,т.РеквизитN
     ИЗ
     ...
         <Условие на период>
         <Условие на прочие поля>
     ...
    ) КАК СРЕЗПОСЛЕДНИХ

(110) Да это понятно. Я пытаюсь уже с другой стороны объяснить.

(109) "Например, в таблице остатков тоже не указываются измерения" - в остатках есть агрегатная функция SUM() по ресурсам. Всё остальное хотя бы можно свернуть. И не надо таблицу остатков воспринимать как подзапрос по аналогии с РС - это не так.

В РС нет никаких агрегатных функций. Никак и ни чего свернуть нельзя.

Вот так в 1С реализованы дополнительные источники данных и так работает язык запросов. Так он задуман и так он всех устраивает.

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

(112) В регистре два измерения "Поставщик" и "Номенклатура". Иногда нужны последние цены по двум измерениям, а иногда только по "Номенклатуре". Так бывает... почти всегда. В реальном мире сущности так соотносятся друг с другом. При вашем подходе получается, что я должен создать и поддерживать отдельный регистр с одним измерением. А теперь представьте что у меня четыре измерения. Сколько я должен буду создать дополнительных регистров?

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

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

(113) Вы не слушаете даже. И выше писали и в (110) коротко даже резюмировали. Вы это в упор не видите.

(116) Что там резюмировали? Что моя схема выдаст дубли? Так и 1С сейчас выдает дубли. Только 1С выдает еще и старые дубли

(117) Неа.... резюмировали, то что если выдавать НЕ дубли, как Вам необходимо, то что?
"какую-нибудь" запись.
"какую-нибудь" - это какую? Какая из записей с разным значением ресурса будет более правильная?

Я уже и с другой стороны объяснить пытался. Но всё тщетно.

Считайте что для Вас среза не существует, есть просто таблица с движениями. Пишите свой срез. Шутка. :-)

(118) Есть три варианта решения вопроса дубля:

1. Оставить дубли
2. Выдавать максимум
3. Выдавать минимум

Меня бы устроил любой вариант

(119) Так они все есть.
1. Как и есть.
2. Примени в выборке к полю ресурса Макс()
2. Примени в выборке к полю ресурса Мин()

Короткий текст запроса брось сюда если есть сложности. Подскажут как взязть максимум или минимум.

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

(121) У меня (в отличии от 1С) сложностей нет

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

(121) Но все равно, спасибо!

(124) я уже и не про срез, а про решение задачи.
те запрос с условиями (122) будет сложнее чем без них

если (122) не нужно, то проще взять срез и его свернуть взяв МАКС по ресурсу

(124) Я решал (и решил, еще до того, как написал сюда) задачу именно среза, и именно по одному измерению

(127) Срез вернет лишние записи (не последние)

(128) просто вы по своему поняли определение среза и не удосужились прочитать официальную инфу по данному методу. Вот и суть всей этой ветки.

(129) он вернет, а потом ты сгруппируешь

(129) это для вас они лишние, а по логике 1с они не лишние, а кому то даже очень нужные. Это вам не регистр накопления, где можно пропустить какие то измерения и ресурс чудесным образом сложится. В РС все должно быть точно и не должно быть неопределенностей в результате

(131) хотя нет, не сработает, там период может же быть другой.
надо самому разворачивать срез

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

так не понимать - это надо талант иметь. да что там талант - талантище!

(119) А я хочу Среднее.

Я один так и не понял, какого поведения ожидал ТС? И что он понимает под "срез по одному измерению"?

(137) ну типа есть у вас:
10.05.2021 Закупочная морковь 45р
11.05.2021 Закупочная морковь 46р
10.05.2021 Продажная морковь 60р
11.05.2021 Продажная морковь 63р
По "логике" ТС, при отборе среза последних по морковке он хочет чтобы 1ска однозначна выдала лишь:
11.05.2021 Продажная морковь 63р
Почему он это требует от нее я хз. 1с здорового человека выдает
11.05.2021 Закупочная морковь 46р
11.05.2021 Продажная морковь 63р
Даже если не указан вид цены, то все равно будет результат из 2 строк. Для более точного результата 1с требует указать ВСЕ измерения. В данном случае вид цены и это нормально!

(138) А, он просто не знает про ПЕРВЫЕ 1? Ясно.

(0) И этот человек ведет курсы в Бауманке.
Это жестяночка.

(140) курсы 1с?

(141) Ну да.

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

пора ему на марс лететь, город там строить

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

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

А, не, отбой тревоги. Уже не ведет походу.
https://www.specialist.ru/course/1s831?src=anons

но интернеты помнют.

https://webcache.googleusercontent.com/search?q=cache:li2DyNqDU_MJ:https://www.specialist.ru/center/coursetrainers/1s831+&cd=1&hl=ru&ct=clnk&gl=ru

(147) эх... не услышу я лекцию из уст ТС про архитектурные решения РС(

(145) Если не обращать внимания на часть измерений, то "последних" записей будет несколько в общем случае (как и в примере (138) ). То есть в случае ТС все равно нужно использовать ПЕРВЫЕ 1. То есть овчинка выделки не стоит.

(140) А я то сначала подумал, что это новый ник ливингстара, хехе.

(149) ПЕРВЫЕ не лечат. Разве что через коррелирующий подзапрос. В общем случае ведь не по единственному значению данные получать надо. Понятно, что выкрутиться можно. Я просто отвечал на твой вопрос.

(147) С чего взято, что это кто-то из этих курсов?

(152) Это Калимулин вроде. Он использует такой ник. Тусовался раньше под своим именем и вроде как под этим тут тоже деанонимизировался. Но зуб не дам.

(153) весной была его ветка на тему "зачем нужны регистры..." там вроде и деанонимизация прошла)

(154) Точно! Он там ссылку на свою статью на хабре давал.

(155) Именно.

https://habr.com/ru/users/exwill/

Как в анекдоте получается.
Один доцент другому:
- Вот студенты тупые пошли! Я им раз объяснил. Второй раз объяснил. Уже сам понял, а они не могут понять.

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

(159) Пытался уже... Вообще не понял о чём. По всей видимости я совсем серая масса и об этом до сих пор не думаю.
Тут нет стёба. Я реально не понимаю о чём там.

(160) А то. Не только лишь все могут в завтрашний день смотреть.

(159) (160) (161) Художники - странные люди.

Художника обидеть каждый может.

(143) Написать вам статью?

(145) Ничего этого не надо. Просто формировать срез по набору измерений, который указан в запросе. В РН же это так работает

(137) См. (18)

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

(138) Вы неточно передаете, что я хочу. Я хочу чтобы в результате было:

Морковь 63р.
Морковь 46р.

или

Морковь 63р.

или

Морковь 46р.

Меня бы устроил любой из этих трех вариантов

(165) Вам ведь уже много раз пытались донести мысль, что в РН есть агрегация ресурсов, а в РС ее нет. Отсюда и принципиальная разница в работе с измерениями.
(166) Вам на этот пример уже привели контрпример, с данными:

01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.02.2021 ООО Ромашка Свистелка 106 руб.

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

(167) Сейчас неопределенности, как раз, нет. Текущее поведение логично и, что главное, задокументировано.

(168) А меня ни один из них не устраивает. Хочу среднее арифметическое.

(169) Сейчас есть задокументированная неопределенность

(170) Ее нет. Неопределённость пытаетесь создать вы. Из приведённых вами примеров в (168) ни один вариант не имеет явной причины для существования. И, да, я хочу среднее арифметическое. Почему нет этого варианта?

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

(172) то же самое кстати, касается и cte. Одно дело = транслировать запрос с общими табличными выражениями для СУБД, которые это поддерживают. И совсем другое - реализовать этот функционал, с его основной фичей -рекурсивным запросом -  на файловом, чисто одинэсном  движке. То же касается и апдейтов во временных таблицах. Было бы иногда прикольно создать каркас временной таблицы, и дальше в пакете отдельным запросами заполнять ее поля. Но тоже нет.

(171) Потому что нет кейса

(167) "неопределенности не должно быть" + (168) "неопределенность меня устроит" — ты сам себе противоречишь.

(175) В этом посте (167) я обращаю внимание на то, что неопределенности и сейчас есть

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

(173) Да ладно, это не бог весть какая задача, не надо преувеличивать. Если будет реальная потребность, реализуют.

(173) Файловую в топку и тогда можно будет в 1С нормальный SQL использовать. Нет нормльного SQL так как есть файловая и это надо там реализовывать. Хотя есть бесплатный SQL постгри.
Сделали бы спец лицензию с сервером 1С и на SQL постгри - в замен файловой и всего делов. Не надо файловой тормозить развитие функционала, который бы существенно упростил разработку и существенно ускорил бы работу запросов в 1С. Мы бы имели возможность писать короткие понятные запросы, а не миллион вложенных внутренних таблиц и подзапросов с тучей JOIN.

(176) Уже сказали как её обойти.
Выбрать
       т.Измерение1
      ,т.Измерение3
      ,ИмяАгрегатнойФункции(т.Ресурс1)
из
      РегистрСвдедений.ИмяРегистра.СрезПоследних(&ДатаСреза, ) как т
Сгруппировать по
       т.Измерение1
      ,т.Измерение3

(179) это если периоды совпадут, то агрегатная функция, если различные - то будет неправильно

(180) Неправильно это как?

В (179) Не выбирается период. Поэтому разные периоды или не разные - фиолетово. Далее всё свернется по измерениям.

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

(178) Нет. Именно потому, что не такая большая проблема, и именно потому что есть файловая, совместимость с которой задекларирована.
Возможно, когда-нибудь 1с решатся и провозгласят. что есть две разных 1С - одна для ларьков, собственно,  - а вторая - для солидных господ. А пока есть файловая СУБД от 1с. и пока ими декларируется обоюдная совместимость(которой кстати изначально нет и не было - по длине индексов)- всех этих плюшек "взрослых" СУБД - ждать самонадеянно.

(178) Повторюсь - это огромная разница между тем чтобы транслировать Запрос.Текст с тем же cte - в запрос СУБД, которая поддерживает этот механизм. То есть это просто преобразование текста по сути.
И совсем другое - допилить свой движок запросов, чтобы он понимал и умел обрабатывать эту инструкцию.

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

with data as
    (Select
     '2017-01-10' as d
    ,'sklad_1' as sklad
    ,'tovar_1' as tov
    ,10 as cena

    union all select '2017-02-23', 'sklad_1', 'tovar_1', 20
    union all select '2017-02-23', 'sklad_2', 'tovar_2', 30
    union all select '2017-02-25', 'sklad_2', 'tovar_1', 40
    union all select '2017-02-28', 'sklad_1', 'tovar_1', 50
    union all select '2017-03-15', 'sklad_1', 'tovar_1', 60
    union all select '2017-03-23', 'sklad_1', 'tovar_1', 70
    union all select '2017-03-23', 'sklad_2', 'tovar_1', 80
    union all select '2017-03-23', 'sklad_1', 'tovar_2', 90
    union all select '2017-03-23', 'sklad_2', 'tovar_2', 100
    union all select '2017-03-25', 'sklad_1', 'tovar_2', 110
    union all select '2017-03-26', 'sklad_2', 'tovar_1', 120
    union all select '2017-03-28', 'sklad_1', 'tovar_1', 130
    )
select
    *
from
    (select
         d
        ,tov
        ,cena
        ,row_number() over(partition by tov order by d) as npp
        ,count(*) over(partition by tov) as Max_tov
    from
        data
    where
        d <= '2017-03-23'
    ) as t
where
    t.npp = t.max_tov


Результат даст:
d            tov    cena    npp    Max_tov
2017-03-23    tovar_1    80    7    7
2017-03-23    tovar_2    100    3    3

,row_number() over(partition by tov order by d,cena desc) as npp

результат:
d        tov    cena    npp    Max_tov
2017-03-23    tovar_1    70    7    7
2017-03-23    tovar_2    90    3    3

,row_number() over(partition by tov order by d,cena) as npp
результат:
d        tov    cena    npp    Max_tov
2017-03-23    tovar_1    80    7    7
2017-03-23    tovar_2    100    3    3

Так же можно прикрутить агрегатные функции среднего логарифма синуса и косинуса - любой каприз. :-)
Можно получать несколько записей и далее брать МИН МАКС у даты и применять агрегатную функцию к ресурсу.

(0) Собственно Вы какой результат хотите?

Аналог типового среза наверное будет такой, только в итоговой выборке не все поля *, а перечисление всех измерений, ресурсов и реквизитов.
В оконной функции в конструкции "partition by sklad,tov,...." перечисление всех измерений.
Но опять же это не лучший и не единственный вариант получения среза.

select
    *
from
    (select
         *
        ,row_number() over(partition by sklad,tov order by d) as npp
        ,count(*) over(partition by sklad,tov) as Max_tov
    from
        data

    where
        d <= '2017-03-23'
        AND <Тут условия по виртуальной таблице>
    ) as t
where
    t.npp = t.max_tov

(188) Я хочу чтобы из исходных данных:

01.02.1999 ООО Лихие девяностые Свистелка 10 руб.
01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.03.2021 ООО Ромашка Свистелка 106 руб.
01.03.2021 ООО Василек Свистелка 107 руб.

В срез последних не попадали данные из прошлого века

(190) В (186) и (187) есть все ответы и такой вариант тоже есть.

(177) Срез последних не обязательно привязывать к уникальности. У самой 1С они по факту отвязаны друг от друга. Срез последних - это ПОСЛЕДНИЕ записи. Например, для набора данных:

01.02.1999 ООО Лихие девяностые Свистелка 10 руб.
01.02.2021 ООО Одуванчик Свистелка 105 руб.
01.03.2021 ООО Ромашка Свистелка 106 руб.
01.03.2021 ООО Василек Свистелка 107 руб.

Срез последних по номенклатуре это:

01.03.2021 Свистелка 106 руб.
01.03.2021 Василек Свистелка 107 руб.

а не:

01.02.1999 Свистелка 10 руб.
01.02.2021 Свистелка 105 руб.
01.03.2021 Свистелка 106 руб.
01.03.2021 Свистелка 107 руб.

как делает 1С сейчас

Думаю, что нужно прекратить кормить тролля и закрыть ветку КЁМ. И даже если это не тролль, то закрыть её за непроходимую тупость топикстартера. Простите за мое скромное мнение, если что не так.

(192) Напишите в 1С, что СрезПоследних() не достаточно и есть острая необходимость в дополнительной конструкции СрезПослденихСовсемПоследних().
Как видите по (186) и (187) эти варианты проще в реализации, чем аналог типового среза в (189).

Дело за малым - определиться с кусочком "order by d,cena desc". DESC или не DESC использовать и там по мелочи.

(194) хе хе, да :-)

(185) И я повторюсь, реализовать CTE в файловом движке не так уж сложно. Потому, что сам движок намного проще "взрослых" СУБД. В крайнем случае можно реализовать через временные таблицы.

В SQLite давно есть и CTE, и оконные функции, и много чего еще. А его пилит практически один человек.

(193) За 8 лет всего 1054 сообщения и всего три темы и тут не выдержал :-)

(192)Ты т.е. ты хочешь, чтобы в 1с был ИИ, который был определял, какой именно срез нужен тебе в данном случае?) В рамках указанной структуры регистра, всё выводит как надо. Дальше уже можно своими силами его обработать как нужно(например взять максимум по периоду)

Скоро абсолютные читатели начнут писать :-)

(197) Да, иногда могу себя не сдерживать.

(192) Срез последних — это последние записи в разрезе измерений регистра. И для каждого набора значений измерений последняя запись всегда одна. Так работает периодический регистр сведений 1С.

А что хочешь ты, я так толком и не понял. Если хочешь серьезного разговора, напряги мозги и роди формальное определение, не допускающее разных толкований и пригодное к реализации. А с такими хотелками, как "не попадали данные из прошлого века" тебя кто угодно пошлет, не только разработчики платформы.

Не уподобляйся Гению с его ламерским подходом к сложным вопросам.

(196) Ну, не знаю.... 1С только обещает в 8.3.20 несколько математических функций добавить и на этом всё.
Оконные функции существуют около десятка лет. Зачастую их использование дает прирост в скорости в несколько порядков, по сравнению с классическими запросами.
А в 1С тем временем, примерно в момент появления оконных функций решило ускоряться путем внедрения тонкого клиента и управляемых форм - по крайней мере в начале это была одна из главных причин. Как итог эти управляемые формы работают по ощущениям только медленнее чем обычные. Понятно что управляемые формы и тонкого клиента внедряли не для ускорения, но продавали это в самом начале именно так.

К (202)
Не проверял, но тут:
https://habr.com/ru/post/474458/

такая информация:

"Необходимый инструмент – оконные функции – впервые появился только стандарте SQL:2003. К этому моменту они уже были в Oracle (версия 8i). А вот реализация в других СУБД задержалась на 5-10 лет: SQL Server 2012, MySQL 8.0.2 (2018 год), MariaDB 10.2.0 (2017 год), PostgreSQL 8.4 (2009 год), DB2 9 для z/OS (2007 год), и даже SQLite 3.25 (2018 год)."

(196) "А его пилит практически один человек." - этому человеку памятник надо поставить. SQLite Просто шедевр.
Или пригласить его за 1 000 000 в день что бы допилил запросы в 1С. :-)

(203)
"Производительность оконных функций будет зависеть от специфики вашей СУБД (и её версии!), размеров таблицы, и наличия индексов. Но в большинстве случаев этот метод будет самым эффективным. Тем не менее, оконные функции недоступны в старых версиях СУБД (которые ещё в ходу). Кроме того, их нет в таких СУБД как Microsoft Access и SAP/Sybase ASE. Если необходимо вендоро-независимое решение, следует обратить внимание на альтернативы."

Вот чем надо с SAP бороться.

(201): строго говоря - он хочет виртуальную таблицу среза последних такую, для которой при ее параметризации можно было указать любое сочетание измерений, по которому бы выдавался срез. типа
рс: (период) измерение1 изменение2 ... измерениеN ресурс1 ...
запрос виртуальной таблицы. чтобы поимо параметра "Пеиод" и условий - можно было еще в какой-нибудь параметр засунуть список имен измерений, по которым бы выдавался срез (а не по всем). ну типа
рс: (период) изм:Номенклатура изм:Поставщик изм:ГородДоставки рес:Цена
а ему в запрос надо виртуальную таблицу среза последних стобы через параметры этой вирт.таблицы можно было указать - что нужен срез этот по измерению Номенклатура и Поставщик - т.е. последние с игнором измерения ГородДоставки.
чухня жуткая, даже не придумывается - где это может пригодиться при том, что стандартный срез последних позволяет выдернуть это же самое по любому комплекту интересующих/игнорируемых измерений.
я же говорю - типичная разруха в голове.

(195) Пусть человек напишет (без сарказма, а на полном серьёзе).
И каждый пусть напишет. И чем больше человек напишет, тем быстрее 1С прикрутит нам счастье в виде оконных функций. Пусть в 1С 9.0, но прикрутит.
Данная задача должна стать приоритетной для 1С.
За что чаще всего критикуют 1С - правильно за неповоротливость и долгую работу. А тут хоть переписанные отчеты летать начнут.

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

(208) А Релиз уже вышел?

(209) А за счет чего оконные функции дают прирост?

(209) Я знаю не больше вас - то что было заявлено в Зазеркалье.
И я пока еще не уверен, это будут нативные функции СУБД, или родная "постобработка" - т.е. поля, которые тут же в запросе не получится использовать.

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

(207) >1С прикрутит нам счастье в виде оконных функций.
Есть же СКД, где на движке 1с реализуются аналоги оконных функций, и есть даже расширенный STRING_AGG ()

(210) Поля, которые получаются с помощью оконной функции заполняются за один проход. А информация, которая может быть содержаться при этом в этом поле может помочь отказаться использоваться от разных не нужных JOIN, которые могли использоваться ранее для решения необходимых задач. JOIN - убийца производительности запросов. Если задачу можно решить без JOIN, то нужно решать без JOIN.

(214) и ЕЩЕ раз.

Вот  у меня запрос, с джоин

ВЫБРАТЬ
    ТоварыНаСкладах.Номенклатура КАК Номенклатура,
    Номенклатура.Наименование КАК Наименование
ИЗ
    РегистрНакопления.ТоварыНаСкладах КАК ТоварыНаСкладах
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
        ПО ТоварыНаСкладах.Номенклатура = Номенклатура.Ссылка

Как оконная функция поможет его обойти?

(213)  Прелесть оконных функций, что далее по запросы используется их результат в логике задачи, а не просто результат для показать.
Посмотри внимательно на (186), (187), (189). Сами поля npp и max_tov (правлиьнее назвать max_npp) как результат итогового запроса вообще не нужны. Их результаты нужны только для выполнения логики запроса, для решения задачи.

(217) Плохой пример. Оконные функции помогают, когда источник данных одна и та же таблица.
Например посчитать нарастающим итогом сумму. Срез какой-то и т.д.

(217) 8.3 Накопленный итог запросом
Тут в посте 21 пример, когда надо по РС построить таблицу с периодами изменения.

(219) Так. Работает только с одной таблицей? Типа буфера, так?

(221)
На входе:
with data as
    (Select '2017-01-10' as d, 'rabotaet' as s
    union all select '2017-02-23', 'rabotaet'
    union all select '2017-02-28', 'otpusk'
    union all select '2017-03-11', 'bolnichniy'
    union all select '2017-03-15', 'bolnichniy'
    union all select '2017-03-17', 'bolnichniy'
    union all select '2017-03-30', 'rabotaet'
    union all select '2017-04-02', 'rabotaet'
    union all select '2017-04-08', 'otpusk'
    union all select '2017-04-14', 'rabotaet'
    union all select '2017-04-28', 'uvolen'
    )

Надо получить на выходе таблицу:
dateN    dateK    s
2017-01-10    2017-02-27    rabotaet
2017-02-28    2017-03-10    otpusk
2017-03-11    2017-03-29    bolnichniy
2017-03-30    2017-04-07    rabotaet
2017-04-08    2017-04-13    otpusk
2017-04-14    2017-04-27    rabotaet
2017-04-28    NULL    uvolen

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

Данную задаче решает вот такой простой запрос без использования JOIN, но с использованием оконных функций:
select
     t.d as dateN
    ,Cast(DateADD(day, -1, LEAD(t.d) OVER(ORDER BY t.d)) as date) dateK
    ,t.s
from
    (select
         t.d
        ,t.s
        ,LAG(t.s) OVER(ORDER BY t.d) prev_s
    from
        data as t

    ) as t
where

    t.s <> t.prev_s
    or t.prev_s is null

(222) Нахрена это?

(222) Вы маетесь ерундой и 1С правильно делает, что не дает вам инструменты для ваших извращений.

(222) Запрос должен вытаскивать данные из базы наиболее просто и наиболее точно. Всё.

Обрабатывать данные вы должны не в запросе, а в коде.

(223) Реши данную задачу с помощью запроса без оконных функций. Решение есть в посте (17) в ветке, которая указана в (220).
Реши с помощью кода.
Посмотри на объем написанного текста.
Замерь производительность.
Убедись что запрос в (222) быстрее всех и количество написанного текста в нем минимальна.

(224) Не согласен.
(225) Как раз это и делает запрос в (222). Просто быстро и коротко.
(226) Если мне нужен результат в отчет и я его могу получить простым и коротким запросом, то зачем что-то обрабатывать?

Все так думают как в H A D G E H O G s ?
Кто думает не так?

Хоть голосовалку открывай и отдельную тему. Только не вижу я в этом смысла. Эта ветка и так сплошной - не пойми что. Автор ветки постарался. Аш, читатели форума писать начали. :-) Фантастика.

(182) вот это и плохо

(227) А я с вами согласен. Оконные функции - полезная и нужная штука. Вообще, чем ближе 1С язык запросов подведёт к современным фичам SQL, тем лучше. Другой вопрос в том, что порог входа для понимания чужих запросов подрастёт существенно, т.к. в современных фичах много неочевидных вещей. Тот же CROSS/OUTER APPLY, очень эффективный инструмент, довольно сложен для понимания "среднему" 1С-нику без хорошей базы разработчика.

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

(0) Запрос покажи свой, который не работает, как срез последнего :)

+ Вдогонку огласи релиз и версию конфы.
+ Для ленивых, напиши тут Имярегистра, и его структуру:
     Измерения...
     Ресурс....
     Реквизит...
   Периодичность, Регистратор (Да/ Нет) :)))

(230) Там на второй странице градус неадеквата существенно растёт :)

(164) Будьте любезны, желательно в разрезе различных бизнес-процессов.

(234) путь гени вижу я)

(235) не... Вот когда видео начнёт снимать...

(236) можно и на видео лекцию запилить, показать как отрабатывает срез последних/первых, какой запрос в итоге получает скуль, в каких вариантах лучше использовать РС, как его правильно строить  и чем он отличается от того же справочника (можно в разрезе того же скуля). А далее можно взять несколько типовых бизнес-процессов и показать как регистры сведений помогают для их реализации. В конце что-нить резюмировать и вуаля, даешь понимание РС для новичков)

(198) Зачем сразу ИИ? Какой набор измерений задал в запросе, по такому и строится срез

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

(238) А как 1ске понять без ИИ, какую из 2х записей дать в результате, если период одинаковый?

(240) вам же не нравится самому выбирать нужный результат из 2х записей, вы хотите чтобы 1ска за вас решала

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

(206) Зачем параметр? Есть список полей запроса. Этого достаточно

(239) см. (34)

(230) Я предлагаю получать последние значения там, где 1С выдает не последние (хотя обращение идет к срезуПОСЛЕДНИХ). Где бред?

(244) И что?

(240) Можно выдавать обе

(247) Она и выдаёт обе.

(248) Она выдает больше, чем обе. Она выдает не только последние, а я предлагаю только последние

(249) И будет каша: по каким-то наборам измерений будет 2 записи, по каким-то - одна.

(250) Так и сейчас каша

(251) Сейчас не каша, сейчас четкая, прозрачная и задокументированная логика. А вот в вашем варианте - каша. Но, по факту, такая ситуация - это ошибка проектирования регистров в прикладном решении.

Каша не результатах.
Каша у кого-то в голове. Наверное, водицы с Солнца попил

(95) заведи второй регист

(243) пойми что субд отбирает _строки_ а не поля

(251) Еще раз внимательно прочитайте пожалуйста (194).

(223) Попробовал (227) или нет?

(229) Ветка будит абсолютных читателей (не писателей) форума. :-)

(252) Нет никакой ошибки в проектировании. Например, когда я проектирую РН продажи, я задаю измерения "номенклатура", "контрагент", "склад". А потом получаю продажи по любому набору измерений. И я не делаю ШЕСТЬ регистров, чтобы решить эту задачу. Я делаю один и это правильно

(254) См (259)

(259) "И я не делаю ШЕСТЬ регистров, чтобы решить эту задачу. Я делаю один и это правильно"
то есть, разнеся остатки и резервы по разным регистрам - архитектор типовой УТ11 - сделал неправильно?

(259) см. (112)

(261) Сколько измерений в регистре продажи в УТ11?

(263) еврей?

(262) Не вижу там дополнительной информации

(264) У меня просто нет под рукой

(265) Когда вы прекратите сравнивать РН и РС?
В РН ресурс всегда число. И остатки это всегда агрегатная функция SUM(). На входе есть все данные что бы свернуть.
В РС ресурс - это что угодно и нет никакой агрегатной функции.

(259) А вас не смущает наличие двух регистров для учета Товаров во многих решениях? Один только количество, другой еще стоимость и партии.

Короче, пора закрывать ветку.
Автор считаем себя самым умным.
Бывает.
Проходит со временем.

(269) Автор не молод. Уже не пройдет.

(267) автор не хочет этого понимать...

(223)  Попробовал (227) или нет?

(267) Агрегатная функция есть всегда. МИНИМУМ(МАКСИМУМ) работают с чем угодно. Но дело даже не в этом. Сравнение совершенно обосновано. Срез последних мог бы работать точно так же, как работает SUM() в РН. И это было бы более логично, чем то, что мы имеем сейчас. Получать срез можно по любому набору измерений

(273) А где Вы сказали СРезуПоследних() Вам МИН() или МАКС() ?
Такая опция в нем не предусмотрена.

Ещё раз прочитайте (194). Ответ уже дан.

(274) Там нет никакой дополнительной информации

(274) Кратко резюмирую обсуждение.
В принципе есть возможность получать последние записи по любому набору измерений? Ответ - есть.
Это в чем-то сложнее, чем получать последние записи по полному набору измерений? Ответ - нет.
Почему 1С это не делает? Ответ - потому что для неполного набора измерений возможно появление дублей.
Если сейчас выполнить запрос к срезу последних по неполному набору измерений, дублей не будет? Ответ - дубли будут.
Тогда почему бы не получать последние записи? Ответ - будут дубли.
А сейчас дублей нет? Ответ - сейчас есть.
А почему тогда... Потому что, гладиолус

(276) Неверный вывод.

(277) В каком месте?

(238) срез возвращает таблицу, а ты хочешь одно значение. Это так не работает. Если смущает слово СРЕЗ - ну что ж, с этим нужно смириться.

(279) Я тоже хочу таблицу

(276) потому что делая запрос, указывая не не все измерения в отборе, 1ска полагает, что вы хотите получить срез последний по всем уникальным связям. К примеру вы захотите посмотреть все последние цены по номенклатуре в разрезе видов цен. И 1ска это сделает, если же вы не укажите в выводе вид цены, то и смысла делать такой отбор - нет. Какое то одно значение из перечня цен вам номенклатура не выберет, это глупо. Еще пример, вы делаете сложный ответ и в какой нить связи с РС пропустили одно измерение. В результате отчета вы увидите дубли и поправите отчет, а в вашем варианте вы даже об этом не узнаете, вам 1ска подсунет сегодня какой нить результат, возможно даже верный.

(279) Если бы я хотел одно значение, этой темы бы не было

(280) ну так выведите все измерения в Выбрать и увидите цельную таблицу.

(276) "В принципе есть возможность получать последние записи по любому набору измерений? Ответ - есть. "   Ответ - нет. В запросах ты не можешь получить последнюю запись по неполному набору измерений+период.   Если повезет - получишь, если не повезет - не получишь.

(282) вы же сами в начале писали, чтобы 1ска какое то одна вам дало, вам без разницы какое

(281) *сложный запрос

(285) В самом начале я писал, что мне без разницы: будет это одно значение или несколько. Будьте точны

(284) Интересно, и что я получу, если "не повезет"?

(276) В 1С срез реализован так как и задуман. Задокументирован. Написаны миллионы строк кода в разных конфигурациях и все ВНИМАТЕЛЬНО прочитав документацию понимают как это работает.
Вам понадобился иной алгоритм получения своего иного среза. Но вместо того что бы написать письмо с просьбой добавить ещё одни вариант среза с дополнительными параметрами, в которых можно было бы указать Мин(), Макс() и т.д. Вы требуете что бы сейчас 1С пересмотрела свой подход к тому, что реализовано в Срезе и что всех устраивает и переписать миллионы строк кода везде.

Вот так это реально выглядит.
А ответы и даже пример реализации находится в это ветке выше.

(288) несколько записей в результате. Просто объясните, как система должна выбирать "любую" запись по неполному набору? и на сколько корректно в таком случае получать разные результаты на одних и тех же выборках?

(287) вы можете назвать хоть 1 бизнес процесс где такое поведение нужно?

(290) Он уже объяснял. Его не смущает каждый раз разный результат на одних и тех же данных.
Ему надо писать письмо в 1С - срочно.

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

(292) "ало! это одинесочная? Срочно приезжайте, у вас тут срез не правильный!")) А если серьезно, если ТС нужен такой функционал, пилишь свою библиотеку и юзаешь, на входе нужная таблица с отбором, на выходе нужный вам результат.

(293) а он не задумывался, почему в регистре цен номенклатуры нет поставщика?)

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

(294) Не, ему надо что бы резко было у всех поменяны логика Среза под его правила, переписана документация и все кинулись переписывать миллионы строк кода. А он просто в одном своем месте просто использовал. :-)
Такой вид эгоизма.

А завтра ему понадобится так же как и сейчас работает. И опять всё переписывать. :-)

(296) Да перед ним какой-нибудь финансист поставил задачу - дать ему последнюю цену закупки номенклатуры без учета поставщика. Человек страдает. Не понимает простой срез из регистра цены поставщиков ему не подходит. Ему нужно самому смотреть весь регистр и самостоятельно строить свой срез и в качестве периода использовать позицию документа поступления ТМЦ.
Собственно и всё.

К (299) Проблема что об этом за (300) постов в ветке ни разу (0) не была озвучена реальная задача. Уже бы давно дали и ответ.
Хотя он где-то написал что задачу он решил уже. Но вот возмутило его что нельзя в его случае использовать Срез. Собственно родилась ветка.

(293) ну такой кейс конечно имеет право на жизнь. Если пользователь хочет грубо оценить цену, ему не важна цена конкретного поставщика. Но тут целых 2 решения: завести отдельный регистр сведений без этого измерения, и делать срез последних, а агрегатной функцией брать максимум. В обоих случаях цель будет достигнута.

Из плюсов. Писать стали в этой ветке даже читатели форума. А это для сообщества на форуме очень хорошо.

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

(303) еще Паузы нет )

Ещё из плюсов.
Так как ветка получилась из-за автора флудной, то обсудили оконные функции и как с помощью них можно быстро получать любой срез.
Правда не все сошлись во мнении почему оконные функции это плюс.
H A D G E H O G s - против использования оконных функций и считает, что это зло. Но пока на не дал ответа быстрее у него отработали запросы на чистом SQL с оконными функциями и без и с помощью обработки на языке 1С. Да и не даст скорее всего. Сколько людей столько и мнений.

(304) нет кнопки "Сделать все" и "Сделать все хорошо"

Ни чего не понял.. Человек хочет "СрезПоследних" с Измереним номенклатура, при условии, что в РС еще есть Период, регистратор, количество, сумма и еще куча полей?)

А если у номенклатуры будет две строчки с разными датами и разными ООО.. то срезПоследних должен показать только 1 строчку а не 2-е ?


01.01.2000, Рога и Копыта, Тумбочка, 200 рублей.
02.01.2000, Рога и Копыта, Тумбочка, 201 рубля.

При таком раскладе, СрезПОследних выдаст тебе
02.01.2000, Рога и Копыта, Тумбочка, 201 рубля.

_______________________________________________________
01.01.2000, Рога и Копыта, Тумбочка, 200 рублей.
02.01.2000, Копыта и Хвосты, Тумбочка, 201 рубля.
03.01.2000, Копыта и Хвосты, Тумбочка, 201 рубля.

При таком раскладе СрезПоследних выдаст тебе 2 строчки
01.01.2000, Рога и Копыта, Тумбочка, 200 рублей.
03.01.2000, Копыта и Хвосты, Тумбочка, 201 рубля.

Так всегда было. Если хочешь что бы выдало срезПОследних без учета других измерений если они разные, так поставь в Условие, что Организация <> Рога и Копыта или еще что нибдуь, так всегда было, я даже ни когда не задумывался

(307) Не задумывался, наверное из-за того что документацию читал. А автор ветки не читал. Вся разница.

(308) Ну просто проблемы вывести так как тебе надо из РС нету. Автору не нравится по какой методики работает СрезПОследних. Ну напиши запрос чуть по другому и все. ПРоблемы то по сути нету. Автор еще даже версию платформы написал ))

и кстати 8.3.18.1208 ... очень косячная платформа.. от слова "совсем". 1с быстренько выпустили другую более адекватную. я бы сменил ее на месте автора как можно быстрее.

(290) А их и сейчас несколько. Только я хочу, чтобы в эти "несколько" попадали только ПОСЛЕДНИЕ записи

(310) у Вас разные организации как минимум в примере. она и показывает срез последних на основании в данном случаи разных организаций.
В одной организации срезпоследних такая то сумма и строка, в другой такая-то.
Если это убрать, то данные будут не верны, либо ведите организации не в одной базе а разных. что бы ООО Ромашка и ООО Василек или что там не пересикались

(306) И "Вернуть всё взад"

ООО Ромашка, продавала стулья по
100
200
300 рублей
ООО Василек продавала стулья по
100
200
310 рублей.

Логично что будет 2 строки
ооо ромашка 300 рублей
ооо василек 310 рублей.

(311) вы не понимаете, ТС хочет, чтобы срез работал по его "логике". Если 2 записи в 1 период последний, то вывести 2, но срезать все остальные записи с отличным от последнего периодом. Ему всего то нужно получить дату последней цены для номенклатуры, а потом связать по дате и и номенклатуре и получить последнюю цену без привязки поставщика, а ТС хочет чтобы так срез работал. Мол не указал какие то измерения в отборе, на тебе последние строчки по периоду. Только вот ТС не хочет понимать, что добавляя поля в "Выбрать" в запросе к регистру сведений, результат запроса не меняется, но ТС хочет чтобы от этого зависела выборка. Мол указал дай мне в разрезе поставщиков, ему стандартная логика, указал без поставщика, ему его логика. Так это не работает.

(314) Да только тогда запрос будет сложнее )) а ТС видимо не умеет)

(314) Мне кажется ТСу нужно просто помочь написать запрос, так как он хочет, что бы выводилось.
А обсуждения СрезаПоследних просто как повод))))))))

(313) вот смотрите что ТС нужно:

01.01.2020 "ООО Джонсон" чай  100р
01.03.2020 "ООО Джонсон" чай  120р

01.03.2021 "ООО Ромашка" чай  100р
02.03.2021 "ООО Ромашка" чай  120р
03.03.2021 "ООО Ромашка" чай  200р

01.03.2021 "ООО Котофей" чай  50р
02.03.2021 "ООО Котофей" чай  60р
03.03.2021 "ООО Котофей" чай  80р

Он из этой таблицы хочет получить:
03.03.2021  чай  200р
03.03.2021  чай  80р
Все остальное срезать. Вот что он понимает под срезом последних. Проще говоря ему надо все записи за последний период по отбору. А если понадобится типовое решение, то он хочет тупо добавить в запросе в Выбрать "РС.поставик, как поставщик" и вуаля, ему выдаст по его "логике":
01.03.2020 "ООО Джонсон" чай  120
03.03.2021 "ООО Ромашка" чай  200р
03.03.2021 "ООО Котофей" чай  80р

(317) но ТС всячески не хочет понять, что РС так не работает, выбор полей не меняет его результат.

(318) РН да может просуммировать ресурс, но это РС!

03.03.2021  чай  200р
03.03.2021  чай  80р
а 01.03.2020 "ООО Джонсон" чай  120р убрать, потому что число 01, а то что там еще ООО Джонсон его не волнует.. хех

03.03.2021 "ООО Ромашка" чай  200р
03.03.2021 "ООО Котофей" чай  80р
Имеют ОДНУ дату, если у первой строки будет 02.03.2021 ее то же не будет. в результате запроса.
То есть человек хочет просто крайнею цену Чая поступившего, вне зависимости от поставщика, даты, организации и цены.
Возникает вопрос, зачем? зачем ему крайняя цена даты, без других данных. Ну узнал что 03 числа ты купил ай за 80 рублей. Не понятно у кого. и что дальше?

(320) ну вот надо ему и все тут)

(321) Ну могу посоветовать выбирать Чай прямо из доков поступления) сортировать там "Дата - по убыванию" ) и "Первые 1" )
Будет у него последний час с последней ценой)))) ну не быстро, а что поделать .

последний чай*

(322) а если массив чаев? тогда первые 1 не сканает)

(311) Это не организации, а поставщики

(320) Как раз мой кейс очень показательный. Но если вам все еще не понятно, тогда представьте себе РН продажи с тремя измерениями. Контрагент, Номенклатура, Склад. Иногда нужны продажи сразу по всем измерениям. Но не менее часто (а скорее всего и чаще) нужны продажи по Контрагентам только, по Номенклатуре только, по Контрагентам и Номенклатуре, по Номенклатуре и Складу

(326) Так уже ответили что РС это не РН. Разные вещи то. Если бы они были одинаковыми, то не было бы смысла делить на РС и РН

(316) Запрос давно написан. До того, как была заведена тема

(326) Вытаскивай последнею цену чая по РН, от туда то же можно получить то что ты хочешь

(328) Это был сарказм или шутка. Просто не понятен сам вопрос, когда РС и Срез, работали так всю жизнь а сейчас уже 2021 год

(328) Покажи хоть что написал.

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

Вот пример
Измерения
1 организация
2 сотрудник

Ресурс
1 ставка


В регистре 2 записи
01.01.2000 Иванов ромашка 1
01.01.2000 Иванов васиьек 0

Делаем срез последних только для Иванова, чкакую ставку он должен вернуть?

(331) Срез через соединение. Что там смотреть? Я тему завел, чтобы проверить - не упустил ли я чего. Может 1С умеет работать логично, а я просто не знаю

(332) Срез можно строить на любом наборе измерений

(332) Обе

(333) Ну пару дней тут пишем. Интересно же взглянуть.

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

(337) точно так же как спорить стакан на половину пусть или полон.

Если бы РС работал точно так же как РН, как ты говоришь что по РН можно посмотреть в разрезе 1 измерения так что бы тебя по твоей логике устроил результат.
То зачем было бы создавать РС и РН создали бы один регистр)

Периодический РС работает по составным ключам из всех измерений. Решение логичное и простое. Так работало изначально и будет работать, потому что другие решения ведут к "двусмысленности".
Из этого срез всегда строится по составному ключу целиком, а потом разраб в запросе может делать с результатами что ему угодно, то есть, решать эти "двусмысленности".

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

(340) Ну я пытаюсь это сказать автору.. но в середине темы он все равно упоминает, что вот по РН ч могу получить результат меня удовлетворяющий
а из РС со срезом, я не могу)

(333) Покажи результат.

(342) он стесняется )

(343) Неее.... Тему на 350 постов не стесняется, а тут застеснялся - не верю.

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

(345) Всмысле не может? Может он через через "Г" написал этот запрос, ибо банально взять "Срез" не получается, что бы было 2 строки запроса))
Результат выдает, но через "Ж".. Ведь запрос так можно написать, что смотришь и плачешь потом и думаешь, кто ж писал такое.

(346) Не. Там сложно напортачить, но есть разные варианты реализации. Хотелось просто взглянуть на каком остановился.

(335) и какой в этом будет смысл?

(346) В этом запросе негде запутаться.

ВЫБРАТЬ
    ЦеныНоменклатурыПоставщиков.Номенклатура,
    МАКСИМУМ(ЦеныНоменклатурыПоставщиков.Период) КАК Период
ПОМЕСТИТЬ Т1
ИЗ
    РегистрСведений.ЦеныНоменклатурыПоставщиков КАК ЦеныНоменклатурыПоставщиков

СГРУППИРОВАТЬ ПО
    ЦеныНоменклатурыПоставщиков.Номенклатура
;

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

Я сейчас в сторону более общего решения думаю

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

(349) не отрабатывается случай 2х цен в 1 период

(346) Надеюсь про запросы в (186), (187), (189) таких мыслей нет... :-)

(351) Будут обе. Как я уже раз 50 здесь говорил, меня это устраивает

(350) какой смысл, на какой вопрос будет отвечать такой псевдо срез?

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

(349) Я так понимаю виды цен поставщиков у вас не используются?

(356) а чем помогут виды цен?

(357) выбрать верный ресурс

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

ну вместо временной будет вложенная.
легче - не особо

(349) А если так (писал на коленке, без проверки в консоле, поэтому мог где-то синтаксис упустить):

ВЫБРАТЬ Первые 9999999999999
     ЦеныНоменклатурыПоставщиков.Период
    ,ЦеныНоменклатурыПоставщиков.Номенклатура
    ,ЦеныНоменклатурыПоставщиков.Цена
    ,АвтоНомерЗаписи() как нпп
ПОМЕСТИТЬ Т1
ИЗ
    РегистрСведений.ЦеныНоменклатурыПоставщиков КАК ЦеныНоменклатурыПоставщиков
Упорядочить по
     ЦеныНоменклатурыПоставщиков.Номенклатура
    ,ЦеныНоменклатурыПоставщиков.Период Убыв
;

Выбрать
     т.Номенклатура
    ,Мин(т.нпп) как Мин_НПП
ПОМЕСТИТЬ ВТ_МИН_НПП
Из
    Т1 как т
Сгруппировать по
    т.Номенклатура
;

ВЫБРАТЬ
     т1.Период
    ,т1.Номенклатура
    ,т1.Цена
//    ,т1.НПП как нпп
//    ,т2.Мин_НПП как Мин_НПП
ИЗ
    т1 как т1
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_МИН_НПП КАК т2
        ПО Т1.Номенклатура = т2.Номенклатура
            И Т1.НПП = т2.Мин_НПП

К (361) Ещё правильнее предварительно взять срез в ВТ и уже в следующей ВТ его нуимировать. Так просто ВТ будут меньше на много.

(355) для этого регистр должен быть такой

Измерение
1. Номенклатура
Ресурс
1. Цена
Рреквизит
1. Поставщик


И все будет работать

(363) ну вообще то типовые регистры никто не меняет ради своих хотелок

(334) нельзя. структура регистра сведений не позволяет получить одно значение по неполному набору.

(363) по такому регистру не узнаешь последнюю цену от поставщика

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

(0) Посмотрел (361) + (362)?
Это твой универсальный случай?

Элементарно делается срез последних по "не всем" измерениям. Надо только не вспоминать статью Гилева "За что увольняют программистов 1С". В параметры в запросе пихаешь только дату, остальные условия в ГДЕ. Работает 100%. Но некошерно...

(354) Мой срез будет выдавать последние записи

(359) Заказчик просил таблицу

(363) Во-первых, типовые регистры нет смысла трогать, когда просят всего лишь сиюсекундный отчет.
А во-вторых, рассмотрите общую ситуацию. Если у вас два измерения, тогда нужно делать три регистра, чтобы закрыть все возможные варианты.
Для трех измерений потребуется шесть регистров. Для четырех тринадцать

(369) И какое условие я должен был поставить в ГДЕ, чтобы получить последние?

(368) Зачем так сложно? В (349) проще

(373) Оно ставится не в ГДЕ
(374) Что сложного?

(293) То есть он хочет, чтобы алгоритм (запрос) для решения его одной частной задачи 1С вкрячила в платформу? То есть вся гибкость языка запросов не нужна, хочу просто обратиться к виртуальной таблице Регистр.СрезИмениBrainguard()?

Понятно. Ну что ж, хотеть не вредно.

(376) Это - не частная задача, а вполне общая. И все, что я хочу - это чтобы при обращении к виртуальной таблице среза последних мне выдавали последние записи. Что в этом странного?

"Делаем запрос по одному измерению "номенклатура" и не получаем срез последних по этому измерению" ... Ты сам себе противоречишь, как можно получить "множественное число", по одному измерению? Это же срез -"ПОСЛЕДНИХ", а не "ПОСЛЕДНЕГО"))

(378) Это - срез последних записей. Количество измерений здесь ни при чем

(375) Аааа. Сразу не увидел. Ты решил задачу получения любой записи. Ничего так, годная штука. АвтоНомерЗаписи() быстро работает?

ок, без проблем, я просто пошутил))

Как мы писали "Срез последних" в 7.7? Точнее, вообще - осуществляли. Вспомните, наложите на современный мир и поймете, что удобнее и логичнее, а что нет.

Кстати, кто-нибудь хоть раз использовал срез первых?

(377) Странно то, средств для решения твоей задачи вполне достаточно и сейчас, по твоим же словам. А оснований для реализации в виде вирт. таблицы я не вижу.

А насчет того, частная это задача или общая — приведи свою реальную задачу, где это нужно, посмотрим. Я вот ни разу такой не встречал, но может просто не попадалось. И никто больше здесь не написал "да, я тоже с такой задачей сталкивался, решил так-то".

(383) Я как-то использовал один раз, зачем, уже не помню.

(380) Очень быстро.

(380) Возьми самую длинную таблицу, которая есть в Вашей базе, что бы она влезла в ПОМЕСТИТЬ.
Два запроса с АвтоНомерЗаписи() несколько раз выполнить и без несколько раз. Сравнить разницу в скорости выполнения. Если конечно эта разница у Вас получиться.

(384) А и не надо дополнительных виртуальных таблиц. Пусть уже имеющаяся выдает последние записи в полном соответствии со своим названием "СрезПоследних".
Кейс я уже в самом начале привел. Два измерения "Поставщик" и "Номенклатура". Нужны последние цены по одному измерению "Номенклатура"ё

(386) (387) Спасибо! Буду знать теперь

(389) Запрос соединение: ограничение количества записей
Примерно такой же вопрос. Я сначала думал дежавю. Потом нет Автор в 7-м посте сам решение нашел.

(375) а где же если не в где? )))

(391) Чтобы получить последние записи, нужно делать соединение. Так что, не в ГДЕ , а в ПО

(392) нет, ну можно многими обходными путями идти, если много времени.
но то, что описано в (369) работает
ВЫБРАТЬ Чегото ИЗ
НашРегистрСТремяИзмерениями.СрезПоследних(&Дата)
ГДЕ
Измерение1 = &Адын И
Измерение2 = @Дыва

(393) А если так:

ВЫБРАТЬ
     Чегото
ИЗ
    НашРегистрСТремяИзмерениями.СрезПоследних(&Дата, Измерение1 = &Адын И Измерение2 = @Дыва)

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

(395) *не указано в ПАРАМЕТРАХ

(395) Ничего из сказанного не понял.
Если есть условие на измерение в резе, его в срезе и указывают, а не в ГДЕ. Связанно это с тем что сам срез в 1С строится не быстро на больших множествах, а вы при построении срез ничем не ограничиваете.
Далее уже ограничиваете трудоемко полученный результат в ГДЕ. Быстрее отработает, если вы в качестве условия передадите свои ограничение, а не в ГДЕ. Такой срез может построится на порядок, или много порядков быстрее - от данных зависит на сколько будет быстрее.

(396) "нет времени объяснять". Просто попробуй. Или прочти всю ветку.

(398) Я всю ветку прочитал. Я не понимаю о чём Вы говорите.

(398) Запросы в (393) и (394) идентичны с точки зрения получаемого результата. Но разные с точки зрения производительности. В (394) в общем случае будет быстрее и на сколько быстрее зависит от самих данных.

(398) в (189) я написал аналог запроса, который будет, скорее всего даже быстрее чем типовой СрезПослдених().
Только там вместо row_number() правильнее будет RANK() или DENSE_RANK(), по логике работы среза как он есть сейчас.
Если в 1С будут оконные функции, то СрезПоследних() и СрезПервых(), скорее всего будут не нужны. По крайней мере в той реализации, в которой они сейчас, так как они, скорее всего, будут медленнее.
Зависит от того как эти оконные функции 1С реализует и сделает ли она это когда либо.

(393) Исходные данные

01.01.2013 ООО Ромашка Свистелка 50 руб.
01.01.2021 ООО Василек Свистелка 150 руб.
01.02.2021 ООО Ландыш Свистелка 151 руб.
01.02.2021 ООО Одуванчик Свистелка 152 руб.

Как в общем случае(!) получить

01.02.2021 Свистелка 151 руб.
01.02.2021 Свистелка 152 руб.

С помощью ГДЕ?

ВЫБРАТЬ
     т.*
ИЗ
    НашРегистрСведений.СрезПоследних(, Измерение2 = @Свистелка) как т

Только там будут все четыре записи

(404) Вот-вот. С чего все и началось

(403) получишь свистелка 50. Потому что это срез последних по всем комбинациям измерений. Срез последних не выдает, насколько я помню несколько записей.

Так зачем нужны две, и что с ними планируется делать - как анализировать или разными колонками выводить?

(406) В смысле - не выдает? Не выдает неуникальные записи?

(407) Нужны последние. А сколько их будет неважно

(406) да ладно? :-)
(0) зачем вся ветка - не выдает оказывается и срез первых без учета измерений будет вместо среза последних. :-)

(406) Нет. Получишь все четыре записи

(409) Ну считай что они есть, что дальше с этим делается?

(409) Ну вот и получишь все последние по всем измерениям, которые ты не указал.

Как мне как пользователю это анализировать? На какую цифру ориентироваться?

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

(414) На любую

(411) ну да, наверное. Но в срезе последних ты ждешь одну, поэтому возьмешь первую :Р

(416) Вот пусть я специалист по закупкам и для меня "любую" не понятно. Если они сильно разные.

(417) Нет, я уже сделал нормальный срез последних, который работает по неполному набору измерений

(418) Разберешься как-нибудь. Ты ж специалист )))

(413) А мне нужны последние по измерениям, которые я указал

(421) В продолдении темы. Если так смотреть, то 1с во многом не логична. И придератся можно к чему угодно. СредПОследних так работал всегда и у него есть описания, но Вас он не устроил и вы хотите что бы он Логично работак так как вы считаете, было бы "Логичном" ))

Вот банальный пример, взять даже Запросы

...........
.....
...
Выбор
Когда
     Пупкин = &Параметр
Тогда 1
Конец как БольшойКОнец )))
......

Логичное, если Пупкин попал под Параметр, то в ячейки встанет цифра "1"..
Если не попал под Параметр, то в ячейки ни чего не встанет.
Только вот по моей логике, там должно встать цифра "0". а не оставить вообще пустым NULL
Но пока ты не допишешь
Тогда 1
Иначе 0

Ноль там не встанет. ЧТо бы ты потом легко мог математически складывать нужные ячейки.  А было бы логично, если в первом варианте ты передаешь цифру 1, то если она не встает, то логично поставить туда цифру 0. Если ты передаешь в первом варианте Строку "алалал". то логично если она не встает передавать туда пустоую строку "" и так далее. Но нет же. ПОка ты не напишешь что ты хочешь место "1" увидеть там, там будет тупо NULL
А как бы ускорило работу, если бы тебе не пришлось везде дописывать лишние строки запроса, если ты изначально хочешь записать туда только цифры допустим.
А вот если тебе надо
Тогда 1
Иначе "Лалала" или Выразить(лалала как строка(111) ну не суть.. тогда да пожалуйста..
Но нет. же.

Мне вот надо было создать отчет. Выводить в ячейки цифры по номенклатуре. не суть. И вот ты как дурак пишешь.. Тогда 1, Иначе 0, ТОгда 1 иначе 0.. ну я образно. лишний код на 50% получается))

Что бы все работало по "Логике" какой человек хочет, а не по какой написана программа. Человек должен сам создать программу себе))

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

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


Я использую его в универсальном просмотрщике базы. Поэтому в качестве источника у меня таблица значений. Можете переделать на любой источник.
Схему запроса не использовал из-за ее громоздкости
https://infostart.ru/public/1492741/

ОМГ, ты всегда такой вырвиглазный код пишешь?

(425) Мне лень на Shift-е плясать

зап. тз тзтип ))

Как кусок песни Скриптонита какого нибуть)

(426) сегодня зап, рез, а завтра уже з=Новый Запрос; р=з.Выполнить();?

(426) если уж лениться, так лениться))

(428) А после завтра я опять на форуме пишу, что бывший програмист мне нафигачил

о=ор.
о.Организация = с.Ор;
сп=О.ПолучитьОбъект
и тд и тому подобное

(428) Все эти переменные умирают через строчку. Какая разница?

(431) читабельность кода?
Не не слышал

Как ты преподавал то?

(432) В данном случае чем короче, тем читабельнее

(434) Да вообще ни разу.

(435) Это потому что у вас опыта мало

Вот данный конкретный случай:

рез=зап.Выполнить().Выгрузить();
ЗначениеВРеквизитФормы(рез, "РабочееПоле");
ЭтаФорма.Заголовок="Всего строк: "+строка(рез.количество());

Если бы не третья строка, я написал бы:

ЗначениеВРеквизитФормы(зап.Выполнить().Выгрузить(), "РабочееПоле");

Но я не могу обойтись без переменной, которая умрет через строчку. Поэтому написано, как написано. Но зачем этой переменной давать длинное имя? Для кого? Для того, кто дойдя до третьей строчки, забывает, что было в первой?

(437) Ты, видимо, не знаком с командной разработкой. Бывает.

(437) те ты считаешь себя умней тех, кто стандарты разработки писал?

(438) Я думаю, что тем, кто на третьей строчке забывает про первую, не место в команде

(439) Определенно )))

(424) Жуть.

(440) Поэтому ты до сих пор без команды?

(442) получается, это был промо-пост к своей публикации на нимфостарте.

Человек просто не заботится о своих коллегах.
Банально когда пишут "ДокРеализация. ляляляля .. лялял " Ты понимаешь что он берет найденый Документ Реализацию и что то делает с ней.
А когда пишут как в моей базе бывшие.. д.Ор.ПОлучитьОбъект(); и тд.. Ты тратишь на много больше времени, что бы понять что такое "Д" и что такое "ОР".. грубо говоря. ))
А если вы одновременно в 3-ом, разрабатываете что-то в одной конфигурации. Но это уже другая история)

(436) Нет, это потому что пишешь ты отвратительно.

Спрашивать за читабельность? У brainguard? Муа-ха-ха-ха.
ЕМНИП это тот чел, что топил за вред использования длинных мнемонических, сбивающих с толку настоящих программистов.
Мол настоящие программисты должны схватывать суть алгоритма без странных костылей в виде говорящих имен, которые легко могут ввести в заблуждение если не совсем соответствуют своему названию.
Поэтому чем бессмысленнее имена сущностей, тем более они полезны. А тем, кто не может читать обфусцированный код с листа прозревая его суть - просто не место в программировании. Это самозванцы какие-то.

(447) давайте ещё проголосуем за переменные вида
a
b
c
в коде 1с. ага.

(448) Какой смысл в голосовании? brainguard'а этим не проймешь. Он постиг дзен, а ты нет. Просветленных по определению не может быть много. Поэтому и голосование неспособно выявить истину.

(445) Ага. Сначала в ДокРеализация был документ реализации, а потом... стало так, что иногда там реализация, а иногда что-то иное.
Да, ты должен ПОНИМАТЬ что такое "Д" и что такое "ОР". Но ты также ДОЛЖЕН ПОНИМАТЬ что такое "ДокРеализация". И вовсе не из названия, а из контекста. Когда ты начинаешь ориентироваться на названия, ты вступаешь на тонкий лед. Потому что смысл переменной находится не СЛЕВА, а СПРАВА

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

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

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

(450) Это банальное нарушение правил хорошего кода. Назвать реквизит "количество", а там будет цена или вообще контрагент)

(454) Прям как
#define TRUE FALSE //счастливой отладки

(452) А ее сначала и назвали нормально. А потом что-то добавилось в процессе. Скажете, так не бывает?

(453) Спасибо. Это и было сделано. До появления ветки и после появления ветки (в универсальном варианте). Но все равно спасибо за то, что кратко и по делу

(456) в нормальной среде обработки - не бывает. Нельзя присваивать переменной ДокРеализация к примеру ДокПоступления.

Ляяя... Многократное использование переменных, меняя их типы за счёт неявной типизации - это не просто говнокод, это за гранью добра и зла.

(452) Программист обязан смотреть направо всегда. Смотреть налево нехорошо

(460) "Вас, Сидоровых, не поймёшь... Она говорит, что хорошо, ты - что плохо..."

(460) программист должен придерживаться стандартов разработки, но вам видимо это не понять

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

Хотя о чем я. Это хороший такой задел на "Незаменимого Васю" )

(464) О да, незаменимых васей ждёт отдельный котёл в аду.

(458) Еще как бывает! Вы намеренно берете антонимы. Реализация, Поступление. А если так: Реализация, ВозвратРеализации? Или так РеализацияСтарая, РеализацияНовая? Или так: РеализацияОпт, РеализацияРозн?

(463) А ее уже вставили в 100500 мест

Вдруг кто еще не читал: https://infostart.ru/1c/articles/966234/
Для пятницы самое оно.

(466) Ну так у вас должны быть разные переменные, прочитав которую было бы понятно о каком объекте идет речь.

Ректальное программирование - это, прежде всего, программирование свободного человека, если хотите - венца творения. Это программирование, свободное от всяких предрассудков, навязанных рамок следования стандартам, параноидальной боязни демонстрировать свой код другим участникам проекта. Ректальное программирование - это путь состоявшегося программиста, уверенного в своём абсолютном превосходстве и компетенции, не нуждающегося в поучениях и не поддающегося стадному инстинкту постоянно обучаться.

(468) веселая статья)

(471) Главное - полезная!

Нравится вам такой код? Если уж лениться на шифт, то можно лениться и на энтер с табом:

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

(467) Ну если вы пишите не код, а говнокод - то да, всё бесполезно и надо жить переменными, которые вообще не соответствуют своему названию.

(450) Если  у тебя в "Переменной"  ДокРеализация. КОД КОД КОД.
Оказался не "ДокРеализация." найденный.. а что-то другое..
То опять же возникает вопрос, по грамотности написания кода. Такого быть не должно.

Нормально написанный код.
Не может быть, что у тебя сначала ДокРеализация. переменная..
А в середине кода, ЭТА ЖЕ Переменна ДокРеализация. Получила документ ПОступления товаров и услуг.
Это не нормально как минимум.

А если к этому добавить... что сначала у тебя была переменная "с." "о." с чем-то.. А в середине кода.. эти же переменные с и о у тебя с другим чем-то..
То это еще более не нормально).

Зачем так делать изначально? Из за экономии времени на набор лишних букв? или из за желания сделать хуже программисту который будет читать и редактировать этот код в будующем?

Если ты пишешь программу себе дома для себя.. можно делать хоть a b c d а в середине кода А Б С  Д..
Но когда ты делаешь это для организации за деньги при этом считаешь себя адекватным программистом, то зачем?)
Вот сейчас ты в единственном лице. А через месяц возьмут второго программиста, вы будете сидеть с ним рядом. Он откроет обработку.. А там черт ногу сломит.
Посмотрит на тебя, ты посмотришь на него.. ))) он поржет и заплачет ))

Ребята! Вы мне напоминаете героя анекдота, который устроился работать пожарным. И все его устраивало. И зарплата, и коллеги, и начальство, и офис. Но вот только... как пожар, так прям хоть увольняйся. Я искренне не понимаю - если тебе так тяжело программировать, то зачем заниматься этим?
История вопроса проста и банальна. Когда человек учится программировать, он сперва осваивает сериализацию, т.е. превращение мысли в текст. Через некоторое время, когда он уже успел наполниться гордостью за себя, человек сталкивается с необходимостью проделывать обратную операцию, структуризацию, т.е. превращение текста в мысль. Эта операция действительно существенно более сложная, чем сериализация и многие тут по началу обламываются. И по свойственной человеческой натуре склонности тут же начинают искать виновного. Дескать, это не я пока еще слаб в программировании, это другой человек плохо написал программу. А я-то молодец, гораздо лучше, чем тот козел!
Лет через 20 это точно проходит.
Впрочем, на самом деле, спор ни о чем. В ближайшем будущем мы будем избавлены от необходимости выполнять сериализацию и структуризацию. Будем записывать мысль не виде текста, а виде мысли. И спор об именах переменных уйдет в историю

Ля, он ещё и идеологическую базу под копрокод подводит.
Клиника.

(478) Ты молодец. Лучше всех окружающих. И весь в белом.
А нет. В белом - врачи вокруг тебя...

(478) но таки при этом большинство пишет г. код. да и мой древний код такое же г.

(478) > Лет через 20 это точно проходит.
К счастью, эволюция нормальных программистов обычно идет в другом направлении.
Поначалу видишь код - мама родная! Какой козел это написал? И все с тобой соглашаются. Глядишь - а это ты же когда-то и написал.
А лет через 20 видишь код - красота-то какая! И все с тобой соглашаются. Глядишь - а это ты же когда-то и написал.

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

(483) наверное хорошо, когда столько времени освобождается от набивки переменных, да и голова не устаёт.

с хорошо отформатированным кодом как минимум приятно работать.

(482) Ну значит я ошибся. Не через 20, а через 30. Просто не засекал точно. Через 30 лет глядишь на тот и другой код. Код, как код. И тот и другой делают одно и то же. Все говорят, что один хороший, а другой плохой, а ты искренне не понимаешь - в чем разница )))

просто в 1с код ревью не приняты поэтому такие как ТС и могут писать такой свой код

(483) Шутки-шутками, но когда нет необходимости отрывать взгляд от монитора то и мысль меньше рвется и ошибок меньше допускаешь.

(486) у тебя повреждено чувство прекрасного. а может и вообще никогда не было

(486) Эффективность понимания кода зависит от его оформления. Для всех. Но не для тебя. Допустим, ты сверхчеловек и для тебя - не зависит. Проблема в том что для работы в команде нельзя тебя ксерокопировать. Тебе придется работать с обычными недалекими людьми, для которых эффективность понимания кода от его оформления зависит. Отсюда вывод какой? Для команды такие сверхлюди отказывающиеся играть по правилам - противопоказаны.

(489) "рез" звучит прекрасно, как полет стрижа или взмах самурайского меча. А как звучит РезультатЗапроса?

(491) А почему целых три буквы? Достаточно "р" - и именно незаглавной - чтобы сэкономить на шифте.

(492) Видимо он не потянул чистоту своего пути. И каким-то людоедским словарем пользоваться все же вынужден.

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

(490) Вот тут кроется самое главное. С чего вы взяли, что зависит? У человека проблема со структуризацией. Он, как и многие другие, хочет в мыслях переложить свою проблему на другого, чтобы не чувствовать себя ущербным. Все находится в области психологического и субъективного. А где объективный критерий?

(493) Ну я пишу же букву "й" )))

(493) Надеюсь, что текст "РезультатЗапроса" был скопирован из типовой, чтобы не утруждать себя набором такого количества символов.

(494) Это случайно не вредная венгерская нотация, которую надо похоронить в 80-х, когда ей самое место.

(495) ты отрицаешь что по разному написанный код требует разного уровня структуризации?

(497) почему вредная? у гугла код стайл такой например

с большой буквы объекты пишутся

(499) потому что читать код, где переменные и объекты содержат в себе префиксы - удовольствие, чуть лучше кода с рез = 0. Венгерская нотация была хороша, когда редакторы не умели в контекстные подсказки, а сейчас даже 1С-ная EDT понимает тип входящей переменной.

+(501) Особое счастье видеть префиксы от нескольких команд разработки - и дерево конфигурации (+ текст модуля) превращается в угадай мелодию.

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

(495) Объективный критерий очень прост. Скорость "структуризации", как ты ее называешь. Секундомера достаточно.

(499) пруфы будут?

(504) Вы проводили измерения? Рандомное тестирование на 1000 разработчиков?

(494) в разных по-разному
например C# использует большие буквы вначале методов, а Java нет

(506) Нет, конечно. Для меня в этом нет смысла. Но это стоит сделать вам, раз вы в меньшинстве. Утрете всем нос.

(508) А мне это неинтересно по причинам, которые я описал в (478)

(509) Вы себе же противоречите. Раз вы признаете, что мнение "молодых и неопытных" разрабов до 30 лет опыта противоречит вашему, то чтобы результаты опыта оказались в вашу пользу - все эти люди должны заблуждаться. То есть думать что "плохой код" снижает их эффективность, а на самом деле он ее снижать не будет. То есть вы всех к психиатру отправляете. Я правильно понял?

(510) Нет. Мне это неинтересно, потому что мы скоро откажемся от текста в программировании. И, соответственно, сам предмет исследований станет неактуальным

<brainguard знал, что в будущем программировать будут без текста и поэтому, опережая свое время, начал программировать без текста когда это еще не было модным. Ну, насколько мог>

Теперь можно и статью про регистры сведений. Помнится, кто-то в этой ветке просил

(513) вперед, главное по больше реальных примеров и интересных архитектурных решений с пояснениями.

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

Кстати, кто помнит, в 8.0 ведь уже были регистры сведений?

(512) Он начал программировать без мозга...
(516) Нет, их ввели только в 8.3.15

(517) А не в 8.3.18? )))

(518) Нет.

(519) Да ладно!

(515) Так это он над всеми издевается, на самом то деле :)

(521) В чем это выражается, по-вашему?

(522) Инспектор ГАИ любит Баха и Гейне,
Инспектор ГАИ - Рамайаны знаток,
Инспектор ГАИ - частый гость в Эрмитаже,
Инспектор ГАИ врубается в рок.

Инспектор ГАИ - он зависает на Фройде,
Инспектор ГАИ лихо пляшет брейк дэнс,
Инспектор ГАИ - ученик Сен-Мен Муна,
Инспектор ГАИ - гуру и экстрасенс.

А то, что он машет дубинкой -
Таков его имидж.
А то, что он дует в свисток -
Это тонкий пристеб.

(523) Не очень понятно. Вы не могли бы своими словами выразить суть претензий?

(516) В 8.0 были уже все прикладные объекты, которые в таблички складываются. С тех пор ничего принципиально нового в этой части не появилось.

(525) Да, я уже посмотрел на users.v8 Но все равно спасибо!

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

Кстати, кто их изобрел? Регистры сведений? Какой сумрачный гений?

А он точно в УЦ работает?

Итоги по регистрм ввели не так давно. Сами регистры были всегда

(530) Разумеется я не про итоги, а про сам регистр. Меня интересует - кто это был. 1С-овцы или ТБ-совцы

Кто такие тбсовцы?

(528) У меня встречный вопрос. Есть примеры систем (не 1С), где есть аналог среза последних, и даже срез последних "по части измерений", который работает по твоей логике?

Ну, чтобы понимать, что это не просто у тебя взбрык такой (перепутал РС с РН), а люди действительно так делают.
И кстати, пример реальной задачи все жду.
Если будет и то, и другое принесу искренние извинения.

(531) Разве у ТБ-совцев в их системе были были регистры сведений?

(533) С реальной задачи все и началось. Попросили отчет о последних закупочных ценах. По товарам, но без поставщиков. Я взял регистр ЦеныНоменклатурыПоставщиков обратился к виртуальной таблице СрезПоследних и был в полной уверенности, что получу последние записи. Но не тут-то было. Я решил задачу запросом к основной таблице, но призадумался. Может я чего-то не знаю. И есть способ получать последние записи из среза последних-то. Поэтому и запостил сюда

(534) Не знаю, поэтому и спрашиваю

(533) А пример системы я уже сам сделал

завтра будет ровно 2 недели обсуждению этого вопроса. давайте как-то отметим чтоли

(535) Конечно есть, и тебе сразу на него указали. Сворачивать ненужные измерения после получения среза.

(539) Это не даст последние записи

(538) Как видите, тема вечноживая. Всегда найдется кто-нибудь, кто не въехал

(540) Конечно даст. Приведи пример, когда не даст.

(542) ну пример и я приведу.
Измерения: поставщик, номенклатура. Ресурс: Цена. Периодичность - по регистратору.

Записи в регистре:
01.07.2021  |  ООО Ромашка         |  Стол     | 1000 руб.
01.07.2021  |  ООО Ромашка         |  Табурет  | 300 руб.
05.07.2021  |  Основной поставщик  |  Стол     | 1200 руб.
05.07.2021  |  Основной поставщик  |  Табурет  | 200 руб.

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

(543) НЕнормальный срез последних. Я настаиваю. Нормальный должен возвращать последние записи, раз уж его так назвали. И это - не придирка к словам. Я потерял какое-то количество своего рабочего времени. Теперь умножьте на количество разработчиков в среде 1С и поймете, почему важно все делать аккуратно

(544) А может, важно читать документацию, прежде чем что-то делать?

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

(546) Но РС синтетический объект, не специфицированный нигде, кроме как в документации от 1С, и ожидать от него некоего поведения, отличного от указанного в документации, на основании каких-то предположений по меньшей мере странно. При чём тут 2+2?

(547) При том что слово "последние" имеет совершенно прозрачный смысл. Уровень прозрачности не меньше, чем у 2+2

(548) Тяжёлый случай. Ладно, Миша, оставайся в своём мире, где значения слов отделены от контекста их использования.

(548) Да, ладно. И сколько же будет "2" + 2? А 2 + "2"?

(550) Не надо кавычек. У вас есть в точности 2+2. Вы полезете в документацию за разъяснениями?

(551)Ничто, в принципе, не мешает вам написать свою систему, где все это будет реализовано, как хочется)

(552) Ничто не мешает. Полностью с вами согласен

(544) >  НЕнормальный срез последних. Я настаиваю.
Зря настаиваешь.
(548) > При том что слово "последние" имеет совершенно прозрачный смысл
Нет. При указании части измерений - нифига не прозрачный.
РС предназначен для хранения сведений по комбинациям измерений. Типовое его применение - когда сведения имеют смысл для полных комбинаций.
И поэтому вариант, когда я указываю не все измерения чтобы получить "последние" по всем полным комбинациям (как сейчас и работает) - абсолютно нормален.
Твой вариант, когда работа с подмножеством комбинаций измерений может иметь смысл самостоятельного РС - это скорее исключение. Я могу привести стотыщ примеров, когда это будет не так и твои "интуитивные последние" не будут иметь никакого смысла вообще. А получение последних по полным комбинациям - всегда имеет однозначный смысл.
То, что ты хочешь - теоретически можно было бы реализовать отдельной опцией. Но в качестве дефолтного поведения (на котором ты наставиваешь) - это нифига не логично, поскольку покрывает гораздо меньшее количество кейсов.

(554) Так, как работает сейчас, не покрывает никакой кейс. Оно просто никуда не годится. Результат, который выдает срез последних по неполному набору измерений, полностью лишен смысла. Разработчикам было лень дорабатывать и они не нашли ничего лучшего, как просто написать в документации: "а вы так не делайте". Ха-ха. Если так нельзя делать, вызывайте исключительную ситуацию. Так, как сделано сейчас, приводит к потерям рабочего времени

(555) Если делать так, как не предусмотрено документацией - то действие лишено смысла.
Посмотри на радужных, которые не читали инструкцию.

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

(557) Если бы он был на месте разработчиков платформы - мы бы все повесились...

(558) Эта платформа умерла бы, ещё не родившись. Так что никто не повесился бы)

(543) >В данном примере, функция минимум не вернет последнее значение по Столу, а функция Максимум не вернет последнее значение по табурету.

Это ты применяешь ее к полю Цена что ли? С какого бодуна? Ее нужно применять к дате, а потом брать цену на эту дату.

(555) >Результат, который выдает срез последних по неполному набору измерений, полностью лишен смысла.

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

(561) Приведите хотя бы два примера

(562) (560) Прошу прощения, прочитал как "по полному набору измерений". Для неполного не встречал кейса нигде.

(560) хорошо. Тогда если применять агрегатную функцию к периоду, тогда такой пример:

Записи в регистре:
01.07.2021  |  ООО Ромашка         |  Стол     | 1000 руб.
01.07.2021  |  ООО Ромашка         |  Табурет  | 300 руб.
01.07.2021  |  Основной поставщик  |  Стол     | 1200 руб.
01.07.2021  |  Основной поставщик  |  Табурет  | 200 руб.

Т.е. дата одна и та же. в рамках одной даты купили мебель у двух разных поставщиков. Если брать максимум даты, то она будет одна и та же, и в итоге в результирующий набор попадут 4 записи.

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

(557) Есть довольно простая операция получения последних значений. Группировка с получением максимума по дате, а затем соединение с основной таблицей. Ее можно применять вообще к любому набору данных, лишь бы дата была. Разработчики применяют именно ее. Но почему-то только к полному набору измерений. Что им мешает применить ту же самую операцию к неполному набору измерений? То, что виртуальная таблица будет строиться динамически, исходя из набора полей выбранных в запросе? Но в РН они ровно это и делают. То, что в результате могут получиться неуникальные записи? Так они и сейчас получаются.
Чтобы я сделал на месте разработчиков, читайте в будущей статье

(557) И еще раз. Реализация того, о чем я говорю, проста


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

(566) да никто не спорит что просто. просто никому не надо.

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

(567) Это - неправда

(568) Да ладно. Перепиши эти 9 строчек, как тебе нравится и используй

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

опять же колонка ресурса одна, а если их несколько?

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

потому что могут быть неопределенности. они реши их не разруливать

(574) Они решили оставить все как есть. С теми же неопределенностями

(573) Вы других разработчиков тоже не жалеете качеством своего кода, так что у 1С было право жалеть время на Вас.

(564) дальше уже вопрос к brainguard, какая из этих записей ему нужна, и соответственно сворачивать дальше.

(565) >Что им мешает применить ту же самую операцию к неполному набору измерений?

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

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

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

(578) и раньше - автор ветки тролль или просто непробиваемый Д’Артаньян.
Зачем вы продолжаете его кормить?

(566) Чуть посложнее. Это же может быть подзапросом в сложном запросе. Но да - не сложнее чем неявная свертка, которая уже реализована.

(569) Почти правда. Твой случай достаточно редкий.

(576) Нет. Меня много, а 1С мало. Мои потери времени не идут ни в какое сравнение с затратами 1С. Тем более что конкретно это дело - плевое

(578) А сейчас дубли разве не появляются?
Что там описывать и формализовывать? Я за 10 минут сделал функцию, которая выдает срез последних по любому набору данных.
Не надо никаких дополнительных параметров виртуальной таблицы. Просто сделать так, чтобы записи, которые называются "последние" были действительно последними

Я думал уже все обсудили в этой теме)) а споры все идут.

(584) Потому что это важная и очень показательная тема

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

(583) Дубли появляются всегда, когда сворачиваются измерения. И в твоем коде (566) потенциально тоже. Если от них не избавиться, результат не может называться "срезом последних" ни в каком смысле.

(587) Почему же не может? Очень даже может. Записи-то последние, и это главное. А есть там дубли или нет - это уже другой вопрос

(588) Но какая самая последняя, вот главный вопрос.

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

(589) Достаточно того, что они все последние. На этом задача решена. Срез либо подставляется под светлые очи пользователя, либо обрабатывается дальше программно тем или иным способом. В чем проблема? Получить одно значение из множества? Вы не знаете - как это делается?

(590) Возьмём регистр Поставщик Товар Цена. Зачем может понадобиться срез последних по Поставщику без Номенклатуры? Ваши предположения?

(591) Зато может потребоваться срез последних по номенклатуре без поставщиков. А, например, в документах может потребоваться срез последних документов по контрагенту, может потребоваться срез последних документов по складу или срез последних документов по номенклатуре

Это все реальные потребности