Есть куча сформированных документов, у которых дата (вплоть до секунды) одинакова. Формирую запрос по регистру и хочу получить последний сформированный документ. Так вот вопрос в запросе МАКСИМУМ(ИмяРегистра.Регистратор) всегда будет возвращать последний документ? Как вообще работает МАКСИМУМ(Ссылка) ?

Нет

(0) Сначала получаешь максимум по секунде, потом по ссылке, то есть работает максимум по секунда + ссылка

Запрос к документам — плохая примета.

(2) Понятно ...
(3) Кто говорил про запрос к документам ?

(2) Момент времени тоже самое не даст?

(4) ИмяРегистра.Регистратор - это документ

(2) Причем, если я правильно понял, это должен быть подзапрос в подзапросе ... потому как в одном подзапросе МАКСИМУМ сразу по двум полям дает какую то ахинею.

(5) Нельза сделать МАКСИМУМ по моменту времени

(6) Это ссылка на документ

(7) Лучше временная таблица, а потом по ней уже вторая, в одном будет ахинея, да

(2) интересно, тип ссылки играет при МАКСИМУМ(Ссылка) ?

(8) это не совсем так

(12) обоснуй

(0) уид не грантирует хронологическую последовательность. Правильно получать остатки на конец этой секунды вид границы включая

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

если нужен последний введенный документ - максимизируйте по Дате и запрещайте юзерам менять ее вручную.

(14) Дело в том, что мне нужны не остатки, а приход (т.е. последнее движение в дате)

(15) платформа же гарантирует порядок

(16) Не вариант (запрещать) имеем то, что имеем

(11) Технически - да. Логически... Что больше: больничный или приходная накладная?

(14) Бред

в ссылке binary16 вроде бы, будет что-нибудь такое

SELECT
MAX(Q_000_T_001.ID),
"Тест для Мисты"
FROM
Document769 Q_000_T_001

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

(15) Когда кажется, крестятся
В рамках секунды документы сортируются именно по гуиду, более того, секунду можно поменять и порядок документов поменяется, а в рамках секунды — нет, если идет сначала гуид 1, а потом гуид 2, то так и только так навсегда

(16) Не советуй, если не в теме

(20) То, у чего больше гуид

(22) Гарантирует
Последний — это у кого в максимальной секунде максимальный гуид, а не тот, который позже всех ввели

(13) по моменту времени возможно упорядочивание, а значит возможно и вычисление максимума:

ВЫБРАТЬ ПЕРВЫЕ 1
    Док.МоментВремени КАК максимум
ИЗ
    Документ.Документ1 КАК Док
УПОРЯДОЧИТЬ ПО
    максимум УБЫВ

(27) Ну, сделай запрос с МАКСИМУМОМ

максимум по ссылке конечно будет последним ибо там индекс по ссылке.
последний, но не последний введенный

(29) Еще один спецыалыст
Или ты хотел сказать, что конечно же в рамках одной секунды?

(8) Моя жизнь поделилась на до и после.

(15) Солидарен
(30) Ты против утверждения что максимум(ссылка) <> последний документ, упорядочивание по ссылке не даст ожидаемого результата

(32) Солидарен с неверным предположением? Бывает

Можно упорядочивать по МоментВремени DESC.
И - ВЫБРАТЬ ПЕРВЫЕ 1.

Или у меня склероз уже?

(33) Что там не верного? Как определены операции больше меньше для ссылок (GUID), есть какие то есть правила?

(32) Он абсолютно прав - я могу создать два документа в одной секунде, а потом у последнего (созданного) поменять дату (02.01.2021 10:00:00) на меньшую (01.01.2021 9:00:00), в итоге МАКСИМУМ(Период + Ссылка) на дату (02.01.2021 10:00:00) выдаст первый созданный документ, а МАКСИМУМ(Ссылка) - второй

(32) Рукалицо
Еще раз
1. Максимум(Ссылка) в рамках секунды даст последний введенный документ, при условии, что гуид назначался автоматом
2. Принудительно сгенерить документу гуид, который в рамках секунды идет раньше другого документа тоже можно
3. Сравнивать гуиды без секунды бесполезно, потому что если я ввел документ, он теперь последний, а потом я поменял у него дату на год назад, то он что, блеать, теперь все-равно самый последний что ли?

(34) Ну если бы мне нужно было это делать только по одной (например) номенклатуре, то да, а вот если мне нужно найти все последние движения по списку, то ...

(34) Упорядочивать можно
Не помню, правда, момент времени — это секунда + дата или просто ссылка
Надо бы проверить

(39) Момент времени это Период + Ссылка (только посмотрел)

(35) Неверно то, что гуиды идут как насрали
Они идут по порядку
Про сравнение не подскажу, заитээсь

(41) Почему я читаю в посте два противоположных утверждения "Неверно то, что гуиды идут как насрали" "Они идут по порядку"

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

(42) Для тебя противоположно?
Неверно то, что 2 + 2 может быть = чему угодно
Верно то, что 2 + 2 = 4 и только 4

(43) Да кабы один ... Есть регистр продаж - нужно найти (причем хитро) последние приходы по списку проданных товаров. Если было бы все просто - я бы вопросы не задавал ... :)

(45) Рукалицо
Учись задавать вопросы
Тогда (2)

(46) Не начинай ... я так и делаю :)

(0) Почему нельзя получить максимум по номеру?

(25) Не умничай.
Запрос типа

ВЫБРАТЬ
    МАКСИМУМ(Ссылка)
ИЗ (    
    ВЫБРАТЬ ПЕРВЫЕ 1
        Ссылка
    ИЗ
        Справочник.Валюты
    ОБЪЕДИНИТЬ ВСЕ    
    ВЫБРАТЬ ПЕРВЫЕ 1
        Ссылка
    ИЗ
        Справочник.Сотрудники
) Подзапрос

