Skip to Content

Reversal of Usage Decision and Stock Posting of Inspection Lot

Dear all,

Everywhere we will face a common issue of GR Reversal of Purchase Orders / Production Orders are not possible, If Quality Inspection Lot is approved and the stock posting has been made from Quality Inspection to Unrestricted Stock.

Here is the standard solution for the reversal of UD and reverse the stock posting of Inspection Lot. Please think about the intended user group of this report. Check the comments below this document for details.

1. Open the SAP Note 175842 – Inspection Lot: Reversal of goods movements from UD as below from SAP market place.

    If you scroll down, there will be a correction instructions available at the bottom. There click on the correction note number 298389.


2. If you click on that correction instruction, the sub note will open. There again you scroll down, there will be object description for the object RQEVAC50.


3. The corresponding program code will open as below.


4. With the help of ABAPer, copy the code and create a Z Program in your system.


Note: you might consider adding additional fields and/or an authorization check, based on your intended user group.

5. Assign a T Code for this program and execute. The input field will be Quality Inspection Lot. Enter the Inspection Lot Number and Execute.

    You will get a success message as below.


6. Inspection Lot Status after UD and Stock Posting Completion (UD  ICCO  SPCO)


7. Inspection Lot Status after reversal of UD and Stock posting. (UD ICCO SPRQ)


8. Stock Posting can be done again, or GR of the Purchase order can be reversed, since the material is available in Quality Stock.


9. Reversal Accounting Document Details are available here. Reference Type 7 is for reversal of Quality Stock Posting.


10. There is small configuration also needed along with this.

     That is Go to OMJJ Transaction for 322 Movement Type and go to allowed transactions and add new entry for T Code QA11 as below.


Hope this will help the users a lot.


