Processing of BAPI_PO_CHANGE

[Former Member]

I'm experiencing problems with the following scenario:

1. change purchase order with RFC BAPI_PO_CHANGE

2. wait 30 seconds

3. post goods issue using IDoc MBGMCR01

When performing step 3, I get in 20% of the cases the error that the PO is still locked by the RFC user in the R/3 system (user PIREMOTE already processing purchase document 123456789). I have tried to extend the wait step to 10 minutes, but the same issues still remains.

I've also tried executing BAPI_TRANSACTION_COMMIT (with and without wait) and BAPI_DOCUMENT_DEQUEUE between step 1 and 2. Neither worked.

Debugging BAPI_PO_CHANGE using SE37 didn't give any results. I noticed that the PO was still locked even when the processing of BAPI_PO_CHANGE in SE37 had finished. Somehow R/3 is locking the purchase document for a very long time in 20% of the cases. During the execution of the module enough work processed are available and no jobs are running. The problem is within R/3, that's for sure, but what's the solution?

Has anyone ever experienced something like this and has an idea where to look next?

[MichalKrawczyk · Accepted solution]

hi,

1. you have to use BAPI_TRANSACTION_COMMIT after BAPI_PO_CHANGE

2. you can use IDOC PORDCH02 to change the PO (which doesn't need any commit)

3. you can schedule IDOC MBGMCR02 (just like any other IDOC) to run as long as it will be successfull (this is why we use IDOCs and not RFCs in many cases - IDOCs are persistent)

any of those 3 solution will help you

Regards,

michal

[Former Member · Accepted solution]

Thanks for your answers.

@Michal: I'm using BAPI_TRANSACTION_COMMIT after BAPI_PO_CHANGE, but the problem still persists. How can you schedule an IDoc to run until executed successful? Won't that give a problem when for example posting a goods issue on a closed PO item?

@Pragathi: I'm not looking for a way to unlock the PO in R/3. I need to send a MBGMCR IDoc to R/3 without having to worry about locked POs.

I think I have found a solution to this problem. but I'm still unsure about it. I'm using an Integration Process in PI to send to BAPI and IDoc. I now checked to box "New Transaction" in the send step and so far the issue seems to have been solved. The process looks like this:

1. send RFC BAPI_PO_CHANGE

2. send RFC BAPI_TRANSACTION_COMMIT

3. send IDoc MBGMCR01

Do you happen to know what the impact of this "New Transaction" checkbox on the processing of the BAPIs in R/3 is?

[Former Member · Accepted solution]

Problem solved. You'll have to first create a new transaction for executing BAPI_PO_CHANGE, then send BAPI_TRANSACTION_COMMIT in the same transaction.

[Former Member · Accepted solution]

Hi Iddo,

Can you help me about this comment

"Problem solved. You'll have to first create a new transaction for executing BAPI_PO_CHANGE, then send BAPI_TRANSACTION_COMMIT in the same transaction"

How can I create a new transaction?

Thanks,

Frank

[Former Member]

Hi Iddo,

How did you do the transaction creation for Bapi_po_change and bapi_transaction_commit.

Thanks in advance.

sunitha

[vijay_b4]

Hi Iddo,

You need to do this:

1) Copy the program of ME28 into z-program. and create new Txn (e.g. ZME28)

2) Remove the check where 'Output' is checked.

3) Then you can use this txn for cancellation of release after the output

Workaround option (I could not verify this as I don't have a system now). Pl try it anyway:

In the messages screen of PO, select the processed output and click 'repeat output'. A new message is created. In the date/time column, maintain '3'. This means there is a message pending for output.

Now, try to cancel the PO release. I think it works (see sometimes you can fool the system at its own game)

Reward points if this helps

Regards

Pragathi.

[Former Member]

Hi,

You Enqueue and Dequeue your BAPI PO CHANGE process.

Once your lock is released means SAP lock is released.

Then you can start your IDOC process.

Regards,