Превращается в

SELECT
    SUBSTRING(MAX(T1.Q_001_F_000TRef + T1.Q_001_F_000RRef),1,4),
    SUBSTRING(MAX(T1.Q_001_F_000TRef + T1.Q_001_F_000RRef),5,16)
FROM
(
    SELECT TOP 1
        0x000004F0 AS Q_001_F_000TRef,
        T2._IDRRef AS Q_001_F_000RRef
    FROM
        dbo._Reference1264 T2
    UNION ALL
    SELECT TOP 1
        0x00000001 AS IDTRef,
        T3._IDRRef AS IDRRef
    FROM
        dbo._Reference1 T3
) T1

Ты все утверждаешь, что больше тот, у кого гуид больше?

(47)
ВЫБРАТЬ
    Продажи.Номенклатура КАК Номенклатура,
    МАКСИМУМ(Продажи.Период) КАК Период
ПОМЕСТИТЬ ВТМаксимумПоСекунде
ИЗ
    РегистрНакопления.Продажи КАК Продажи

СГРУППИРОВАТЬ ПО
    Продажи.Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    Продажи.Номенклатура КАК Номенклатура,
    МАКСИМУМ(Продажи.Регистратор) КАК Регистратор
ИЗ
    РегистрНакопления.Продажи КАК Продажи
        ЛЕВОЕ СОЕДИНЕНИЕ ВТМаксимумПоСекунде КАК ВТМаксимумПоСекунде
        ПО Продажи.Номенклатура = ВТМаксимумПоСекунде.Номенклатура
            И Продажи.Период = ВТМаксимумПоСекунде.Период

СГРУППИРОВАТЬ ПО
    Продажи.Номенклатура


(48) Вон из профессии

(51) Опередил ... :)

(49) Причем здесь справочники, если мы про документы и сравнение в рамках секунды?

(53) Не ерзай. Ты прямо ответил на вопрос "Что больше: больничный или приходная накладная?" фразой "То, у чего больше гуид". Сейчас ты пытаешся приплести сюда уже секунды.

Вот тебе документы:
ВЫБРАТЬ
    МАКСИМУМ(Ссылка)
ИЗ (    
    ВЫБРАТЬ ПЕРВЫЕ 1
        Ссылка
    ИЗ
        Документ.ВыплатаЗарплаты
    ОБЪЕДИНИТЬ ВСЕ    
    ВЫБРАТЬ ПЕРВЫЕ 1
        Ссылка
    ИЗ
        Документ.Больничный
) Подзапрос

SELECT
SUBSTRING(MAX(T1.Q_001_F_000TRef + T1.Q_001_F_000RRef),1,4),
SUBSTRING(MAX(T1.Q_001_F_000TRef + T1.Q_001_F_000RRef),5,16)
FROM (SELECT TOP 1
0x000012F2 AS Q_001_F_000TRef,
T2._IDRRef AS Q_001_F_000RRef
FROM dbo._Document4850 T2
UNION ALL SELECT TOP 1
0x000007B5 AS IDTRef,
T3._IDRRef AS IDRRef
FROM dbo._Document1973 T3) T1

Приходной накладной, извини, не было.

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

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

(56) ну по виду они не кучкуются)

(54) Да капец
Для таких как ты, даже на упаковке пластилина пишут "Не есть"
Еще раз, ВСЕ сравнения ЛЮБЫХ ссылок на ДОКУМЕНТЫ корректно проводить только в рамках одной и той же секунды
Просто потому, что если ты поменяешь дату документа на год раньше, то он как бы явно станет меньше того, который идет годом позже, а ссылка у него при этом не поменяется, то есть (23)
Сравнение же ссылок на что-то другое, на справочники, например — это вообще что-то непонятное, какой смысл их сравнивать?
Но вообще, по логике, раз нет даты, то, наверное, последняя введенная ссылка будет максимальной, да

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

Для корректного упорядочивания по ссылке есть оператор запроса АВТОУПОРЯДОЧИВАНИЕ. Однако, если мне память не изменяет, его использование отключает получение N первых.

Оператор запроса

МАКСИМУМ(Ссылка)

лишён смысла. Это точно неверно.

(55) Читай (58) для чего

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

(53) подтяни базу. Момент времени - это дата + ссылка. Благодаря этому решаетсмя вопрос однозначного упорядочивания джокументов на оси времени. Но о фактическом моменте содания документа там ничего нет. Более того есть метод УстановитьСсылкуНового которым можно задать ссылку документа

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

(57) Скорее всего не кучкуются, да
Наводит на эту мысль две вещи
Сравнивается же по гуиду, а не по типу документа + гуид
И в СКД если расшифровать тот же регистр накопления по регистраторам, что-то я не заметил, что в рамках секунды идут сначала все приходные накладные, а потом расходные или наоборот

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

для Регистра накопления:

УПОРЯДОЧИТЬ ПО МоментВремени

ORDER BY (T1._Period), (T1._RecorderTRef), (T1._RecorderRRef)

т.е. по периоду, по типу, по уиду (binary)

(59) Его смысл — получить последний документ в рамках секунды

(61) Так а как же по твоему тогда быть с журналами документов? А с регистраторами регистров?

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

(65) То есть сначала все ПН, потом все РН, потом все перемещения и т. д.?

+(69) Вот насчет этого не уверен, в рамках одной секунды может так и есть, надо проверить

(66) Для сортировки в рамках секунды предназначен оператор МоментВремени. Нет разве?

(71) Так а как макисмум-то брать?
ТС нужен максимум

(72) Максимум(МоментВремени) не работает разве?

(73) Ты умеешь читать?

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

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

(0) а в чем смысл агрегатных функций для бинарного типа ?

(77) Так тут же Всегда ли в запросе МАКСИМУМ(Ссылка) вернет последний документ? уже вроде ответили, в чем

