Skip to Content
Author's profile photo Wilbert Sison

Behaviour of Sales Order Save Exit in EHP7

We’ve just upgraded from EHP5 to EHP7.  I think there is an important piece of information that some customers would want to prepare for.  There’s a change  in the logic during Sales Order save which has impact on available information within USEREXIT_SAVE_DOCUMENT_PREPARE.  This exit is used to manipulate  Sales Order information before the document gets checked and saved.

Back in 2010, we had created BADI’s invoked within MV45AFZZ / SAVE_DOCUMENT_PREPARE to encapsulate some logic. In our case it’s primarily Sales Order blocking logic. These blocks, in turn, drive system and business processes around the Order. We were in an early patch of ECC 6. Now in 2015, we’re upgrading from EHP5 to EHP7. 

In our logic, we depend on two pieces of information to determine blocking information.  The first is the status of the document. The second is the confirmed quantity associated with the schedule line item. 

In EHP7, we’ve discovered that in a BAPI-create case, the status and confirmed quantity are no longer being determined prior to USEREXIT_SAVE_DOCUMENT_PREPARE.  This has impacted our existing service interface for domestic orders. It necessitated workarounds for our customer service team until we can develop new service interfaces.  All other dialog transactions like VAxx appears fine.

We raised a message to get SAP assistance  on it.  It’s just due diligence stuff.  Actually, I don’t foresee anything coming out of it since SAPNote 381348  explicitly states that the SAP maintains no responsibility for any problems in connection to user exits.  Further it said :

”No, SAP does not have to and cannot change the call of user exits. Since all possible changes in a user exit cannot be “foreseen”, SAP cannot take on maintenance responsibility for such cases. A change in a user exit is a modification like any other modification…

In fact, a change in the call of user exits due to a problem of ONE customer could also cause that MANY other customers will suddenly have problems.”

In as much as SAP does not have contractual responsibilities to assist customers in this regard, I’d maintain that SAP had the responsibility to ensure that this critical exit is invoked in the same order as before.   But I’m not confident in winning that argument.

Anyway, prepare for this. If you don’t… well… it’s sales orders. Revenue generating stuff. Let me know if you’ve encountered it. I’d like to hear from you. If you’re about to upgrade, ping me on twitter (wcsison) if you want to know more about it. I’m happy to share what our solution is.

[Edit :  This is relevant. We have GATP via APO. Depending on how your ATP Check is customized, your system will behave differently to acquire the confirmed quantity on the sales order. If you’re lucky – you may not encounter this problem.].

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Brice Lagaly
      Brice Lagaly

      Thanks for sharing

      Author's profile photo Wilbert Sison
      Wilbert Sison
      Blog Post Author

      Hi Brice, You're welcome. Hopefully it reaches relevant people so they don't get caught off guard during upgrade like we did. 🙂



      Author's profile photo Pawan Akella
      Pawan Akella

      Thanks for sharing valuable information

      It helped me a lot in saving my time from debugging

      Pawan Akella

      Author's profile photo Wilbert Sison
      Wilbert Sison
      Blog Post Author

      Hi Pawan, Thanks for the ping!  I'm glad it helped. Cheers

      Author's profile photo Varghese Mathew
      Varghese Mathew

      Hi Wilbert,

      We are also facing the same issue with confirmed quantity not being available at exit. I am interested in knowing the fix you did. Please share.


      Author's profile photo Varghese Mathew
      Varghese Mathew

      The solution to this is given in SAP note - 2146153.

      You need to do a ATP call using the below code.

      IF xvbak_updkz NE updkz_delete.
      * call Group check when processed in background mode
      USING verarb_dunkel.