Коллеги, прошу помощи зала.

Задача: при создании запроса через VA11 необходимо осуществить некоторую проверку и по результатам разбить запрос на несколько.

Как реализовывал:
- в USEREXIT_SAVE_DOCUMENT_PREPARE поставил точку расширения
- в ней сделал проверку
- обернул ФМ BAPI_SALESDOCU_CREATEFROMDATA в отдельный ФМ
- при проверке из внутренних таблиц удаляю всё лишнее, оставляю только для первого документа
- для остальных данных заполняю таблицы и вызываю свой ФМ

Грабли:
1. не даёт запустить свой ФМ в update task (валится в дамп, мотивируя что "реальная" блокировка в обновлении невозможна)
2. если же запускать не в update task, то сохраняет только тот документ, который создаётся через ФМ.

Вопрос: где собака порылась ?

Добрый день.
У меня была похожая задача. Я победила дамп:
Попробуйте свой ФМ создать как
-МОДУЛЬ ОБНОВЛЕНИЯ
-ЗАПУСК ОТКЛАД.
И запустите через update task

Все "грабли" растут из попытки "впихнуть невпихуемое", а именно - засунуть в одну SAP LUW создание/изменение нескольких документов (бизнес-объектов). Это противоречит логике работы системы в принципе
Выход всегда один - разбить разные бизнес-объекты по разным SAP LUW.
Сделать это можно несколькими способами:
Способ 1 подсказала dev403k - фактически, в ее варианте "вторичные" документы приобретают статус статистических данных, отложенных на V2-Update.
Способ 2 заключается в генерации вторичных документов по событию в системе - например, создания первичного документа.
Оба способа относительно надежны, поскольку требуют контроля отсутствия ошибок вне исходной транзакции.

dev403k, я изначально так и сделал, о чём и указал во вводной Получил вышеописанный дамп.
nicky555, воистину так. Меня в запарке немного сбило другое обстоятельство, а именно: там же вызываю ещё несколько ФМ-ников в update task, все отрабатывают нормально.
В итоге сделал по-старинке: ФМ вызываю не в update task, но внутри него БАПИшник вызываю с destination 'NONE' и т.д.
Может и не совсем спортивно, но работает.

А почему не спортивно?

Ну, формально-то я ничего не нарушаю. Но на некоторых проектах доводилось узнавать о себе много нового от консультантов, которые смотрели код с такими конструкциями
Так что тут вопрос из разряда религиозных.

Просто я про эту конструкцию не могу сказать/вспомнить ничего плохого, наоборот - несколько раз очень выручала.
Так что, да, наверное это вопрос предпочтений.

Пара нюансов при синхронном вызове функции по RFC-соединению NONE:
Вызов ФМ плодит новый контекст (область памяти, в которой работает процедура) на том же сервере приложений. В этом контексте и выполняется процедура. Причем контекст будет жить либо до завершения работы программы, установившей соединение, либо до ручного закрытия соединения (например, ФМ RFC_CONNECTION_CLOSE). Отсюда есть определенные ограничения:
1) Возможны взаимные блокировки;
2) Возможна перезапись данных контекста при повторном вызове;
3) Если ФМ генерит, например, динамическую программу (внутреннюю таблицу), то есть шанс упасть в дамп при достижении потолка динамической генерации при вызове в цикле - лечится закрытием соединения (см. выше).