Воапрос: как провести второй док материала на основе первого проведённого из MIGO.

Тема эта уже несколько раз обсуждалась, но вот нормального решения я так и не увидел.

Варианты
1) "IF_EX_MB_MIGO_BADI~POST_DOCUMENT вызываешь ФМ BAPI_GOODSMVT_CREATE в режиме IN BACKGROUND TASK или IN NEW TASK"

Но на это момент первый документ ещё не сохранен - он только отправляется на сохранение, соответственно если так делать то надо в новом процессе ждать когда появится документ в БД.

2) вызываешь ФМ BAPI_GOODSMVT_CREATE в режиме IN BACKGROUND TASK или IN NEW TASK из модуля обновления который выполняется IN UPDATE TASK

Однако вызов таких штук приводит к неявному database commit что в итоге может перевести к не консистентности БД

3) Вызвать из модуля обновления ФМ BP_EVENT_RAISE оно вроде commit не вызывает, ну и обработать событие

Событие обрабатывается в фоновом задании под тем пользователем под которым оно запланировано (а не инициировано)


По всей видимости надо развивать вариант 1 но уж больно както ...

1.Верный способ дождаться создания документа материала - в цикле проверять блокировку на запись (например блокировку запаса материала на заводе или блокировку партии).
2.
Где происходит вызов неявного commit при call funcion .. in background task?

Согласен тут я ошибся. ФМ запускается при Commit work в вызывающей программе.

а STARTING NEW TASK однозначно вызывает commit

проверил всё это эксперементально.
-----------
Так что наверно можно сделать вызов ФМ in background task из модуля обновления

Сдается мне, какая-то у Вас путаница.

Всем привет.
Хочу поднять эту тему - как наиболее грамотно создавать второй документ материала при проводке в migo?
Задача - сохранить консистентность БД и чтобы либо оба документа материала создавались, либо - оба нет.
Сейчас в голове крутится запускать бапи BAPI_GOODSMVT_CREATE в программе обработки выходного документа к первому материалу. Вопрос - что делать, если на выходе бапишики есть сообщения с ошибками, чтобы не допустить сохранения первого документа материала. Выдать message e?
Что скажете?

LKU, как угодно.
Второй начинать проводить только когда первый уже реально лежит в БД.
Если второй падает - сторнировать первый.
Ну и оповещать юзверя почтой, например.

Ну, сторнировать 1-й, если не провелся второй - это запасной вариант. Но как-то не хочется плодить в системе лишние документы.

Поэтому вопрос формулирую именно так - есть ли реальный способ создать два документа материала в единой транзакции?
Слово "транзакция" я здесь использую в обычном программистском смысле, а не в саповском: либо оба документа создаются, либа оба - нет

Если они связаны (например второму нужен запас после первого) - то нет.
В противном случае можно.
Как самый простой вариант, и если позволяет версия, - заэнхансить MB_CREATE_GOODS_MOVEMENT.

Может быть попробовать воспользоваться BADI MB_MIGO_BADI и методом POST_DOCUMENT. Позвать в нем update task бапишку и там, если ошибка сделать ROLLBACK.

Так первый документ все одно останется в системе. Его, понятное дело, можно и нужно сторнировать. Но LKU хочет транзакцию и отсутсвие мусора...

А точно ли он останется? Если это будет update v1, то должен будет откатиться и главный документ, тем более, что в очереди апдейтов, как мне кажется, первым будет второй документ (хотя это не должно иметь значения для v1, вроде бы).

Попробовал сейчас. Вродебы получилось то что надо. Или мне просто этого очень хотелось

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

to lars: Я потому и подумал про выходные документы, что они, насколько я знаю, запускаются in update task. Во всяком случае, если в выходных документах есть ошибка, то пользователю приходит сообщение об оштибке обновления и документ материала не сохраняется, это я точно знаю.

В общем, буду эксперементировать.

Вы правы, можно, просто сделать mesaage типа E.

Написал тестовую программу. Использовал свою первоначальные идеи:
- вызов бапи в программе обработке выходных документов
- message e в случае проблем.
Update task при вызове бапи не использовал, так как выходные документы уже вызываются в апдейт таске.

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

А мне с энханметном все равно больше нравится.
Бо ошибки сразу в лог создания документа материала сыпятся. В MIGO, например, очень user friendly получается

Про то, что первый останется - это я, конечно, неправ был. Перестраховался.