Repeated MB_CREATE_GOODS_MOVEMENT fails due to document lock

[former_member507569]

Hi,

I use MB_CREATE_GOODS_MOVEMENT to do a repeated goods receipt for a certain process order within a loop. After calling MB_CREATE_GOODS_MOVEMENT and MB_POST_GOODS_MOVEMENT I call a COMMIT WORK AND WAIT. Despite I get several fails due to document lock by my own user. Most of the postings get through but some always fail. How can this happen with a COMMIT WORK AND WAIT?

(Remark: program text shortened)

LOOP AT gt_sel_print INTO wa_out.

    l_tabix = sy-tabix.
    REFRESH: it_bdcdata,
             l_it_bdcmsgcoll.
    CLEAR: l_wa_mess.
    CLEAR: emkpf, imkpf,
           emseg[], imseg[],
           emseg, imseg.
    MOVE sy-datum TO imkpf-budat.
    MOVE:
          sy-uname          TO imkpf-usnam,
          c_101             TO imseg-bwart,
          wa_out-matnr      TO imseg-matnr,
          wa_out-charg      TO imseg-charg,
          c_move_ind        TO imseg-kzbew, "movement indicator
          wa_out-menge_ist  TO imseg-menge,
          wa_out-menge_ist  TO imseg-erfmg,
          wa_out-aufnr      TO imseg-aufnr,
          wa_out-erfme      TO imseg-erfme.
    APPEND imseg.

* goods receipt for process order
*********************************

    CALL FUNCTION 'MB_CREATE_GOODS_MOVEMENT'
      EXPORTING
        imkpf   = imkpf
        ctcod   = 'MB31'
      IMPORTING
        emkpf   = emkpf
      TABLES
        emseg   = emseg
        imseg   = imseg
        et_mseg = et_mseg
      EXCEPTIONS
        OTHERS  = 1.

    IF emkpf-subrc = 1.
* material movement successful:
      CALL FUNCTION 'MB_POST_GOODS_MOVEMENT'
        IMPORTING
          emkpf  = emkpf
        EXCEPTIONS
          OTHERS = 1.

      COMMIT WORK AND WAIT.

* Success message
      PERFORM fill_log_table USING '/CLA/ZZ_WM'
                                     '999'
                                     'S'
                                     text-029 "Material document has been posted
                                     l_text
                                     space
                                     space.

    ELSE. "return error of MM posting
      MOVE-CORRESPONDING emseg TO l_wa_mess.

      CALL FUNCTION 'BALW_BAPIRETURN_GET2'
        EXPORTING
          type   = l_wa_mess-msgtyp
          cl     = l_wa_mess-msgid
          number = l_wa_mess-msgno
          par1   = l_wa_mess-msgv1
          par2   = l_wa_mess-msgv2
          par3   = l_wa_mess-msgv3
          par4   = l_wa_mess-msgv4
        IMPORTING
          return = l_wa_mess_return.

      CLEAR: wa_log.
      wa_log-icon = icon_red_light.
      wa_log-message_text = l_wa_mess_return-message.
      APPEND wa_log TO it_log.
      PERFORM fill_log_table USING '/CLA/ZZ_WM'
                         '999'
                         'E'
                         text-030 "Material document was not created
                         space
                         space
                         space.
    ENDIF. "emkpf-subrc = 1

    CALL FUNCTION 'DEQUEUE_ALL'
      EXPORTING
        _synchron = 'X'.
  ENDLOOP. "AT gt_sel_print INTO wa_out to post documents

[Former Member]

hello,

Increase the wait time. May be since you are processing a lot of documents it is slowing the system.

best regards,

swanand

[former_member507569]

So you mean I should use a WAIT UP TO n SECONDS statement instead of the COMMIT WORK AND WAIT?

Of course I can do that, but why is the system not waiting until the processing of the document has finished? I thought this is the idea of COMMIT WORK AND WAIT?

[alex_campbell]

I'm not sure why this happens, particularly with Goods Movements, but what I've done in the past is put a loop after the commit work and wait, which will check to see if the lock is still in place and if so, wait a quarter of a second and then repeat the loop to try again. DoOn't forget to put a maximum number of loops, otherwise there's the potential for infinate loops if something goes awry.

Also, I would definitely not call DEQUEUE_ALL. Releasing locks should be left up to whatever module put the lock in place. If the standard goods movement FM hasn't released it's locks yet, it probably means it's still manipulating the data. Procecssing another goods movmeent before the previous goods movement has completed manipulating the data could lead to inconsistencies.

[former_member507569]

Ok, I understand that this problem is known and there is no better solution than just wait or read whether the lock disappeared (for that I can read bdcmsgcoll). Thanks for your answers!

[raymond_giuseppi]

First read Note 385830 - Inconsistencies with goods movements in the background. Why not use BAPI_GOODSMVT_CREATE or similar BAPI ?

Regards,

Raymond

[former_member507569]

That's the information I needed! Thank you, now I'm going to check the BAPI!

Best regards

Frank

[former_member507569]

Hi Raymond, or any other who knows this problem!

I now make use of the BAPI_GOODS_MVT_CREATE in the loop together with      

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'        

EXPORTING           wait   = 'X'        

IMPORTING           return = lt_return.

if no errors are returned, instead of the FM above. But it produces the same lock entry errors!

I read in a different forum that it is necessary to use

SET UPDATE TASK LOCAL.

before each bapi call, but this doesn't help either. The first posting always goes through and afterwards some do other not. What is wrong?