You must be Logged on to comment or reply to a post.
  • Hi,

    This document is pretty useful for users who do not have have access to market place. Getting codes would definitely help in creating the reversal program.

    Keep sharing.


  • We have to be very careful about how OSS notes are included in blogs.  I had to ask Vinodh to remove the actual program text in the attached file.  We can't actually include the notes.  Documents also should not be a repetition of what are common activities unless you can add some added info that is not readily apparent.  For instance, downloading of an OSS note would not suffice for a document.  This document does show the related config step though as well.

    We need to include extra notes into documents so that they are not just a series of screen prints or info already generally available in help files or SCN discussions.

    It should also be noted that this does not support reversal of lots using HU's or serial numbers.  There are several other disclaimers that SAP includes in the note.  It would be good to include the key ones in the document itself.

    This includes the SAP statement that this functionality should NOT be made a part of the standard business process.  I.e. every time a mistake is made, the first option is to run this program.  This program should only be capable of being run by one or two people, (probably IT people), and only after getting approvals from high level management.  The reason being is that if the program becomes part of the daily lives of people, the underlying, root causes for having to run the program are never solved.

    Ideally, BEFORE this program is run, a quality notification, (internal problem), should be created.  Following necessary approvals and execution of the program, the notification should be then be used for an investigation as to why it was necessary to run the program and what remedial actions are to take place to prevent it from happening again.

    More often than not, the need for this is caused by human error which could require retraining, process change, extra checks, a customization, etc.. or several of the above.


    • I am not so much into the SAP basic administration, but shouldn't one import things like this via SNOTE, instead of just copying the program code into a Z-Report? At least the screenshot of the correction note with the "Insert Block" would indicate that.



      • I'd have to check on this type of note Martin.  I don't believe there are any corrections in this note.   But yes, normally you should go through SNOTE to add any notes to your system. 

        I don't know if by using SNOTE, since this is basically a standalone report, if the program is actually created for you or not.   I don't use SNOTE much as at most clients they wouldn't let me.   I did use it at my previous client however for a few notes.

        Good question.


        • As I said I have rarely used SNOTE to implement stuff myself, but at least what I have experienced is that  common practice is to load down the note details via SNOTE for all notes. This has also the effect that other system administrators are able to track who loaded down the note and which notes have been downloaded so far.

          On this note in detail it is a bit difficult to state: on the one hand the note text itself states "create an executable program and insert the attached source code", on the other hand there is a correction instruction attached to the note that has the typical sections for an automatic code creation included.



        • No.  The only code in here is the code in the screen print.  It's not enough to allow you to copy the code and recreate it in your system.  You'd still need more coding than what is seen in the screen print.

          Typically, we don't share SAP code here.  In the ABAP forum and other areas you will see coding but it should only be user created coding, not coding done by SAP.  You also need to make sure you have the official permission of the company that the code was written for in order to publish it here.

          We discussed this email earlier in a previous response.


  • Hello,

    This program posts the reversal document using the system date.

    I created a variable called "postdate" and inserted the following code so the system uses the date of the original UD movement.

      SELECT SINGLE budat_mkpf INTO postdate FROM mseg WHERE

        mseg~mblnr IN ( SELECT mblnr FROM qamb WHERE qamb~prueflos =

    prueflos AND qamb~typ = '3' )


        mseg~mjahr IN ( SELECT mjahr FROM qamb WHERE qamb~prueflos =

    prueflos AND qamb~typ = '3' )


        mseg~zeile IN ( SELECT zeile FROM qamb WHERE qamb~prueflos =

    prueflos AND qamb~typ = '3' ).

    and I changed the following code which was using system date:

      l_imkpf-budat = postdate.

    Besides from that issue, what is your solution for materials with serial number profile? This program doesn't allow for such operation.

    Best regards,


  • I understand that the the reversal does not include the possibility to record results again for the inspection lot, right? So if a user wrote wrongly the results and the usage decision is performed this fix does not solve it. Is this correct?

    • That is my understanding to Maria.  The note primarily is used to bring teh stcok back against the lot.  It might be possible to reset the characteristic in results recording and change the value but I can't say I've actually tried it.


    • You can change the results anytime (provided they are Long term MICs). This correction doesn't make a direct impact. Yes this is to reverse the stock into QI but change in result recording is a different matter and can be performed anytime for Long term MICs irrespective of the UD/ SP status.


          • hii Nitin ,

            we can use QEVA0008 exit and add function module CALL FUNCTION 'QAST_PROCESS_ACTIVITY' in it . by doing this we get a customer function button enabled in the UD screen which we can use to Chabge the UD Code as well as the results .

  • Sumit Gupta

    I do not agree with your additional comment in the last version of this document. This report is not intended to be used by a greater amount of persons in a company. Therefore the additional fields are not required. In opposite they might cause issues when SAP releases a newer version of the note.

    Craig S Nitin Jinagal

    What is your opinion on this?

    • My feeling hasn't changed since my comment on 14Jan2014.  This program should not be used by the general user community as it leads to overuse and a lack of investigation into root causes.

      On the other hand I wouldn't say it's a bad idea that Sumit added.  Especially in a global instance.  You might have plant level IT support allowed to run the report or maybe local QA people.  Or you might have global  IT support centers responsible for executing the report.  In either case, validating authorization for the plant and user isn't a bad idea.

      If I was forced to allow this program to be used on a more widespread basis than I like, I would probably take it even a few steps farther.  I might require the user to enter in some long text regarding the need and necessity to run the program. Or require them to enter in a reference number that would allow documentation of the issue.  (SAP Notification number, Trackwise number, help desk ticket, etc..).

      That would all be then documented in a change control record in a Z-table maybe, that can then be reveiewed and checked to see the who, what, when and why's.

      As far as future versions of the program, the key would be how the program is done that is tied to the Z transaction.  You should be able to call the SAP program and submit the job as a BDC with from your own Z-program.  That way you wrap all your checks and balances around the call to the SAP program.

      Yes a future change to the SAP provided program might fail because some screens or paramters change but you only need to redo your own program to allow it to execute the new program.  You wouldn't be rewriting the SAP program.  So it might work just fine without any changes.  Yes, I wouldn't make custom changes to the actual SAP program.

      So I wouldn't place my program changes in the SAP program, but in my own program that wraps around the SAP program and calls the program and probably executes it ultimately as a BDC session.


    • Hi Martin

      I can't track the additional comments made in the last version and thus, cannot really comment on that but after looking at your text and Mr Craig post in this, I believe that changes are never appreciated in the standard program. Some part of the note states that any logic of the standard program must not be modified as this might bring inconsistencies with system status or inspection lot quantities or material docs etc.

      My previous client had done bit modification and gave the posting date field in the selection screen. As a result, users were able to make back date postings. Not a right thing to do! 

      As far as the number of users for handling this program is concerned, I agree with Mr Craig and will definitely go in a controlled manner because sometimes, you really have to give access to more than one user. Also, adding a field to mention a reference number to run the program is wonderful approach and I will also go one step ahead in linking the Employee Id for the cases where a common user id is shared by more than one person.


  • Hi Vinodh,

    Great helpful document you have provided ,

    Today I have practiced the steps in IDES with help of ABAPER and able to reverse the stock from UR and modify the UD.Found short term MIC change in Result recording not possible.finally ZUDREVERSAL 🙂

    Keep postings,