Есть документ с реквизитом типа "Дата". Надо добавить вычисляемое поле в выборку, где помимо этого реквизита будет "разность дат" между соседними строками. То есть примерно так:

Ссылка - Дата - РазностьДат
1. Ссылка1 - 01.01.2022 - 30 (количество дней между первой и второй записью)
2. Ссылка2 - 31.01.2022 - 28 (количество дней между второй и третьей записью)
3. Ссылка3 - 28.02.2022 - х (количество дней между последней записью и текущей датой)

Как можно сделать это в одном запросе? Можно конечно вычислять их и после выполнения основного запроса, но это динамический список, и надо именно в запросе.

Пусть будет таблица ВТ_ДОКИ(Ссылка,Дата). Тогда:

выбрать
  тт1.Ссылка,
  тт1.Дата,
  РазностьДат(НачалоПериода(минимум(тт2.Дата),День), НачалоПериода(тт1.Дата,День), День)
    как РазностьДатМеждуДокументами
из
  ВТ_ДОКИ как тт1
  левое соединение
  ВТ_ДОКИ как тт2
  по тт1.Дата < тт2.Дата
сгруппировать по
  тт1.Ссылка, тт1.Дата

Не проверял, но вроде так.
Динамические списки поддерживают временные таблицы где-то с версия 2018 года.

(0)
1. Добавить автономерзаписи в ВТ
2. Соединить ВТ саму с собой по ВТ.НомерЗаписи + 1 = ВТ2.НомерЗаписи

(2) Оно не позволяет сортировать временные таблицы, если нет ПЕРВЫЕ. А для автономерзапии в порядке даты это нужно.

(3) лайфхак: первые 99999999999

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

(4) Так нужно было в (2) об этом писать)
(5) В ТС написано, что для ДС

(4) А ты уверен, что оно корректно это отработает для заведом меньшей таблицы? Оптимизаторы они таки, капризные.

(7) Ни разу не сталкивался чтобы результат кривой был. Оптимизаторы могут давать неоптимальный запрос, но чтобы кривой результат...
(6) в (2) просто идея. Против классического (1) в данной ситуации ничего не имею. Минимум() только забыл)

(8) Есть там минимум. Маленькими буковками. Это не является ошибкой)

А вот по вопросу сортировки. Она задокументирована, что сделана для ПЕРВЫЕ. И если при этом работает автономерзаписи в желаемо-предполагаемом виде, то это побочка, а не явная фича. Потому что если сортировка только для первые, а кол-во строк в таблице известно заранее, то оптимизатор может посчитать сортировку лишним действием.

если известно заранее и заведом меньше кол-ва затребованных первых

Учитывая что оно может выполняться на файловой, на MS SQL разных версий, на PostgreSQL. И эти скл имеют свои еще оптимизаторы, тут сложно наверняка сказать, что оно всегда будет правильным.

(1) Спасибо, все прекрасно работает. Но вот незадача: мне понадобилось еще по одному полю группировать - по Контрагенту из документа, чтобы получался вот такой результат:
Контрагент1
   Ссылка1 Дата1 РазностьМеждуДата1ИДата2
   Ссылка2 Дата2 РазностьМеждуДата2ИТекущаяДата
Контрагент2
   Ссылка3 Дата3 РазностьМеждуДата3ИДата4
   Ссылка4 Дата4 РазностьМеждуДата4ИДата5
   Ссылка5 Дата5 РазностьМеждуДата5ИТекущаяДата

И вот в этом случае я получаю для Контрагента2 (для последнего) правильный результат по разнице между датами, а для всех остальных - немонятно что. Например, разницу между 01.01.2022 и 01.06.2022 получаю 3 месяца вместо пяти (если переводить в месяцы). Группировка у меня делается уже в настройках СКД - а именно в Настройки - Отчет - Новая группировка.

+(12) А если добавить Условие: по одному контрагенту, то все выводится и рассчитывается правильно!

(13) Там еще нашелся вариант, он немного проще в использовании. Вот здесь в 4 сообщении:
Получение первого элемента при связи вложенным запросом

В нем не нужно группирование и максимум. Но лично я пока такое не проверял в действии.