BAPI_GOODSMVT_CREATE with multiple material numbers and same PP order?

Question

As I know of, When you're using BAPI_GOODSMVT_CREATE at the same time(by loop or just coincidence), Using same material number puts you an error about locked object (Material XXXX is locked by USER YYYY).

But, as i know of, using BAPI_GOODSMVT_CREATE at the same time, but different material number WITH same production order makes no error.

Issue

Recently I found an error about M3/897 (Plant Data of Material XXXX is locked by user XXXX) when I'm doing BAPI_GOODSMVT_CREATE when I'm trying GI for Production order, by parallel processing, which are putting different Material number to same production order.

Question

So, I'm asking about constraint of BAPI_GOODSMVT_CREATE.

So far I know is -

A. You can't issue GI for Production Order(Mvt 261) at the same time, when you're putting same material number for different production order .

B. (I'm not sure about this) You can't issue GI for Production Order(Mvt 261) at the same time, when you're putting different material number for same production order .

Is both is right, or just A is right? Any help from experienced ABAPer or MM consultant would be appreciated!

Answer 1

To post GI in a loop you need to make commit after each run, and unlock the object explicitly, otherwise you will get the PP lock.

Try like this:

LOOP AT lt_orders ASSIGNING <fs>.
...
CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
 EXPORTING
  goodsmvt_header  = ls_header
  goodsmvt_code    = ls_code
 IMPORTING
  goodsmvt_headret = ls_headret
  materialdocument = ls_retmtd
 TABLES
  goodsmvt_item    = lt_item
  return           = lt_return.

 IF line_exists( lt_return[ type = 'E' ] ).

  CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.

 ELSE.

  COMMIT WORK AND WAIT.
  CALL FUNCTION 'DEQUEUE_ALL'.

 ENDIF.

ENDLOOP.

Always use BAPI_TRANSACTION_COMMIT with WAIT parameter or COMMIT WORK with the same after each BAPI call.

Also there can be tricky issues with the GR and implicit GI movements, see the note 369518 about this.

Answer 2

You can check the presence of existing lock at runtime using this FM - "ENQUE_READ2".

data: RAW_ENQ like LOCKSEDX_ENQ_TAB, SUBRC type SY-SUBRC, NUMBER type I.

clear : RAW_ENQ[], SUBRC, NUMBER.

add 1 to COUNTER.
call function 'ENQUE_READ2'
  importing
    SUBRC  = SUBRC
    NUMBER = NUMBER
  tables
    ENQ    = RAW_ENQ.

But if you have to prevent a failure of GOODS mvt. in general you have instead to implement some reprocessing logic to store errors.

The steps would be: Catch errors --> store bapi information or header doc number --> retry later