Выходной документ создается автомотически при создании документа, если, конечно, есть соответствующие настройки.

А как нам "внедриться" в создание выходного документа?

SPRO->Управление материальными потоками->Управление запасами и инвентаризация->Выбор выходных документов->Ведение видов выходных документов

Здесь указываем программу и подпрограмму обработки.
Может так?

Именно так.
Отлаживать проще через mb90 по нажатию кнопки "предварительный просмотр", так как в этом случае программа обработки выходного документа работает не в фоне, а в диалоге.

Большое спасибо. Сейчас пробую все настроить.

Поднему тему, возникла похожая ситуация.
Задача стоит следующая: на расходном виде движения необходимо на техническом заводе сделать приход забаланса списываемого материала.
Использовать событие с выходными формами нет возможности, необходимо для реализации использовать события
1. POST_DOCUMENT бади ZMB_MIGO_BADI
2. события бади MB_DOCUMENT_BADI
для создания ДМ использую бапи MB_CREATE_GOODS_MOVEMENT

Как сказано в сап ноте на событие создания ДМ использовать бапи ДМ можно только с BACKGROUND TASK
Если бапи вызывать с BACKGROUND TASK то каким образом удостоверится что второй ДМ создался успешно? Что бы в случа чего сделать откат первого. Веть в BACKGROUND TASK нет возможности извлечь импорт параметры выполняемого ФМ.
Пробовал запускать бапи и в IN UPDATE TASK - в результате получаю ошибку обновления "ABAP-процессор: GETWA_NOT_ASSIGNED"
Пробовал по разному методом тыка)) идей больше нет((
Подскжите пожалуйста, наверняка у кого нибуть есть готовая техническая концепия данной задачи)
Спасибо)
PS система 6.0

to aivengo : Почти такую же задачу решал. Перемещение но отпускаемый и принимаемый материалы имели различные складские ЕИ. поэтому пришлось делать такое перемещение создавая ОМ на тех. счет и сразу же ПМ с тех.счет. Так вот ОМ создавался через ФМ "MB_CREATE_GOODS_MOVEMENT" он вызывался без UPDATE TASK , а создание ПМ я завернул в ФМ обновления , который вызывал в методе MB_DOCUMENT_BEFORE_UPDATE в реализации Badi MB_DOCUMENT_BADI. при ошибке создания ПМ ФМ обновления рейзит ошибку что соот-но вызывает ошибку обновления. Результат - или оба создаются или ничего не создается.

К сожалению ваш способ не подошел, пробовал по всякому получал либо шибки обновления (если UPDATE TASK) или сообщение "модуль bapi невыполним", у меня система 6.0
Реализовал следующую концепцию, вроде работает, может кому пригодится:
1. В качестве события использую ФМ MB_POST_GOODS_MOVEMENT
там есть две точки расширния одна в начале модуля другая в конце
данный модуль звенит единожды на каждом ДМ который создается как в интерфейсе так и в бапи, в нем есть флаги отвечающие за просовывание ДМ в коммит.
2. В начале модуля копирую табличку xmseg xmkpf во внутренние таблицы
3. В конце модуля анализирую эти таблицы на предмет надо ли создавать второй ДМ
если надо то готовлю данные для bapi
4. если надо создавать ворой ДМ в модуле снимаю флаги внутренних переменных отвечающих за коммит
CLEAR: XCOMMIT, SAVE_MBLNR, SAVE_XABLN.
далее вызываю непосредственно саму бапи для второго ДМ не в апдейт таск а в обычном режиме
5. Если бапи нормально отработала то флагам XCOMMIT SAVE_MBLNR, SAVE_XABLN возвращаю старые значения если нет то прерывание и рулбэк

таким образом можно просунуть второй ДМ в одну транзакцию БД
Незнаю насколько красивый способ но работает))

Спустя годы тему вверх.
Ситуация аналогичная сабжу но только наоборот . Пытаемся провести документ в MIGO. Необходимо ДО того как он будет проведен и даже проверен воткнуть еще 2 документа. Схема такая Поставщик->Промежуточный склад->Целевой склад. Есть 2 соответствующих заказа (на поставку и на перемещение). Пользователи хотят проводить только поставку на целевом складе, а чтобы поставка на промежуточный склад и отпуск с него генерились автоматом.
Проблема в том, что провести конечную поставку без предшествующих не можем. Вопрос в какой момент их создать. До MB_DOCUMENT_BADI дело не доходит, проверки выкидывают раньше (на промежуточном складе же еще ничего нет). C MB_MIGO_BADI->POST_DOCUMENT аналогично.
Пока в мыслях сделать преенхансмент в LCL_MIGO_KERNEL->document_post, либо LCL_MIGO_KERNEL->document_operation, но пока сложно представляю, что в них писать(( (BAPI_GOODSMVT_CREATE, MB_CREATE_GOODS_MOVEMENT, MB_POST_GOODS_MOVEMENT...).
Может кому известен более изящный способ решения? Спасибо.

Refresh, может свести задачу к предыдущей?
То есть, договориться с пользователями, что они приходуют товар от Поставщика на промежуточный склад, а уж перемещение делается автоматом? Это и с процессной точки зрения выглядит более оправдано, так как вероятно именно в этот момент переходит материальная ответственность.
Еще, конечно, непонятно зачем вообще нужен промежуточный склад, если в 100% случаев с него идет автоматом перемещение на основной, но вам виднее.

aivengo, недавно в POS интерфейсе SAP я увидел такую штуку:
ФМ POS_SALES_DOCUMENT_PROCESS

Под промежуточным складом я понимаю некоторый консолидационный склад. Т.е. при закупке в региональный центр материал сначала отгружается на этот консолидационный склад, а от туда уже развозится по регионам. Я пока не вижу полной картины, т.к. на проекте всего несколько дней.
Логика оформления прихода именно на конечный склад думаю в том, что проводку делают пользователи именно на конечном складе. К ним пришел товар, они его у себя и провели. Понимаю, что на промежуточном складе приходовать и отпускать товар должны его сотрудники, но видимо есть причины, по которым это не делают.

Вот это здорово. Получается у сотрудников консолидационного склада материальная ответственность равна нулю.

aivengo, недавно в POS интерфейсе SAP я увидел такую штуку:
ФМ POS_SALES_DOCUMENT_PROCESS
[/quote]

Добрый вечер, коллеги.
Уже больше года пользуемся способом, позволяющим создавать нескоклько документов материала в 1 коммите.
Перед вызовом bapi по созданию каждого документа материала выполнить следующий код:

if <_xcommit> is not assigned.
assign ('(SAPLMBWL)XCOMMIT') to <_xcommit>.
endif.
if <_xcommit> is assigned.
clear <_xcommit>.
endif.

Вроде нареканий данный способ не вызвал.