" Однако следует учитывать, что значение ссылки генерируется системой без какой-либо гарантии получения неубывающей последовательности. То есть взаимное расположение в хронологической последовательности двух документов имеющих одинаковую дату (включая время) не зависит от порядка создания документов или от чего-то другого. Соответственно не существует возможности изменить порядок расположения двух документов в пределах одной секунды. Таким образом, порядок двух документов с одинаковой датой можно считать неопределенным, но система обеспечивает неизменность этого порядка после записи документов. "
https://its.1c.ru/db/metod8dev/content/2737/hdoc

(79) Ну, в целом сказано все то, что и сказано в этой ветке, кроме генерации ссылки
Добавлено про номер строки для регистров, это правда
Про генерацию ссылки сказано, что в принципе ссылка может быть сгенерена какой угодно, даже меньшей, чем уже существующая в этой секунде
Но при этом, если не вмешиваться в формирование ссылок, то вроде как следующая ссылка всегда больше предыдущей
И это не отменяет того, что потом-таки упорядочивается по ссылке

(80) "Но при этом, если не вмешиваться в формирование ссылок, то вроде как следующая ссылка всегда больше предыдущей" — это я про собственный опыт, если че

(80) А если "ссылки" генерируются в нескольких внешних системах параллельно?

(82) Тогда это ручная генерация ссылок, со всеми вытекающими

(83) В каком это месте она "ручная"? Например, в ЦБ загружаются ОРП с 1000 магазинов, это у тебя "ручная генерация", что-ли?

(84) Да
Не ручная — это когда все ссылки генерит сама база, в которой эти ссылки содержатся
А в данном случае ссылки генерятся в других базах и назначаются уже сгенеренные

зато в Фузине этот вопрос точно решен

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

(87) всё движется по спирали, 10 лет все работали в толстом клиента, и нам пели: не нагружайте клиента, переносите операции на сервер. Все перестроились, перешли. Теперь начинаете петь в другую сторону?

У меня РИБ-база, поэтому любой GUID любого объекта - уникальная абстрактная бесполезная информация :( кроме условно-полезной даты создания ссылки :)

Насколько я помню в 1С UUID версии 1
https://ru.wikipedia.org/wiki/UUID#Версия_1_(время_и_MAC-адрес)

Но так как 1С получает гуиды пачками там отличаются по миллисекундам в пачке для каждого типа конфигурации
Из гуида можно получить и время.
http://catalog.mista.ru/1c/articles/635159/

Но все это прекрасно, если птом не изменить время документа вручную, или GUID внешний
Можно конечно использовать GUID версии 6 https://uuid.ramsey.dev/en/latest/nonstandard/version6.html
https://github.com/bradleypeabody/gouuidv6/blob/90681a9a92948d6a1ce447622e8591e86386fe7d/gouuidv6.go#L111
Он по сути близок к автоинкременту.

Проще отбирать по Выбрать первые и отсортированные по нужным полям
v8: Подзапросы с Выбрать Первые

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

(90) видимо, я все же был прав в (15). Интуиция меня не подвела.

(93) Мда, некоторым даже (79) по хрену мороз, я самый умный и все тут

(94)как по мне 79 только подтверждает и (15) и (29).

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

Я же говорил, что запросы к документам — плохая примета.

(96) Момент времени и есть дата + ссылка, что в явном виде и написано на ИТС по ссылке в (79)
А максимум по ссылке используется только потому, что максимум по моменту времени брать запрещено

— А давайте лупанем по тупым америкосам!
— Мы и есть тупые америкосы, сэр!

Понаберут дебилов по объявлению
Фейспалм

(95) Не процитируешь текст, который подтверждает (15)?

Про (29) не говорю, там Вафель на своей волне, говорит что-то лишенное смысла, максимум по ссылке у него конечно же будет последним, но не последним введенным
Хм, все понятно, что ничего непонятно
Видимо, он пытался сказать, что если взять две произвольные ссылки, то нельзя сказать, что та, которая меньше, ту и введи хронологически раньше
Ну так это никто и не утверждал
Дяденька сам пошутил, сам посмеялся

(98) "и эти люди учат нас как ковыряться в носу!", пардон учат нас как внедрять ЕРП.
http://catalog.mista.ru/1c/articles/84177/#:~:text=Момент%20времени%3A,ссылку%20на%20объект%20базы%20данных.
почитай хотя бы тут. кратко, но достаточно, чтобы человек разумный перестал пороть чушь.

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

Кто-то пытается строить хорошую мину при плохой игре.

(91)+ Правильнее выбирать последнюю запись отсортированной по дате и номеру документа
Используя Выбрать Последние

(103) что тоже самое если отсортировать по ссылке с авто упорядочиванием

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

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

только вот 1с от последовательностей то сама отказалась .. дорогие они видимо ..

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

(104) Неа. Ссылка может быть и внешняя из другой системы, из гуида другой версии
https://ru.wikipedia.org/wiki/UUID
Кроме того можно изменить время и номер вручную.
Правильно это последний по дате и номеру

(100) Для дебилов перевожу то, что там написано
Момент времени — это дата + ссылка
Что тебе еще надо-то?

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

Если и это до тебя не дойдет, то я пас, фиг знает, как дереву объяснить, что 2 + 2 = 4

(101) А что, при dt меняются номера типов метаданных и/или гуиды?

(102) Не надо лишних слов, просто тыкни пальцем, где и что написано верно, а где и что нет

(103), (104), вы издеваетесь  что ли? Как вас на работу-то взяли?

(106) А, ну да, при проведении по регистрам именно последовательности и используются, ага
Рукалицо

+(113) То есть если я в номер вместо 0010123 напишу 0000001, то он сразу станет самым первым в этой секунде что ли?

