ДД
Подскажите чтобы это могло значить:
в ответ на письмо по реализации задачи пришел ответ с фразой

Цитата:

INNER JOIN таблиц VBFA и VBAK обычно не делают ....

Честно говоря не понял глубинного смысла этой фразы. В таблице VBAK одно ключевое поле VBELN. В таблице VBFA есть ссылки на VBAK по ключевым полям VBELV и VBELN. Почему нельзя их объединить? может есть какие-то подводные камни?

Гуру, подскажите!

Ну, возможно, дело в нецелесообразности. Зачем вам брать все позиции заказа. если надо прочесть заголовок один раз ?

Делать то INNER JOIN никто не запретит, только что вы хотите этим добиться?
Заказ может входить в одну фактуру, потом эту фактуру отсторнируют, создадут другую и тд - все это отражается в потоке документов, в таблице VBFA.

В том-то и дело, что мне нужно получить все позиции заказа.

Позиции заказа находятся в VBAP. Не совсем понятно, зачем тут VBFA...

VBFA - священная таблица в сбыте, на ней одной висит вся история сбытовых цепочек, причем не только последовательно, но и всех со всеми. В общем, этого монстра не рекомендуется включать в JOINы - есть какая-то указивка SAP по этому поводу.
Включите дебаг и помотрите, как формируется поток документов в SD (зелёненькая кнопочка в заказах, поставках, фактурах). Скорее всего есть специальные ФМ для обработки истории. В них - SELECT SINGLE по ключу, или что-нибудь в этом роде...

Можно ли более подробно, чем может навредить INNER JOIN "священной таблице"? Просто довольно часто приходится встречать заявления, будто INNER JOIN использовать нежелательно, и лучше использовать SELECT SINGLE. Но конкретных причин никто не указывает. По своему опыту могу сказать, что есть два неприятных последствия использования INNER JOIN.
1) Есть вероятность ошибки оптимизатора, и он создаст неудачный план запроса.
2) Пока SELECT не выполнится, система не может снять процесс по TIME OUT, а это ужасно бесит администраторов.
На мой взгляд, это недостаточное основание для отказа от JOIN. Обычно обе проблемы так или иначе удается обойти другими путями.

И ещё десяток нот посвящено этой же проблеме (преимущественно в подмодуле IS-A-GR).

Других причин отказываться от join'a нет.

PS. Вот с MSEG'ом VBFA джойнить действительно нельзя.

Конкретно для VBFA INNER JOIN ничем не повредит, если она канеш не кластерная - просто результат может оказаться не таким как ожидали

Не совсем понятно - а разве SELECT SINGLE и INNER JOIN друг с другом не совместимы?..

И до сих пор остается неотвеченным главный вопрос - ЗАЧЕМ? Какую дополнительную информацию вы собираетесь почерпнуть из VBFA ?

Если таблица не кластерная, то JOIN по идее не должен повредить (если, конечно, он делается по ключу). IMHO часто проблемы с VBFA возникают из-за того, что к ней приходится обращаться "наоборот": не по VBELV/POSNV, а по VBELN/POSNN. Вот этого SAP делать и не советует.

ФМ "RV_ORDER_FLOW_INFORMATION"

А JOIN с VBFA - это гиблое дело.
Jelena +1

Гиблое в каком смысле? ФМ RV_ORDER_FLOW_INFORMATION работает раз в 10 медленее.

что-то и правда не совсем понятно...
ну так почему нельзя или нежелательно делать JOIN, и почему результат может быть непредсказуем именно для VBFA? какие на то конкретные причины? дайте ноты, факты, примеры...может и правда есть что-то
ведь объединяют же BKPF, BSID, BSAD и т.д, которые гораздо объемнее чем "монстр" VBFA

а то что в САПе нет примеров JOIN-a c VBFA, может из-за того как и указал sibrin, что в некоторых системах она кластерная?

в качестве примера когда может потребоваться объединять VBFA, можно предложить например чтение определенных документов для вышестоящего документа по потоку, с дополнительными данными/критериями которых нету в vbfa

ps: все конечно же ИМХО

Это смотря как пользоваться
Понятно, что кроме VBFA этот ФМ читает и VBUK, и VBAK и еще кучу таблиц.
Но если осуществлять поиск "снизу вверх", что чаще всего встречается, то быстродействие вполне приемлимое.
И если учесть, что тебе не нужно самому просчитывать цепочки документов, которые к тому же могут оказаться разной длины в разных случаях, гибче применять именно этот ФМ. Или написать свой, который будет работать лучше.
Но с JOIN лезть в таблицу, в которой есть ссылки и вверз, и вниз, по позициям и по заголовку имхо очень мазохистское занятие

1.Связи между документами сбыта делаются с помощью настройки. При жестко заданных условиях поиска по VBFA при изменении настроек нужно менять программу.
2.Связь между документами хранится как по заголовку документа, так и по позиции. Может быть ситуация, когда от поставки до заказа связь идет по позиции, а предыдущий документ (контракт) в цепочке связан с заказом только по заголовку. В этом случае одним select`ом не обойтись. И неизвестно, сколько промежуточных заказов может быть в цепочке до контракта.

Маленькое резюме: JOIN c VBFA оправдан, когда
1.Поиск документов идет "сверху вниз", от контрактов к поставкам и фактурам
2.Настройки цепочки документов сбыта меняться не будут
3.Есть время и желание изучить уже имеющиеся цепочки документов