Skip to Content
Technical Articles
Author's profile photo Thiyagarajan Balasubramani

Reversing Goods Receipt and its corresponding Goods Issue for a Stock Transport Order

Requirement:

Recently, I came across a requirement from one of the customers to reverse the goods movements and delete the Outbound delivery created for a Stock Transport Order in a single execution via a custom program.

Below is the document flow for Stock Transport Order which is in discussion.

–> Stock Transport Order 

       –>Outbound Delivery 

       –>Goods Issue 

       –>Goods Receipt

The requirement is to reverse firstly the Goods Receipt and then Goods Issue and finally delete the Outbound Delivery.

Problem faced:

BAPI ‘BAPI_GOODSMVT_CANCEL’ is available to reverse Goods receipt and Function Module ‘WS_REVERSE_GOODS_ISSUE’ is available to reverse Goods Issue. The problem in standard is some of the data objects are not cleared at the end of BAPI call to reverse the Goods receipt. Later, when the function module to reverse GI is called, some of the include programs which are already called during the BAPI execution is also being accessed, causing the issue.

Since, the data objects are not cleared in the previous BAPI call context, FM to reverse Goods Issue fails miserably!

Solution:

  1. Wrap the BAPI to reverse GR in a custom Remote Function Module and call as Synchronous RFC and destination being ‘NONE’. Perform ‘COMMIT’ or ‘ROLL BACK’ inside the RFC based on the success/failure of BAPI.
  2. Call the function module ‘RFC_CONNECTION_CLOSE’ to close the connection which is called in above step.
  3. Wrap the FM to reverse GI in another Remote Function Module and call as Synchronous RFC and destination being ‘NONE’. Perform ‘COMMIT’ or ‘ROLL BACK’ inside the RFC based on the success/failure of FM.

Solution Snapshot:

  • The solution aims to call the BAPI and FM in a separate context through separate Synchronous RFC‘s. This will avoid processing both the calls in a single context.
  • Both the RFC’s will be called in their own RFC context.
  • COMMIT or ROLL BACK must be called inside the respective RFC’s. This will help to finish the respective LUW’s.
  • Closing the RFC connection between the RFC calls is important here otherwise you would be facing the same kind issue.

Assigned tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Sorry, I’m confused…

      You are saying “data objects not cleared” in BAPI call. If this is true (I could not find any SAP Note to that effect), then why this hasn’t been brought to the attention of SAP Support?

      BAPI should be running in it’s own LUW without any RFC and there should be COMMIT done after that. There seems to be confusion about LUW and RFC session (they are not the same). RFC call you’re describing is about a synchronous vs. asynchronous update. Not sure how this could relate to any variables not being cleared (even assuming shared memory is used). I’m guessing this would solve the issue if FM was starting too fast, before BAPI COMMIT was completed but that’s not what the blog says.

      Not sure if I missed something but the whole story doesn’t quite add up. Might want to clarify.

      P.S. Edit: just noticed "BAPI and FM are called in a same LUW" - why? That doesn't make sense... Now I'm even more confused.

       

      Author's profile photo Thiyagarajan Balasubramani
      Thiyagarajan Balasubramani
      Blog Post Author

      Hi Jelena Perfiljeva

      Read that BAPI and FM are calling in same context. hence, the FM was failing.

      The workaround is to call BAPI and FM as separate sync. RFC call. This enables the FM to be called in its own context. hence, the uncleared data objects of BAPI doesnt pose any probblem to FM.

      FM was able to clear the GI document.

      Have informed this to SAP support.  

      Regards,

      Thiyagarajan

      Author's profile photo Jeroen MARIJNISSEN
      Jeroen MARIJNISSEN

      Thanks for the blog!

      Each time you call a function, a new (addtional) program group is loaded. External called subroutines will be added to this new program group. Data between the function and the program containing the subroutine can be shared using TABLES statement.

       

      BAPI_GOODSMVT_CANCEL > FM > SAPMV45A subroutine > Program group 1

       

      WS_REVERSE_GOODS_ISSUE > SAPMV45A subroutine > Program group 2

       

      Function WS_REVERSE_GOODS_ISSUE expects that data to subroutine can be passed using TABLES statement. That isn't possible because subroutine has been assinged to Program group 1.

       

      What was the solution provided by SAP ?