Есть Документ1. На его основании могут сделать Документ2 так, что Документ2.Основание = Документ1. Дальше могут сделать Документ3, где Документ3.Основание = Документ2. И так далее.

Для Документ1 нужно найти последний документ в цепочке (Документ3)

На ум приходит периодический РС, но это работает до тех пор, пока Документы вводятся в хронологическом порядке. Но если установить дату Документа2 позже даты Документа3, то срез последних не покажет Документ3.

Есть идеи?

типовая структура подчиненности может подойдет

(2) Так подходит. Вот только надо в запросе получить последние документы в цепочки для массива ссылок.

Измерения: Основание, Документ. Ресурс: Уровень - число.
При новой связи копируем все строки Где Документ=&ТекущееОснование заменяя Документ на текущий и увеличивая уровень на 1. Плюс добавляем текущую связь 1 уровня

(4) РС независимый что ли?

И для чего это все?
Надо ли регистрировать майстрячить если это нужно собрать раз в день?

(0) изучайте теорию графов и хранение графа в реляционной базе

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

(0) Если структура подчиненности - дерево, какой документ будет последним?

(9) На основании документа можно сделать только один документ, но замечание хорошее

(10) Вы пишете всякую чушь, уж извините

много неопределенного, поэтому конкретных советов быть не может
как хранится основание, Документ2.Основание = Документ1 это реквизит?
Или платформой НаОсновании и ппц?

(3) в целом скл наверно поможет, но не забывайте про лицензирование (!)

(5) вполне

(4) почему нельзя просто: измерение - документ, ресурс - последний документ?

(15) можно все. Только вводить на основании можно ведь много документов. Там граф дерево (куст я бы сказал)

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

мне кажется, что это хранится в скл, в виде

ИД        ИДродителя
123        
321        123
123321    321

и так далее, все это можно вытащить и обработать как надо, а можно еще на уровне скл правильный запрос написать и получить готовое
ну можно кончено и свой регистр с казино сделать
а для этого надо понимать, что вобще нужно
хронология - это время, а цепочка это последовательность и совсем необязательно во времени. 1, 2, 3 - цепочка и неважно, когда во времени в ней появилась цифра 2 или 3

(0) реквизит "документ-основание" в документах, критерий отбора и рекурсивный запрос

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

(19)(20) более того, запросов к РС будет ровно столько же, сколько к КО.
Т.е. это как раз тот случай, когда денормализация не приводит к выигрышу.

(0) дешего и сердито писать в каждую запись регистра просто самый первый документ основания

(22) пишется "дёшево"

(0) изучайте объект под названием "Критерий отбора". Это то что Вам нужно, походу.

(2) согласен ...я делал такую задачу именно так