Доброго всем дня!

Так уж получилось, что приходится создавать проформа-инвойсы из UPDATE TASK. Используется BAPI_INVOICE_CREATEMULTIPLE, который в свою очередь после создания инвойса запускает RV_INVOICE_REFRESH, в конце которого добрые руки немецких программистов разместили COMMIT WORK который с апдейт таском, как известно, не дружит. Занавес, вылет в дамп.

Несет ли какую-то смысловую нагрузку наличие коммита в данной функции и если вызывать ее из апдейт таска - можно ли убрать вызов коммита (там притаился энхансмент, через который можно выключить коммит)? Несколько боязно, так как наверняка была веская причина его туда поставить

Тоже столкнулся с этим полгода назад.
Ковырялся, ковырялся, в итоге обернул вызов BAPI_INVOICE_CREATEMULTIPLE в Z-Фм, который вызывал асинхронно через CALL FUNCTION 'Z***' IN BACKGROUND TASK

То есть из функции А в UPDATE TASK-e вызывать функцию Б в BACKGROUND TASK-е? Желательно ли использовать нотацию AS SEPARATE UNIT?

У меня была задача сделать автофактрирование исходящей поставки при ОМ, вызов ФМ создания фактуры "IN BACKGROUND TASK" сделал еще до перехода потока управления по сохранению поставки в UPDATE TASK.
Поэтому тут вряд ли подскажу.

Так нельзя сделать, т.к. такой вызов - это неявный commit, который не допускается при обновлении.
Почему нельзя вызвать создание счета-проформы после вызова BAPI?

Попробовал провести эксперимент - дампа нету, но и весь код, который оформлен как ФМ, вызываемая в бэкграунд таске - не отрабатывает.

Ну как бы сказать счет-проформу я как раз и создаю посредством BAPI_INVOICE_CREATEMULTIPLE.
Хронология такова - в апдейт таске стартует некий процесс, частью которого является в том числе и создание проформы. Проформа создается вызовом стандартной саповской БАПИ-функции BAPI_INVOICE_CREATEMULTIPLE, которая по окончании работы вызызвает стандартную саповскую функцию RV_INVOICE_REFRESH. В самом конце рефреш-функции прописан COMMIT WORK, но при этом его можно "задизэйблить" (там есть параметр WITH_POSTING, играя со значением которого можно убрать коммит - например, "H" свидетельствует о том что инвойс создается в симуляционных целях и коммит не делается). В данный момент так и сделал - временно ставлю WITH_POSTING "Z", после того как перепрыгивает через коммит, ставлю обратно старое значение. Вроде бы как работает, проформа создается - но не оставляет подспудное чувство легкой угрозы. Какие риски могут быть от таких трюков?

Выудил интересную дискуссию на схожую тему:
http://scn.sap.com/thread/1473168

Если обернуть вызов BAPI_BILLINGDOC_CREATEMULTIPLE в РФЦ-функцию и вызвать с параметром STARTING NEW TASK DESTINATION 'NONE' - будет нормально?

Таки идея была верна

В общем, если надо вызвать код, содержащий COMMIT из UPDATE TASK - то его надо обернуть в Z-FM, продефинированный как Remote-enabled Function Call. Далее из UPDATE TASK можно вызывать Z-FM STARTING NEW TASK 'ZTEST' DESTINATION 'NONE' - и всё будет!

Надеюсь, кому-либо пригодится!