Interacting with many different customers along last 12 years of experience, I noticed there are recurrent issues when using BAPI_GOODSMVT_CREATE to post goods receipt.
One example is to receive stock in transfer via BAPI by posting movement type ‘315’. Suppose here, BAPI is being called multiple times and, as a consequence, allows receiving quantity more than the stock in transfer.
Why does it happen?
Read the following Wiki documentation to get further details:
Goods Movements with BAPI
This document explains how to call the BAPI BAPI_GOODSMVT_CREATE several times within one roll area.
As stated there, when you want to post depending Goods Movements in a series like a goods receipt and then, immediately afterwards, a transfer or a new receipt and issue for the same material, you need to consider the stock is read only from the database in the case of an actual goods issue.
For a goods receipt, the data is read from the buffer and thereby at the time before the last posting in the same roll area. A goods receipt, for example with movement type 315, automatically posts an implicit goods issue in the stock in transfer. This situation is not taken into account in the current design. You may get an error message like ‘M7 021 - Deficit of ... stock’. To avoid this, you have to call the BAPI in a different way, as mentioned on the note 369518:
“Make sure that the program buffer is deleted by changing the roll area. You can accomplish this by logging off and then logging in again for the BAPI process. If the BAPI is called from an ABAP program, you can also use the command: CALL FUNCTION func DESTINATION 'NONE'.”
In addition, take into account the impact of ‘COMMIT WORK’ and ‘ROLLBACK’ commands. BAPI_GOODSMVT_CREATE is used to create goods movements. The ‘COMMIT WORK’ command, which triggers the actual update of the document to the database, is performed in the calling program. In the case of an error during the posting, a ‘ROLLBACK’ work should be performed in the calling program. If this is not performed the underlying object (purchase order, material etc.) referenced in the failed goods movement will remain locked until the program is finished.
This will cause locking problems if other user/programs try to access this object while the program is active. Take into account that the enqueue for documents is at header level, so the complete document is always locked, even when a Goods Receipt for a single line item is being performed.
If a ‘COMMIT WORK and WAIT’ is performed, the dialog work process waits until the update has been performed before continuing. This can negatively affect the overall runtime of the transaction/BAPI.
You should review the coding after the call to the BAPI_GOODSMVT_CREATE (also for other BAPI’s) in your transactions ‘Z-transactions’. It needs to be analyzed in details to see if a sufficient error handling logic (with a ‘ROLLBACK WORK’) has been implemented and how the ‘COMMIT WORK’ is triggered. Often the BAPI BAPI_TRANSACTION_COMMIT is used to perform the COMMIT, however notice if this BAPI is called with the parameter ‘WAIT = X’, then a ‘COMMIT WORK and WAIT’ is performed.
Note: this cannot be seen as a general recommendation for all programs, each ‘Z-transaction’ needs to be analyzed individually. For example, if the program needs to immediately perform an additional goods movement for the same stock, a ‘COMMIT WORK and WAIT’ is necessary.
As I mentioned, you should consider the approach described on the note 369518 to ensure that each BAPI call is done in a separate roll area then you should have no problem with buffered data being used.
Check also the following note:
187687 - BAPI_PO_CREATE and Commit Work
I hope this info can be helpful to SCN Community!
Kind Regards,
Fábio Almeida - MM Support Consultant
