В Бухгалтерии для Казахстана в документе РасчетУдержанийРаботниковОрганизаций в запросе, формирующем актуальный список работников делается так:

ВЫБРАТЬ
   МАКСИМУМ(РаботникиОрганизацийСрезПоследних.Приказ) КАК Приказ,
   РаботникиОрганизацийСрезПоследних.Физлицо КАК Физлицо,
   РаботникиОрганизацийСрезПоследних.Организация КАК Организация
ИЗ
   РегистрСведений.РаботникиОрганизаций.СрезПоследних(
           &парамНачало,
           Организация = &парамГоловнаяОрганизация
               И ВидЗанятости <> &парамВнутреннееСовместительство) КАК РаботникиОрганизацийСрезПоследних

СГРУППИРОВАТЬ ПО
   РаботникиОрганизацийСрезПоследних.Физлицо,
   РаботникиОрганизацийСрезПоследних.Организация


Вопрос: что дает в этом запросе МАКСИМУМ() от поля типа ДокументСсылка.ПриемНаРаботу?

произвольный приказ. это им лень было "выбрать первые 1" делать

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

теоретически уиды инкрементятся в пределах типа метаданных и узла РИБ

(2) максимальный по ссылке.

но на самом деле - надо было отсортировать в обратном порядке по дате и выбрать первый (т.е. последний)

(2) в том то и дело что не всегда...

(2) неправильно.

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

(7) а может тот, кто это писал думал именно так, как в (2), поэтому мы и видим это тут.

максимальный в приделах даты одной....
вроде так...

(5) это если выбирать нужно 1 физлицо. а если 10 то первые 1 не поможет

(8) ну, я глубоко не копал, но, наверное, так и есть. для выбора произвольных данных - прокатывает, иначе надо явно делать как в (5)

(10) а я-то думал... а если задним числом вводят?

(2) как правило так, но Нуралиев это не гарантирует! (с)

псц скока "знающих"...........

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

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

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

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

"теоретически уиды инкрементятся в пределах типа метаданных и узла РИБ" - булшит... они генерятся в пределах одного сеанса для всех метаданных...

(17) в том-то и дело, что механизмов задать порядок документов внутри секунды в v8 нет...

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

(21) я же говорил - глубоко не тестил... так, один раз поглядел, что на разных РИБ узлах префикс разный, но одинаковый, как и на метаданных...

еще подкинем дровишек в костер обсуждения.

на 8.1 нормально отрабатывает...
а это версия 2.0.2.10 под 8.2...

(20) у человека 2 приказа о приеме.
и они на разную дату.
и почему то выбирает ранний! (

>>что дает в этом запросе МАКСИМУМ() от поля типа ДокументСсылка.ПриемНаРаботу?

Отсортирует по представлению и выдаст максимальный. Соответственно, для типа документссылка может выдать документ ЯЯ00000001, для составного - какое представление больше понравится)

(25) вроде 1С исправило эту фичу, теперь не по представлению там, а по гуиду.

(25) сам придумал?

(27) конечно, сам

(28) ну а тут про 1с говорим, а не про то что ты там напридумывал