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

А при поиске вверх, т.е. предшествующих документов, данный ф.м. делает такой же full scan, если индекс VBFA~M01 не активирован. (Все понимают, что во многих случаях ссылку на предыдущий документ можно в самом последующем документе взять, не обращаясь к потоку.)

Аналогично для сложных случаев использую RV_ORDER_FLOW_INFORMATION. Кстати, может быть не совсем в тему. Был случай, когда не хотели сторнироваться логистические документы сразу после использования этого модуля. Ссылались на, точно уже не помню, что то связанное с ролями партнеров. Вопрос решился тем, что в BELEGTYP передал явно тип документа сбыта. Что то там не подчищалось в памяти.

Очень даже в тему. Хороший пример тому, что использование стандартных ф.м. вместо простых селектов — палка о двух концах.

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

Я же говорил, что для алгоритма "сверху вниз" можно использовать select с VBFA
А вот примеры "снизу вверх":
а)счет-фатура по услугам создается на основке заказа сбыта, а счет-фактура по материалам - на основе исходящей поставки.
Цель - в обоих случаях выйти на контракт или на спецификацию к контракту
б)есть 2 разные цепочки заказов, в которых документ одного типа находится на разных уровнях...

А в случае, когда необходимо найти ровно один документ вверх по цепочке, VBFA не нужен. Достаточно VGBEL и VGPOS

Так я ж не спорю. Ты говорил, что в этом случае можно. А я, что этот случай, как правило и нужен.

Я тоже это говорил.
Но бывают случаи, когда известен только номер фактуры и нужно найти все предыдущие документы: поставка, заказ, контракт (если таковые существуют). Тогда нет смысла селектить VBRP/VBRK. Можно считать всё из потока одним селектом или одним вызовом ф.м.

Именно. для этого, помнится, и использовался join