MIRO после сохранения документа.

AlekseyG

Доброе утро.
Подскажите какой-н exit или badi после создания документа, и снятия блокировки на mbew.
(INVOICE_UPDATE не подходит, документа еще нет, материал блокирован)
Хочу прицепить после этого свою цепочку с новыми документами.
Пока вариант один, встроится в LMR1MF1F.

Besa

AlekseyG написал:

Доброе утро.
Подскажите какой-н exit или badi после создания документа, и снятия блокировки на mbew.
(INVOICE_UPDATE не подходит, документа еще нет, материал блокирован)
Хочу прицепить после этого свою цепочку с новыми документами.
Пока вариант один, встроится в LMR1MF1F.

INVOICE_UPDATE метод CHANGE_IN_UPDATE чем не подходит? Документ есть, материал не блокирован.

msi

Коллеги, хотелось бы углубить эту тему, так сказать хочется :roll:

продолжения банкета.
Имеем: транзакция MIRO, сохраняется счет-фактура. Группа функций MR1M, экран 6000, PBO fcode_6000. Далее вызов PERFORM FCOBU (она же Include LMR1MF1F). Так вот насколько я понял BAdi INVOICE_UPDATE отрабатывает в подпрограмме FCOBU в районе вызова PERFORM BELEG_BUCHEN (она же Include LMR1MF0R), в которой в свою очередь сидит ФМ 'MRM_INVOICE_POST', со своими расширениями (то есть и бадя для врезки например как бы и не нужна).
Вся эта петрушка (в FCOBU) происходит задолго до COMMITa. Подобный расклад вещей категорически не устраивает партию большевиков, а заодно и заказчика,

который желает чтобы аккурат ПОСЛЕ появления записей соответственно логистического документа в RBKP и FI-ного например в BKPF (что здесь и является результатом COMMITа) можно было успеть наделать своих подлых дел типа запуска всяких CALL TRANSACTIONов в личных целях.... Так вот вопрос и заключается в том куда и как здесь все-таки цивилизованно врезаться (стену не предлагать) когда необходимо УЖЕ наличие записей в RBKP и BKPF....
Заранее спасибо. :roll:

Пономарев Артем

msi, если вам так уж критично наличие документов в БД - запускайте свой ФМ в бэкграунде из CHANGE_IN_UPDATE и ждите пока записей не появится.

Сергей Королев

msi написал(а):

...чтобы аккурат ПОСЛЕ появления записей соответственно логистического документа в RBKP и FI-ного например в BKPF (что здесь и является результатом COMMITа) можно было успеть наделать своих подлых дел типа запуска всяких CALL TRANSACTIONов в личных целях.... Так вот вопрос и заключается в том куда и как здесь все-таки цивилизованно врезаться (стену не предлагать) когда необходимо УЖЕ наличие записей в RBKP и BKPF....

неоднократно делал такие вещи при помощи фоновых задач Workflow. Если вообще в вашей системе Workflow используется, то можно попробовать просто заюзать его RFC соединения и запускать свою функцию "как бы" удаленно IN BACKGROUND TASK AS SEPARATE UNIT. Поскольку это будет tRFC, то она реально запустится только в случае успешного COMMIT'а. Одно "но", документы будут созданы от имени системного пользователя WF-BATCH.

msi

Пономарев Артем написал:

... запускайте свой ФМ в бэкграунде из CHANGE_IN_UPDATE и ждите пока записей не появится.

Спасибо! Вероятно так и придется делать. Будем попробовать....

msi

Сергей Королев написал:

... можно попробовать просто заюзать его RFC соединения и запускать свою функцию "как бы" удаленно IN BACKGROUND TASK AS SEPARATE UNIT. Поскольку это будет tRFC, то она реально запустится только в случае успешного COMMIT'а. Одно "но", документы будут созданы от имени системного пользователя WF-BATCH.

Красиво конечно :idea:

, но с именем WF-BATCH концов будет потом не найти... :roll:

Правила форума

MIRO после сохранения документа.

Кто сейчас на конференции