Call BAPI_GOODSMVT_CREATE several times with COMMIT only at the end

[alexandreourth]

Hello experts,

I am processing a custom IDOC in which i call several times the famous BAPI_GOODSMVT_CREATE. At first there were errors due to the several calls but then i saw a post suggesting we must use DESTINATION 'NONE' in the call of the MF and then:

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' DESTINATION 'NONE'.

CALL FUNCTION 'RFC_CONNECTION_CLOSE' EXPORTING destination = 'NONE'.

My problem is, as i am in an IDOC, i want to do the COMMIT at the end, when all the calls are done and all of them are OK.

So the first call is OK, but at second call, dump => CALL_FUNCTION_REMOTE_ERROR on MB_CREATE_GOODS_MOVEMENT. When i remove the destination NONE, and if i do a COMMIT after each BAPI, there is no problem (but that's not what i want)....

Do you know what is missing here please? I suppose it is related to the DESTINATION 'NONE' extension but i don't know for sure...

To sumup: i need to call several times BAPI_GOODSMVT_CREATE, and do the COMMIT only if all the calls are successful, using the DESTINATION 'NONE' extension (or not if there is another solution).

Remark: I saw the other post and I can't use the TESTRUN parameter and store all the parameters to do a recall again because it's not how the program (old one) has been written and it would take too much time to adjust it.

Thanks a lot for your time.

Regards,

Alexandre

[DominikTylczyn]

Hello alexandreourth

To my knowledge that's not possible. BAPI_GOODSMVT_CREATE uses MB_CREATE_GOODS_MOVEMENT internally, that doesn't support multiple calls without commit between them.

I see two options:

1. either post an entire IDoc with one BAPI_GOODSMVT_CREATE
2. or transfer each material document in a separate IDoc

Best regards

Dominik Tylczynski

[former_member660513]

Hello, just my curiosity - what is the exact error message(ST22)? This topic has been discussed already, like here

https://blogs.sap.com/2014/03/24/several-times-call-bapigoodsmvtcreate-in-the-user-program/

[Sandra_Rossi]

As Georgi said, what error you have behind CALL_FUNCTION_REMOTE_ERROR?

NB: I don't see an obvious reason why 2 calls would succeed without RFC, and 2 calls in RFC in same context would fail. The only difference is what is done before in the same context.

[alexandreourth]

Hello georgislavov and sandra.rossi

I've already checked this thread, and yes the person in the comment has the same problem but maybe you missed it, but there were no answer so...sorry if it's disturbing you if i ask again.

The error is : "Unable to execute function module"

Again, when i do a COMMIT between each call => no problem! The data i use are the same & i can launch as many time as i want.

But this BAPI is known to be full of issues, and in this particular context, i have to chain several calls but i need the COMMIT only at the end. as 3a9e4ce873a94034b33dc62b0ce600ee suggested, i'm started to believe it is not possible with this BAPI....

[DominikTylczyn]

Hello alexandreourth

Again, what you want to do is unfortunately impossible with this BAPI, due to MB_CREATE_GOODS_MOVEMENT limitations. It can't be called several times in the same context without commit between the calls.

If you can't put all the MM postings from an IDoc into a single material document and a single BAPI call and if you can't split the IDoc, then another option is to use qRFC queues. You can open a qRFC queue for an IDoc, put all the postings (the BAPI calls) as separate qRFC processing units and close the qRFC queue. Then you set the IDoc processing status on success. Notice that this solution is not a perfect one as IDoc status doesn't tell you that all the material documents are posted with the BAPI. It only tells that the BAPI calls were transmitted to the qRFC queue. If you like this approach, see SAP Help on qRFC Programming

I presume you are working with a custom IDoc and a custom function module posting the IDoc.

Best regards

Dominik Tylczynski

[alexandreourth]

Thanks again for your time 3a9e4ce873a94034b33dc62b0ce600ee.

Thanks for your suggestion. My problem is i don't have the budget to rewrite the code so even if qRFC is an option, i could not deploye it. I was hoping there were something easy i missed, but definitely this BAPI is not user friendly, it can't refresh his buffer itself between calls, dump when multi call, OSS note everywhere...

I would do my workaround, using the TESTRUN flag, store all the data from each call into one big internal table, then at the end if all is OK, loop on every "row", do my BAPI, COMMIT at each call. But no budget right now. They will decide.

Thanks again for your time.

Regards,

Alexandre