При работе с BAPI сбытовых документов, они использую функции из одни и тех же инклудов, в связи с этим возникают глюки неочищения буфера.
Требуется чтоб каждая из 3 BAPI выполнялась в своём потоке. Чтоб области памяти не пересекались.
Пока удалось разделить только 2 BAPI
1е выполняется в основном потоке
2е выполняется в FM RFC destination 'NONE'.
Если 3е BAPI тоже выполнить в FM RFC destination 'NONE' оно попадает в один LUW со 2м и начинаются глюки.

CALL FUNCTION STARTING NEW TASK использовать запрещено, заказчик такого не примет.

после каждой bapi luw должен закрываться,
можно поискать ф/м и подпрограммы очистки;
или, если не запретили, попробовать call function .. in background task [as separate unit]
вроде ограничений на новый luw нет, надо проверять.
submit report тоже вероятно поможет

RFC-вызов порождает свой контекст (в вашей терминологии LUW).
Беда в том, что этот контекст существует либо до принудительного закрытия соединения (например, ФМ RFC_CONNECTION_CLOSE), либо до завершения работы программы, установившей соединение. То есть, определяется соединением (NONE в данном случае). Соответственно, у вас не получается запустить дважды RFC-модуль с одним соединением - они попадают в один контекст.
Если по условию требуется делать вызовы параллельно, никуда от STARTING NEW TASK не уйти.
Если можно делать вызовы последовательно, закрывайте соединение перед последующим его использованием.

Вызовы BAPI происходят последовательно. Программа: селекционный экран+ экран с ALV На экране c ALV есть кнопки, "провести документ",
"стронировать документ". Если делать провести->сторнировать->провести, то на второй проводке BAPI выдает глючные ошибки, чтоб не было ошибок нужно выходить на селекционный экран и возвращаться.

Не пробовали "завернуть" вызов BAPI в программу и 3 раза последовательно делать SUBMIT?

жестковато. согласен с Nicky555, вызывайте bapi в destination NONE, после вызова делайте RFC_CONNECTION_CLOSE для NONE. все будет хорошо

ps: bapi_transaction_commit / rollback надо тоже вызывать с destination NONE, а уж после RFC_CONNECTION_CLOSE конечно, тогда контекст будет всегда новый