Getting error while calling two BAPIs

Question

Dear ABAPers,
I'm stuck into a problem.
I have a situation where I'm using BAPI, WS_DELIVERY_UPDATE to update a delivery.
Then after this I have post a GR so for that I'm using BAPI_GOODSMVT_CREATE.
Now my problem is when I'm calling BAPI_GOODSMVT_CREATE it gives me an error
"CODE is not supported by BAPI2017_GOODSMVT_CREATE". I check my code thoroughly, but didn't find anything in that
which was wrong.
Again, if I try to do the same, in debugging mode, its processes me in the way it should, without any error.
Also, If I use a hard coded DELAY of 2 mins, in my program after WS_DELIVERY_UPDATE, it again processes perfectly.
Now I've put COMMIT AND WAIT and FM DEQUEUE_ALL after WS_DELIVERY_UPDATE, but still not working, and this I'm getting
error from BAPI_GOODSMVT_CREATE - "No Items Transfered".
Please help me sort this issue.
Regards,
Varun

Answer 1

Hi varunchopra,
the SAP documentation is not 100 % clear here: They say, with COMMIT WORK all high-priority ("VB1") update function modules are executed in the order of their registration and in a shared database LUW.  With WAIT addition, the calling program will continue after the update work process has executed the VB1 function modules.
Probably BAPI_WS_DELIVERY_UPDATE will also trigger one or more VB2 update functions that will keep the objects locked.
Ten years ago we used this code in a similar situation to wait for the update task for a material being changed:
FORM WAIT_UPDATE.
  USING P_MAX_WAIT_SECONDS TYPE I
  CHANGING P_SUBRC LIKE SY-SUBRC.
  DATA:
  L_ENDTIME LIKE SY-UZEIT,
  L_TABIX LIKE SY-TABIX,
  L_TRIES TYPE I,
  L_SUCCESS LIKE SY-SUBRC,
  L_ANSW TYPE C,
  L_TRY_AGAIN LIKE RMCLS-XFLAG VALUE 'X'.
  GET TIME.
  L_ENDTIME = SY-UZEIT.
  ADD P_MAX_WAIT_SECONDS TO L_ENDTIME.
  WHILE L_TRY_AGAIN = 'X'.
    LOOP AT ITAB.
      PERFORM CHECK_LOCK_EMMARCE
        USING ZAUF-WERKS ITAB-MATNR CHANGING P_SUBRC.
      GET TIME.
      IF P_SUBRC <> 0 OR SY-UZEIT >= L_ENDTIME.
        EXIT.                          "Loop
      ENDIF.                           " sy-subrc = 0.
    ENDLOOP.                           " AT itab.
    IF P_SUBRC = 0.
      CLEAR: L_TRY_AGAIN.
    ELSE.
      IF SY-UZEIT >= L_ENDTIME .
        PERFORM POPUP_TO_CONFIRM_WAIT
          USING P_MAX_WAIT_SECONDS CHANGING L_ENDTIME P_SUBRC.
        IF P_SUBRC <> 0.
          CLEAR L_TRY_AGAIN.
        ELSE.
          CLEAR P_SUBRC.
        ENDIF.                         " p_subrc <> 0.
      ENDIF.                           " sy-uzeit >= l_endtime.
    ENDIF.                             " p_subrc = 0.
  ENDWHILE.                            " l_try_again = 'X'.
ENDFORM.                               " WAIT_UPDATE
The coding of CHECK_LOCK_EMMARCE was derived from SM12 lock overview and used FUNCTION 'ENQUE_READ'. Today I would just try to lock the object with ENQUEUE function - if you get foreign lock error, the updatze task lock is not yet released.
Monitor SM12 during test run to identify which lock object  must be checked.
The you have to decide: If you put a WAIT UP TO 1 SECONDS in the wait loop, you may lose up to 1 second per delivery. If you just LOOP until the locks are released you may put some non-necessary load on the machine.
This way will be faster than any unconditional wait - which may sometimes not be long enough.
Regards,
Clemens