Здравствуйте. Возникла следующая задача. Необходимо выполнить несколько шагов в одном LUWе (транзакционно, как единое целое, т.е. с коммитом только после окончания всех шагов).
Шаг 1. Создание ОС (субномер 0000) с помощью ФМ-а BAPI_FIXEDASSET_CREATE1.
Шаг 2. Создание субномера 0001 для ОС из шага 1 с помощью ФМ-а BAPI_FIXEDASSET_CREATE1.
Шаг 3. Поступление для субномера 0001 с помощью ФМ-а BAPI_ASSET_ACQUISITION_POST.
Шаг 4. Движение материала для субномера 0000 с помощью ФМ-а BAPI_GOODSMVT_CREATE.
Проблема в том, что после шага 2 приходится обязательно выполнять "промежуточный" коммит, иначе ФМ-ы из шагов 3 и 4 не видят свежесозданное ОС.
SET UPDATE TASK LOCAL не помогает. Создание ОС происходит внутри BAPI_FIXEDASSET_CREATE1 путем вызова CALL FUNCTION 'RA_ASSET_MODIFIKATION' IN UPDATE TASK. Соответственно, если не коммитить после шага 2, на шаге 3 запись насчет новой ОС в anlh еще отсутствует, а BAPI_ASSET_ACQUISITION_POST уже лезет проверять наличие такой записи.
Попытка сделать ФМ-оболочку, включающий в себя все эти шаги, и вызвать его IN UPDATE TASK, также не привела ни к чему хорошему. Внутри BAPI_FIXEDASSET_CREATE1 (include LAISTF20) происходит вызов экрана: CALL SCREEN GD_DYN-MAST, соответственно при таком вызове ФМ валится в дамп.
Может, кто-либо уже решал задачи подобного рода? Или у кого-нибудь появятся идеи? Спасибо.

RA_ASSET_MODIFIKATION проходит по v1, странно, что set update task local не сработал,
он вызывается перед всеми шагами?
поставьте select .. from anlh и убедитесь, что она считывает новую запись перед шагом 3,
ещё возможно, что шаг 3 ..post использует данные ,которые прописывались в шаге 2 по очереди v2,
такие ф/м не проходят по set update task local

Забудьте. Без промежуточного коммита никак. SET UPDATE TASK LOCAL просто гарантирует, что сразу ПОСЛЕ коммита все данные будут физически в базе.