(110) до вас пытаются донести, что для гуидов в общем случае не определена арифметика от слова "ваще". И не определено сравнение на больше-меньше, только на равенство. Он не расценивается как целое число, как двойка, например.

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

(116) Вот то ли дело момент времени, да?
Для него не только сравнение на больше/меньше определено, по нему даже максимум можно строить?
А, или нелья
Хм, странно, казалось бы, почему нельзя?

(117) Ok, допустим я забыл весь свой предыдущий опыт и знания
И как же нужно сортировать по времени документы?
Как мне, например, понять, какой документ раньше, а какой позже?

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

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

(110) мне в данной теме понятно все, кроме твоего воинствующего хамского тона, который совершенно недопустим со стороны идиота пишущего (37) "1. Максимум(Ссылка) в рамках секунды даст последний введенный документ, при условии, что гуид назначался автоматом" (с)

(120) Эээ... кхм... к тебе вопросов больше не имею

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

Да, действительно, МАКСИМУМ(МоментВремени) сделать нельзя, но можно по МоментВремени упорядочивать, и тем самым получать нужную информацию - последний сформированный документ

Мне все это уже слегка надоело
Тем, кто до сих пор уверен, что максимум по ссылке — это лютая дичь, предлагаю в конфигураторе типовой нажать Ctrl + Shift + F, ввести "максимум" и потом в найденном поискать "ссылка" или "регистратор", после нахождения долго думать

(125) И что, результат будет отличаться от упорядочивания по дата + ссылка?

(126) Я в типовых конфигурациях мат в сообщениях находил. Должен ли я руководствоваться результатом этого поиска при общении с клиентом?

Не в сообщениях, а в комментариях

(129) Ну вот ты-то куда полез? У тебя тоже максимум по дата + ссылка не равен максимальному моменту времени?

(109) При сортировке по ссылке с автоупорядочиванием, 1с автоматически изменяет это сортировку сортировку по дате и номеру для документов, и на основное представление для справочников

(130) Я не настолько туп, чтобы применять максимум() к гуиду, даже если он идёт в паре с датой.

(132) Ну-ка ну-ка, и что ответишь на (119)?

О чем спор вообще, МоментВремени = дата + ссылка...
PR делал, то утверждение исходя того что ссылки генерируются автоматом и нет вмешательства из вне(изменение даты, внешние ссылки)... НО ЭТО ЧАСТЫЙ СЛУЧАЙ В ВАКУУМЕ! Опираться на это в реальной практике = быть больным идиотом....

(133) _тебе_ я ничего отвечать не буду. Бесполезно.

(134) Верно
Мне все-равно, ссылки назначаются по порядку или как насрали
Важно, что потом порядок берется именно из дата + ссылка

(135) А, ну слился и молодец

(127) Роман, я согласен с коллегами, что применять упорядочивание к Дата + Ссылка методологически неверно, но это моё личное субъективное мнение, основанное "ни на чём". Если у меня будет задача определения точной хронологической последовательности, то я буду использовать, в том или ином виде, механизм, который именно для этого и предназначен - МоментВремени. Да, действительно, МоментВремени - это ДАТА плюс ССЫЛКА, но я не считаю себя умнее программистов, которые эту платформу делали, и буду пользоваться именно тем методом, которые они именно для этого и предлагают.

Ссылку, в конце концов, можно установить и вручную.

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

(131) При сортировке по ссылке с автоупорядочиванием, 1с автоматически изменяет это сортировку сортировку по дате и номеру для документов, и на основное представление для справочников
Не буду спорить про сортировку. Суть то в том что нужно брать не Максимум(Ссылка)

А
                 Выбрать Последние 1
                   Док.Ссылка,
                   ИЗ
                       Документ.РеализацияТоваровУслуг КАК Док
                   УПОРЯДОЧИТЬ ПО
                       ДатаДок, НомерДок

140+ При этом можно использовать Выбрать первые и в подзапросах
v8: Подзапросы с Выбрать Первые

(137) если порядок берется как ты говоришь из дата + ссылка, то тогда должно быть нормой, что сначала идет ДК002 от 01.01.2021 23:59:59 а за ним идет ДК001 от 01.01.2021 23:59:59, хотя логически это не так

(142) Держите наркомана

(139) Твой намёк на то, что я дурак (раз ты ощущаешь себя в дурдоме) говорит не о моих умственных способностях, а о твоём воспитании. Я просто предлагаю использовать тот механизм, который именно для таких случаев и предназначен. А то, что ты знаешь тонкости его работы лучше меня - ну, молодец.

(143) Поясни за слова, или так лишь бы написать?

(142) На такое я даже не знаю, что ответить
Гитлер капут

(145) Что ему пояснить?
Ты такую дичь написал, что просто вообще тушите свет
Так сказать, некоторые в ветке докопались до дна и тут ты пришел с отбойным молотком и дно уверенно пробил

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

(144) Да я просто не понимаю как можно говорить про момент времени и дата + ссылка как про что-то разное, если это _одно_ _и_ _то_ _же_ по заявлениям самих разработчиков?
Странно, что по моменту времени можно сортировать, но нельзя брать максимум, а так в остальном все же одно и то же
Максимум понятно почему нельзя брать, потому что поле составное, тем более дата + строка, но тем не менее, сортировать же по нему можно, могли бы и максимум прикрутить и не было бы этого позорища некоторых в ветке

(148) Какая глубокая мысль

(147) Дно тут пробил ты, любому уважающему it спецу известно что GUID это про уникальность, а не про порядок и операции больше меньше для него не применимы. Ты обосрался, и пытаешься тут отвертеться, дабы не запачкать свой "авторитет".

(150) Мне показалось, что это удачная аналогия для тех, кому сложно уловить суть.

(145) https://its.1c.ru/db/metod8dev/content/2737/hdoc
https://its.1c.ru/db/metod8dev#content:2610:hdoc
http://catalog.mista.ru/1c/articles/84177/

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

