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

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