RFCs sequence from MII to ERP

Question

Hi!
MII 12.1.7
Inside one transaction there are 3 JCo Functions, calling SAP native BAPIs, following strictly each other:
1. Consumption of material by the Production Order
2. Material issue from the Production Order
3. Confirmation of the Production Order
Each call have the same schema: Start Session - Function - Commit - End Session. The properties of Function and Session actions are default (RFC Type = Best Effort, Processing Type = Synchronous Processing, Pool Connections = true)
When MII makes Confirmation BAPI call it returns error that order is processed by MII user, despite that previous BAPI call was succesfull and returned correct data. The same error occurs if I try to put all Functions inside one Session block.
Another case: when first BAPI creates Planeed Order and second creates Production Order from planned one - second BAPI says that planned order ###, that was returned by first BAPI, does not exist.
I solved this problem only by putting Pause action between these calls, but I hope there is some better way to deal with this problem. Is there?
Is there any way to force next BAPI  to "wait" untill data modified by previous BAPI will become actual in ERP and not blocked by MII itself? Can it be managed with Function and Session properties?
Thanks!
Best Regards
Petr

Answer 1

3 points that could help here-
1) To reduce locks in Material Movements-
Try testing with transaction OMJI (test with 'Late exclusive lock'
settings)
  Notes 70865 and 322989 contain interesting information on locks in
  MM-IM. Transaction OMJI allow to set a late exclusive lock in order
to reduce the time that the material master data is locked.
2)
You could also automate the goods movements and post
Everything you are doing here with the confirmation posting via
backflush and auto Goods receipt.
When goods movements are posted linked with a confirmation they are what
We Call de-coupled. This means they get posted seperately to the confirmation
In the update task, Note 208477 explains this about the decoupled process.
It is very common to get locks during goods movement processing and the error
Handling of confirmation handles this eliminating the need for any manual
processing, a regularly scheduled run of the program
CORUPROC clears up any errors that arose out of lock situations.
There is settings for when the movements are updated set in the process control
Assigned to the confirmation parameters in transaction OPK4, the definition on the
Type of processing is transaction OPKC however these have no effect with bapi
Postings (back to note 208477)
Also different processes such as batch determination,classification and derivation
can slow down GM postings, if the runtime due to these occuring during GM posting
is an issue try to perform it in the order (see production schediling profile OPKP/CORY)
3)
Use the wait parameter in the commit bapi BAPI_TRANSACTION_COMMIT
and ensure to commit after each bapi call.
Kind Regards
Eoin