(149) То есть, себе ты даёшь право что-то не понимать, а другим такого права не даёшь?
(151) Согласен. ГУИД - это про уникальность, а не про сортировку и операции больше-меньше.

(151) Он разве предлагал где то брать только по ГУИД, кроме частного случая? Я вижу только про гуид + дата

(151) Ты бы после (142) лучше вообще помолчал :)))

(153) Из твоих ссылок что ты привел , ты не можешь представить ситуации что сортировка в дате и ссылке документа дасть результат :  ДК002 от 01.01.2021 23:59:59, ДК001 от 01.01.2021 23:59:59

(152) Да нет, это скорее пук в лужу
Неправильный тем более

(154) Ok, давай с начала
Момен времени = Дата + Ссылка?

(157) Достаточно присвоить оба номера вручную

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

И как выше уже говорилось - момент времени в рамках секунды использует именно порядок ссылок/гуидов. И благодаря вышесказанному, документы созданные позднее, в рамках секунды попадут в конец.

(161) Я это знаю про компоненту времени в гуид, но при этом это не является гарантированным поведением, и поэтому полагаться что это компонента будет работать всегда нельзя, и отсюда все правила обращения с GUID

Выдержка из ссылок в (153) если кому то лень читать.

На закуску процитирую слова Бориса Нуралиева:
"Механизм генерации ссылок обеспечивает только их уникальность. Возрастающая последовательность при их генерации не обеспечивается."
Всё сказано вполне чётко, не правда ли?

p.s. Думаю, не стОит напоминать что момент времени -- это время + ссылка, то есть если так будет проще, время + тип документа + уид

Сколько раз нужно это еще повторить в топике?)))

(164) "Возрастающая последовательность при их генерации не обеспечивается" и как это утверждение согласуется с (143) в адрес (142), кто наркоман?

Мне тут все давно понятно, тема интересна лишь в ключе почитать как будет господин "PR" съезжать со своих утверждений касательно темы ветки и наезда на (15).

(165) Да кто тебе предлагает то сортировать по одному ГУИДУ??? Тебе говорят о том, что правильно сортировать по ГУИД + ДАТА что и является МоментомВремени в 1с... ты докапался до частного случая про который писал PR... Если нет факторов влиящих из вне на ГУИД (Изменение даты, ГУИДЫ прилетевшие из других баз/сайтов и тд), то действительно записи будут ложится в базу по ПОРЯДКУ. (о чем кстати подробно написано со всеми тестами в 3 статье по моим ссылкам)...

(159) МоментВремени УСТАНАВЛИВАЕТСЯ с помощью Даты и Ссылки, но как обеспечивается хронологическая последовательность - знает только платформа.

(168) см (65)

(164) "Возрастающая последовательность при их генерации не обеспечивается."

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

Т.е. получается, что последовательность по моменту времени (дата+тип+уид) - это такая вещь в себе, часто совпадающая с интуитивной хронологической последовательностью, но не тождественная ей.

(167) (Изменение даты, ГУИДЫ прилетевшие из других баз/сайтов и тд), то действительно записи будут ложится в базу по ПОРЯДКУ
Нуралиев -  "Возрастающая последовательность при их генерации не обеспечивается."
Еще тут обвинениями в наркомании бросаешься...

(170) но получается в рамках базы. выгрузка/загрузка дт поломает сравнение типов. дт не архив!!11 )

(171) Видимо вы действительно наркоман, если не понимаете, что такое частные случаи и почему Нуралиев так ответил... Платформа действительно так себя ведет без вмешательства в жизнь гуидов... Но изменение даты документа уже равно вмешательству, что сразу приводит к нарушению последовательности... НО это не отменяет факта, то что при ОПРЕДЕЛЕННОМ ЧАСТНОМ СЛУЧАЕ... понимаете ЧАААСТНООМММ, это работает так.

(173) Из тебя бы вышел отличный сапер, но возможно одноразовый. Хорошо что ты 1Сник.

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

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

(168) Дата включает в себя миллисекунды. Это и есть момент времени.

(176) миллисекунды это про границы (включая, исключая)

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

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

(164) Даже если эти слова Нуралиева достоверны, то на практике легко убедиться в обратном. Когда есть слова и есть факты, я предпочитаю не обращать внимания на слова.

(166) Ты точно не наркоман?
В (15) говорится что сравнивать между собой ссылки глупая идея
Я всю ветку говорю, что нет, не глупая
Куда и почему я должен съезжать?

PS: для наркоманов в очередной раз уточняю, все сравнения ссылок имеются в виду в пределах одной секунды

(168) О, ну наконец-то, прокашлялся
Хранится ли момент времени в базе отдельно как отдельное поле или генерится на лету из дата + ссылка я не знаю, но мне пофиг, мне достаточно того, что сортировка по моменту времени _всегда_ будет совпадать с сортировкой по дате + ссылка

(169) А, ну, кстати, да, уже не только платформа, но и, как минимум, youalex

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

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

(172) А dt здесь причем? (111)

(176) Ты хочешь сказать, что момент времени — это не про ссылку?

+(187) А как же (65)?

(176) 1C не сохраняет миллисекунды в базе данных. Во всяком случае в сиквел нули пишет.

(177) Граница — это дата и ссылка опять же

(180) В чем в обратном?

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

(192) О как
А, ты имеешь в виду, что Боря сказал, что возрастающая последовательность не обеспечивается, а на самом деле обеспечивается?
Какой коварный тип!

(193) Как я понимаю, этим сразу два зайца убивается:
1) для базы данных хорошо, когда новые записи пишутся в конец кластерного индекса, а не как бог на душу положит
2) при сортировке по моменту времени в пределах секунды тоже получается логичнее, что позднее созданные документы идут после созданных ранее

