QA32 - Incorrect selection

[Former Member]

Hi,

For some reason I am getting erroneous results while running QA32. While running the transaction I select 'Inspection lot without a usage decision':

When I execute I can see an inspection lot for which usage decision has already been made:

An idea why this happens? Your responses will be highly appreciated.

Thanks a lot

Regards

Snigdho

[former_member42743 · Accepted solution]

I personally haven't ever seen that situation.  But it could be related to a status inconsistency.  You don't indicate if this error is happening with a whole bunch of lots, or just the one in your screen prints.  I suspect it's only the one lot.

A user reported some thing similar in a discussion this week.  You might have the same root cause.

See this:

For the lot in questoin in your screen prints, check to see if field QALS-STAT35 is set.  If it has an "X", it thinks the UD is made.  If it is not set, it thinks the UD is not made.

So if the status of the lot shows a UD status, the field QALS-STAT35 should have an X.

When no UD status is not active, the field QALS-STAT35 should be null.

When these are not consistent with each other, you have problems.  The type of problem you have depends on how the programmer wrote the code and whether the section of SAP code is looking at the status, (i.e. UD form the JEST table) or the QALS-STAT35 field.

Craig

[Former Member · Accepted solution]

Hi,

This happens when I forcefully close results recording without capturing all data for each sample. When I forcefully close results and assign UD - this error comes.

Thanks for your help.

Regards

Snigdho

[former_member42743 · Accepted solution]

Did you check the various fields I suggested you look at?

Craig

[Former Member · Accepted solution]

Hi Craig,

You are right. Upon closer look I found that STAT35 is not marked as 'X' although the UD has been made. Why this happens? This is standard SAP am dealing with. Any suggestion?

Thanks

Snigdho

[former_member42743 · Accepted solution]

No, i don't have the answer as to why it behaves that way.

But I would search OSS for an SAP note on this.  I would try using QALS-STAT35 as a search parameter in  your search.

If  you don't find anything about it there, I would submit it to SAP to look at.  I think you have good info to give them.  1) it sounds like you can recreate the problem, 2) you know the symptoms of the issue 3) you know technical field and values that are in error.

With that info, they should be able to figure out what code needs to be fixed and possibly provide a patch for it.

As an alternative in the meantime, you could create a special program do find these problem inspection lots and update the QALS-STAT35 field directly.  It's not normally recommended to update tables directly but in your case, this might be a time you can successfully do so.

Craig

[Former Member · Accepted solution]

Hi Craig,

Thanks a lot for the quick response. The good part is we know the symptom, and the bad part is recreating the problem. I have faced this issue twice till date. The first time I had forcefully closed the inspection characteristics. I thought that might be the reason. However second time, I had carefully captured all the results and closed the characteristics normally and still faced the error. I think there is some other issue which I am not aware of.

I will post a message to SAP and wait for their response.

Thanks again for your help. I really appreciate it.

Snigdho

[former_member42743 · Accepted solution]

Please let us know if SAP provides any info, (or if they don't!).

Craig

[Former Member]

Sure - will keep this thread open!

[Florian]

Maybe you can run your Transaction again with ANST after you can rebuild the example.

Just in case you do not know about it -->

~Florian

[Former Member]

Thanks Florian,

I will try this.

Meanwhile I was searching SCN on similar issue. I found this:

I do have an enhancement following the UD and it does have one COMMIT statement. We have removed it and testing again.

[Former Member]

Hi all,

As stated in my last post, we removed the COMMIT statement from the enhancement that followed the usage decision. After that I haven't faced this issue (touchwood ).

  I am closing the thread here - this was an indeed good learning!

Thanks all.

Regards

Snigdho