Getting error while calling two BAPIs

[Former Member]

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

[raymond_giuseppi]

I check my code thoroughly, but didn't find anything in that which was wrong.

Which movement CODE value do you use, there should be a value in "CODE & is not supported by BAPI2017_GOODSMVT_CREATE"

Field GOODMVTS_CODE must exist in table T158G, which also carries a transaction code.

Regards,

Raymond

[Clemenss]

Hi varunchopra,

no need for FM DEQUEUE_ALL.

After call of BAPI_WS_DELIVERY_UPDATE make sure thre are no errors, i.e.

LOOP AT RETURN TRANSPORTING NO FIELDS
  WHERE type CA 'EAX'.
* ERROR - handle it
ENDLOOP.

The call FM BAPI_TRANSACTION_COMMIT

EXPORTING WAIT = 'X'.

Regards,

Clemens

[Former Member]

Dear Raymond,

I'm using 01 for MB01 in BAPI_GOODSMVT_CREATE, but its giving error "CODE is not supported" without any code, i.e. its not taking any code with it..also if I try to pass the coded hard codedly in the FM itself, then I'm getting error " No Items Transfered".

My observation is that..we get our control back in the application server after the processing of WS_DELIVERY UPDATE, but there is a parallel processing that is going in the database server, which doesn't allows us to process BAPI_GOODSMVT_CREATE until the database processing is complete for the first BAPI. And if we use DELAY even of two minutes its works fine.

@ Clemens,

I have already put a check on the return table of WS_DELIVERY_UPDATE. But its working fine and does not returns me any error.

[Former Member]

Dear Raymond,

I'm using 01 for MB01 in BAPI_GOODSMVT_CREATE, but its giving error "CODE is not supported" without any code, i.e. its not taking any code with it..also if I try to pass the coded hard codedly in the FM itself, then I'm getting error " No Items Transfered".

My observation is that..we get our control back in the application server after the processing of WS_DELIVERY UPDATE, but there is a parallel processing that is going in the database server, which doesn't allows us to process BAPI_GOODSMVT_CREATE until the database processing is complete for the first BAPI. And if we use DELAY even of two minutes its works fine.

@ Clemens,

I have already put a check on the return table of WS_DELIVERY_UPDATE. But its working fine and does not returns me any error.

[Clemenss]

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

[Former Member]

Hi Clemens,

Its actually the BAPI WS_DELIVERY_UPDATE which is creating a Goods Issue for the Delivery and this delvery being done against a PO so it locks the Purchase Order for further updates as per the GI being done, and it is the one which is taking time to process .

So Thanks, now I have put a WHILE loop as per the code given by you, which is checking for any locks in the PO. So now it won't process further until the PO is free. Atleast, I got a solution to rid of the DELAY put in the code.

I have also raised an OSS to SAP regarding the same. Waiting for them to reply on, why the WS_DELIVERY_UPDATE is taking time to process.

Thanks Again Clemens, Hence closing the post.