(194) + Уникальность, хотя ее можно было и по-другому конечно достичь
+ Движения в регистры ложатся позже и не приходится пересчитывать каждый раз те же актуальные итоги

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

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

(195) Про итоги не понял. Актуальные в любом случае будут пересчитываться.

(176) А если допустить, что в базе создали 100 000 000 документов "Реализация товаров и услуг", и у всех у них дата "31.12.2020 12:00:00", как отработает момент времени, основанный на миллисекундах?

Мне кажется, там всё-таки не миллисекунды, а какой-то другой механизм. Да тот же инкремент, например.

(198) Момент времени - это дата + ссылка. Дата с точностью до секунды. Какую пользователь выставил, скажем. А ссылка, с точки зрения порядка - тупо время генерации ссылки (плюс еще части, дополнительно обеспечивающие уникальность ссылки как гуида). Время генерации ссылки - там 60 бит кажись. С точностью до микросекунд и даже долей микросекунд.

(193) эээ... все в курсе, что из ссылки можно достать её время создания? Оно не совсем и не всегда соответствует реальному, но для моих целей - и так сойдёт. Я запросом выбрал однотипные документы за прошлый год; отсортировал по GUID(SQL); вычислил и сравнил даты создания. На пару тысяч ссылок всего одно нарушение возрастания последовательности. Как бы Боря - прав... но я не исключаю вероятность проблемы с получением времени сервера в многопользовательском режиме.

(199) http://catalog.mista.ru/1c/articles/635159/ вот тут подробно написано, время это один и компонентов, но он не гарантирует возрастание порядка выданых гуид, поэтому опираться на утверджение "А ссылка, с точки зрения порядка - тупо время генерации ссылки " не верно

(200) Не совсем понял, с чем ты сравнивал. С ЖР?
(201) Поясни, почему время генерации не гарантирует порядок возрастания. Я, видимо, туплю. Уже несколько раз сказал, что 1С в базе данных часть со временем генерации впереди записывает. То есть сначала будет порядок времени генерации, а все остальное уже влияет на порядок в пределах микросекунды.

Вопрос о количестве документов в одной микросекунде подобен вопросу "Сколько ангелов поместится на кончике иглы?" ;)

(202) Сортировал GUIDы по возрастанию и проверял на возрастание время создания этих-же GUIDов

(202) В ссылке (201) отдельным пунктом рассматривается этот вопрос. Грубо говоря что это может работать в 99.9% , но уже не может быть однозначным правилом.

Порядок времени генерации гуид в каких-то отдельных случаях может и не совпадать с порядком времени записи в БД.
Можно же заранее получить ссылку нового, например. Но в базе данных все равно же будет порядок возрастания времени генерации гуидов.
Исключением будет только нестандартное получение ссылки. На основании "ручного" гуида, например.
(204) Я возражал на утверждение "Возрастающая последовательность при их генерации не обеспечивается". Обеспечивается. Но есть еще "ручная" генерация.

(205) Тут правильнее было написать "Возрастающая последовательность при их генерации не гарантируется"

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

(196) Последний документ — это тот, который поставили самым последним, то есть у него самая последняя дата и самая большая ссылка в секунде этой даты

(197) А, ну да, в любом случае будут же просто движения нового документа добавляться

(198) Инкремент, все верно
В ссылке

(203) Хм... Тогда непонятно, откуда расхождение вылезло. Возможно, ошибка извлечения времени для какого-то краевого случая.
(206) Гарантируется. Просто так как все неявно пытаются привязать время генерации гуидов к чему-то практическому (например ко времени записи в БД), во всех статьях проще бить всех по рукам и говорить "ничего не гарантируется". Потому что эти дебилы-одинэсники не хавают таких тонких разниц.

(205) Не "обеспечивается" же, это просто "сайд эффект". Его можно использовать, но при этом не удивляться, если что-то пойдёт не так...

Я соглашусь с такой формулировкой: "Возрастающая хронологическая последовательность записи объектов в БД при генерации их ссылок не гарантируется".

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

(212) Эээ... а как его и зачем использовать?

(215) Единственное практическое применение, которое я встречал - можно узнать примерное время создания объекта, если ЖР не сохранился.

(215) Если ты этого не знаешь - значит тебе этого и не нужно.

(217) Логично
Мне не нужно
Даже (216)

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

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

(220) Ок. Этого никто не гарантирует. Но в 1С это работает именно так с первой версии и по текущий момент. И я не вижу ни одной причины, почему это может измениться. Потому что причины, почему сделано именно так, вполне очевидны и весьма весомы. На практике от этого толку мало, поэтому с пеной у рта попросту нечего обсуждать. Но факт остается фактом. Хотелось расставить точки над "ё".

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

(222)  Это не "стало неактуально с появлением управляемых блокировок". Это для управляемых блокировок этот момент стал менее критичным. Две большие разницы.

(220) если говорить о ms sql то порядок там можно гарантировать на том основании что ссылка это ГУИД которых имеет тип binary, который sql не запрещает сортировать:
"Columns of type ntext, text, image, geography, geometry, and xml cannot be used in an ORDER BY clause."
https://docs.microsoft.com/en-us/sql/t-sql/queries/select-order-by-clause-transact-sql?view=sql-server-ver15

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

(225) Не только для этой. Задам вопрос так. Ты считаешь, что изменение алгоритма генерации гуида в очередной версии 1С на полностью рандомный ничего не ухудшит?

(226) ну я просто процитировал, если интересно, то могу ссылку дать
а так - надо замеры делать

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

(220) Уже сто раз все объяснили, сто раз давали ссылки на разъяснения от 1С, сто раз взывали к логике и здравому смыслу
Уже вроде даже никто не спорит с тем, что момент времени = дата + ссылка
Но нет, все-таки есть еще некоторые упоротые, которые по-прежнему считают, что никакого порядка из ссылки получить и получать нельзя, максимум можно использовать как странный необъяснимый лайфхак
А что же вместо этого использовать?
Ну конечно же сортировать по номеру документа, самый верный способ

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

(230) LOL
Это уже упертая дремучесть какая-то
Как ты думаешь, если двум первому документу назначить вручную "большой" гуид, а второму вручную "мальнький" и одну и ту же дату до секунды, то:
1. Сортировка по моменту времени совпадет с сортировкой по дате + ссылка?
2. Движения в СКД по какому-нить регистру остатков, куда эти два документа наделали движений, пойдут в какой последовательности, сначала движения первого, а потом второго или наоборот?

(231) И все-таки еще вопрос:
3. При правильной сортировке (понимай под этим что хочешь, порядок в списке документов, попадание в последовательность, сортировка по моменту времени или что-то еще) сначала пойдет первый документ, а потом второй или наоборот?

(231) я как бы понимаю что там где сортируется, поэтому не понял наезда про дремучесть
дремучесть в чем?

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

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

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

(235) ну да

(236) Ок, взаимно.

(237) А, ну так это вообще непонятно почему возникшая в этой теме дискуссия
Я про то, что новый документ по дефолту будет с бОльшим гуидом
Ветка-то изначально не про это и в принципе вообще неважно, больше будет новый гуид или меньше
Ветка про то, что и как использовать для сортировки и максимума и решения (0)
А полветки обсуждается именно то, как генерятся ссылки

Три страницы печенкиного самоутвержения какие-то

Опираться на сравнение больше/меньше на гуид так себе идея. Объект вообще может прийти из другой базы.

(240) Ну, на самом деле можно было закончить на (2), но прибежала орава народу, вчера открывших конфигуратор, и начала спорить про то, что не знает

Теперь вот еще (241) нихрена не прочитал, но тоже очень хочет что-нибудь сказать

сортировка по ссылке = сортировка по моменту создания документа (или что то же самое уид-у).
при этом дату и время документа можно менять. в результате чего сортировка по ссылке станет существенно отличаться от сортировки по дате(+времени) документов.
//упп демо укр:
ВЫБРАТЬ Док.Ссылка, Док.Номер, Док.Дата
ИЗ Документ.ЗаказПоставщику КАК Док
УПОРЯДОЧИТЬ ПО Ссылка
// результат:
// Ссылка    Номер    Дата
// Заказ поставщику НФ000000011 от 01.05.2011 0:00:00    НФ000000011    01.05.2011 0:00:00
// Заказ поставщику ДО000000008 от 06.06.2011 0:00:00    ДО000000008    06.06.2011 0:00:00
// Заказ поставщику НФ000000001 от 04.04.2011 12:00:00    НФ000000001    04.04.2011 12:00:00
// Заказ поставщику НФ000000002 от 05.04.2011 12:00:00    НФ000000002    05.04.2011 12:00:00

(239) "окумент по дефолту будет с бОльшим гуидом"

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

(242) На самом деле можно было. Но сравнение что мы открыли недавно конфигуратор и спорим не корректное, подойдет другое у нас есть хотя бы базовые знания в программировании поимо конфигуратора 1С. Ты настолько упертый, что для даже Сергей Нуралиев для тебя не авторитет.
Метод из 2 сработает, но никто не гарантирует что этот метод даст реально последний введенный в базу документ. Тут спор идет о тонком моменте который ты не понимаешь наверно ввиду своей гуманитарной натуры.
1С приняло правило, что для разграничения внутри секунды используется сортировка по ссылке, но так как сам ГУИД имеет природу генератора, а не инкремента, то гарантируется лишь сохранение бинарного порядка гуидов в последующем, сам порядок ничего не значит (кроме свойств бинарной сортировки), если кто то хочет рулить временным порядком 1с предлагает регулировать дату документа, больше никак.

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

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

"Да, очень жаль, что нам так и не удалось послушать начальника транспортного цеха!" (с)

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

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

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

СсылкаПредудыщая = Неопределено
пока истина цикл
    Запрос "Выбрать первые 10 Ссылка Из Документ1 УПОРЯЧИТЬ ПО Ссылка ГДЕ Ссылка > &СсылкаПредудыщая"
    ..
    СсылкаПредудыщая = Выборка.Ссылка;
КонецЦикла

(248) Порядок то неизменен. Только вот гарантировать, что порядок гуидов при этом будет совпадать с хронологическим порядком записи объектов, они не берутся. Это лишь предполагается исходя из алгоритма формирования гуидов в 1с, а он также не документирован и вполне может быть изменен.

(250) не берутся. но я этого и не писал

(245) Мне достаточно того, что ты на это закладывается 1С

(246) >>но никто не гарантирует что этот метод даст реально последний введенный в базу документ
Рукалицо
А кто это утверждает?

>>1С приняло правило, что для разграничения внутри секунды используется сортировка по ссылке
Всё!
Мы только про это и говорим
Нахрена сюда приплетать сортируемость гуида, дикость этой процедуры или что-то еще?
1С сортирует документы по дате + ссылка
А ТС, ну нифига себе, как раз спрашивает, как в 1С получить самый поздний документ для каждой номенклатуры, ну или для чего он там пытается их получить

Я уже не знаю, как объяснить такую простую вещь
Все время разговор скатывается либо на то, что ссылка на последний введенный документ может быть не максимальной
Либо на то, что сравнивать гуиды вообще странно, дико и как-то фу
Но вопрос НЕ В ЭТОМ, вопрос в том, как это ПРАВИЛЬНО делать, замечу, делать именно в программе 1С, а не где-то еще

Вся ветка напоминает примерно следующее
— А как в 1С можно прочитать avi-файл?
— Платформой никак, только как двоичные данные, а дальше делай с ними что хочешь
— Спасибо, все понятно
— Читать avi-файл как двоичные данные? Нахрена?
— Никто не читает avi-файлы как двоичные данные, это дико, надо использовать потоковое чтение
— Граждане, так вопрос же был про 1С, а не про то, как avi-файлы можно и нужно читать в других языках программирования
— Да понятно, что в 1С можно прочитать avi-файл только как двоичные данные, но это неправильно, просто 1С так решила
...
— Уже было, что читать avi-файл как двоичные данные — это неправильно?

(250) >>Только вот гарантировать, что порядок гуидов при этом будет совпадать с хронологическим порядком записи объектов, они не берутся
А нахрена им это гарантировать?

(251) Да по ходу где-то неподалеку наркоманскую секту адвентистов хронологической сортировки по гуиду разогнали, они все сюда прибежали

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

(256) Да в принципе да, можно было остановиться на (2) и проигнорировать дальнейшую бредятину, но вот что-то решил поспорить

(115)>> То есть если я в номер вместо 0010123 напишу 0000001, то он сразу станет самым первым в этой секунде что ли?
Для кассовых документов номер документа является уникальным в течении года.
Что ты хочешь от получения ппоследний по ссылке? Без учета того, что это не внешний гуид сформированный по версии Версии 3 и 5
https://ru.wikipedia.org/wiki/UUID#Версии_3_и_5

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

Но если ты используешь пагинатор, то при выводе документов нужно использовать определенную сортировку.
Для документов это как правило номер документа, или День документа номер документа.
Или ДатаДокумента посекундно и номер документа.
Для документа может меняться время очень часто. Ставят в конец или начало дня. Итд
Можно делать что угодно, но МАКСИМУМ(Ссылка) вернет последний документ отсортированный по ссылке byte[16]
Хотя время документа может быть изменено, GUID может быть получен из внешней системы итд.
Но все зависит от того что тебе нужно.

(0) Профайлер посмотри - увидишь в какой SQL-запрос превращается 1С-ный запрос

в (49) вон показывает человек

(258) Да прочитай уже ветку что ли, уже сто раз сказали, что нужно

(261) Читать долго. В любом случае правильно использовать выбрать последние по нескольким полям в зависимости от условий. Или ты не согласен?

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

(263) Мне интересно твое мнение и твои аргументы. То, что я читал, даже чукче ну ни как не аргумент.

(264) Мой аргумент очень простой
Сама 1С использует сортировку по дате + ссылка (момент времени — это то же самое и есть) как единственный вариант упорядочивания, когда речь идет о необходимости упорядочить документы
Будь то для журнала документов, будь то для последовательностей, будь то для формирования движений по регистрам, будь то для отчетов, где угодно

+(265) Вообще, 1С при необходимости берет и добавляет нужные для упорядочивания реквизиты, например номер строки в регистрах
А тут почему-то решила завязаться на регистратор, хотя можно было бы сделать другой реквизит числового типа

(265) Молодец! И как же противоречит то что я сказал, что нужно использовать Выбрать последние по нескольким полям в зависимости от условий?
В данном случае Дата, ссылка, но может и Дата, уникальное значение в течение дня.
Ты же подтверждаешь мои слова. Но почему то ты с моими выводами не согласен!

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

(268) Кстати, вот по поводу того, что это будет быстрее, я как рах не уверен, ХЗ, но вообще по логике должно быть быстрее

(269) Зависит от используемого индекса. Если сортировка использует индекс будет одинаково.
Выбрать первые ты тоже можешь использовать в подзапросах
v8: Подзапросы с Выбрать Первые

случайно наткнулся: "Это решение отличается от применяемого сейчас сомнительного приема, когда документы внутри одной секунды упорядочиваются по внутреннему идентификатору и таким образом погашаются в случайной последовательности."
https://infostart.ru/1c/articles/262300/

(271) >>таким образом погашаются в случайной последовательности
>>Неоплаченные долги при распределении оплаты по правилу ФИФО
Противоречие и непонимание сути, дальше можно не читать

(249) >>ГДЕ Ссылка > &СсылкаПредудыщая"

Дин. списки и списки объектов в ОФ  вроде бы по такому же принципу выводят данные порциями, типа
select top 25 * where _IDRRef > @PrevRef

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

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

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

А вот что пишет ИТС по этому вопросу в https://its.1c.ru/db/metod8dev/content/2737/hdoc

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

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

(278) Что за "оперативная отметка времени"? Ты точно не про семерку?

(279) Глобальный контекст (Global context)
ПолучитьОперативнуюОтметкуВремени (GetRealTimeTimestamp)

Синтаксис:
ПолучитьОперативнуюОтметкуВремени()

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

Описание:
Получает оперативную отметку времени.

Доступность:
Сервер, толстый клиент, внешнее соединение.

Примечание:
Получение оперативной отметки времени выполняется также системой автоматически в ходе оперативного проведения документов.

Использование в версии:
Доступен, начиная с версии 8.0.

1000 рублей занесешь к ДенисЧ

(280) И что это и нахрена?

Есть очень простая тема с не очень удачным решением
А вокруг нее зачем-то какие-то кучи всякого мутного дерьма наворотили

(277) А, так это оказывается про вообще другое https://its.1c.ru/db/metod8dev/content/2312/hdoc
Понатащут всякой дряни в ответ на вполне себе конкретный сабж

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

(285) Оперативная отметка времени — это вообще про оперативный режим проведения, причем здесь нахрен упорядочивание документов?
Выдыхай, бобер

(286): тебе бы выдохнуть лучше, истеричка. перечитай (280) по слогам. а потом по слогам же - читай слово "также". до просветления. если оно случится. и не прерывайся на метание говна и истерики пока не.

(287) Какие все кругом умные, плюнуть некуда
Давай еще раз, где отметка используется ТАКЖЕ я понял, давай теперь, какое ее основное назначение и какое это отношение имеет к сабжу?