cancel
Showing results for 
Search instead for 
Did you mean: 

Batch status disappearing after taking the UD (QA11)

Former Member
0 Kudos

Hi Experts,

We are facing the following issue (ECC6.0 EHP5 with no enhancement activated):

- when the UD is made for the IL created at GR from purchase order (origin 01), the batch status initially set at GR (Q) is cleared; same time the UD for the IL is recorded and kept correctly (UD has the new status)

- when this UD is changed for the same IL, the batch status is getting updated with the new status; the UD for the IL is correctly updated, too.

We have implemented the note 1687321, but the problem still persists.

Has anyone of you faced the similar problem? Any hints where to look for the root-cause?

I've checked the user exits for batch update and QA11 (based on forum posts), but they are not called at making UD or they have correct values.

Thanks for help,

/J

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Late reply but maybe some would find it helpful.

We have implemented SAP notes 1671652 and 1634699 and they solved the problem.

Regards,

Jacek

Answers (1)

Answers (1)

former_member42743
Active Contributor
0 Kudos

I'm not sure i understand your problem. It appears the batch status is updated each time you make or change a UD. Isn't that you want?

The batch status is either Restricted or unrestricted. So I'm not sure what you mean when you say the batch status is disappearing.

FF

Former Member
0 Kudos

Hi,

Sorry for messing up with the terminology. I meant usage decission characteristic value.

UD made with QA11 => UD value is removed from the batch characteristic (LOBM_UDCODE)

UD changed with QA12 => UD value is updated (updated value of LOBM_UDCODE)

/J

former_member42743
Active Contributor
0 Kudos

Ok.. maybe another issue with terminolgy.

If you are using QA11 to make the UD, how can the value of LOBM_UDCODE be removed if the UD hasn't been made yet?

Doing the QA12 should update the LOBM_UDCODE with the new value. It sounds like that is working fine.

So the issue sounds more like why isn't the initial UDCODE being populated? Since this is an SAP provided characteristic, there isn't really anything you can do to fix this if it is a problem.

The only thing I can think of is that the batch is somehow locked or something that prevents the batch update. Do you have any followup action accessing the batch when the QA11 is done?

If you go to MSC3n and go to the classification tab, the second icon in the middle of the screen should be a "display change documents" button. This should show you when the LOBM_UDCODE value is created, updated, etc... It might shed some light on the problem.

FF

Former Member
0 Kudos

Hi FF,

I think we are on the same page with terminology

Indeed, our process is a bit "enhanced" I would say. When doing the GR from purchase order, the batch characteristic LOBM_UDCODE is pre-filled with the UD of "Q" (LEANQM1 Q) whereas the IL created upon packing of HUs has no UD.

Then, when user makes UD for this IL, the pre-filled UD on batch level should be changed to the UD user made. It is not and the value disappears. I've run some checks on the ABAP code and the issue seems to be caused by the VB_CHANGE_BATCH used in the MQEVAF40 in form charge_klassifizieren. When the initial UD is made (QA11), the internal table for this f-n module has only the new values the batch classification is to be updated with. When the UD change is made (QA12) - both new and old values are provided. If I change the internal table values to include old and new ones for the initial UD, the process works correctly (batch LOBM_UDCODE is updated with new value).

As we are upgrading to ECC6 EHP5, I've compared the flow to the ECC5 and the values provided to VB_CHANGE_BATCH at initial UD (QA11) are the same for both systems. The process works in ECC5. As result, we have created the OSS message.

In MSC3n changes to the batch characteristics are visible from change docs - and the log is kept for QA11 and QA12. For the removal of LOBM_UDCODE it displays "deleted" values, and for QA12 it shows "created" values. In other words - change logs are working correctly.

Once SAP responds to OSS message I will update this tread. Any ideas appreciated.

/J

former_member42743
Active Contributor
0 Kudos

That actually makes sense. The SAP is expecting the code being deleted from the batch to be in the selected set being used for the QA11 decision. If I've understood this correctly, the UD code "Q" is not in the selected set used in your QA11 UD.

You could confirm your "bug" easily by adding the UD code "Q" to the selected set being used in QA11. Maybe in a sandbox system.

Sounds like you need to find out from SAP why they now enforce that logic in 6.0 when they didn't in 5.0. Is there a reason that you need to be aware of? Was it done to fix some other bug?

Looking forward to hear the solution.

FF

Former Member
0 Kudos

Hi FF,

I ran the same test you suggested after posting the message. When the UD code in IL is set to Q and is the same as UD code at batch level, the UD code remains not changed. Interesting thing is that change documents are not showing any record for QA11 (making UD).

I wouldn't be surprised SAP corrected the functionality in 6.0. We have seen already this type of corrections (not flagged in the 5.0 to 6.0 delta system comparison) i.e. corrected process of confirmation control keys usage for receiving (for HU managed storage locations).

We will update the message and let's see what SAP responds.

/J

former_member42743
Active Contributor
0 Kudos

My thought was to just include the "Q" in the selected set. Then run QA11 as you normally would and select a normal UD code like "A". Then the "Q" should be deleted and replaced with "A" in the batch.

FF

Former Member
0 Kudos

The "Q" is already in the selection sets.

/J

former_member42743
Active Contributor
0 Kudos

Ok. One last possibility I can think of. When you pre-populate the UD code value, what exactly are you putting in there?

The number of spaces is critical to it.

FF

Former Member
0 Kudos

Hi,

the spaces and values are correct.

This solution works without any problems in ECC5. The issue started appearing after we did the upgrade to ECC6 EHP5.

/J

former_member42743
Active Contributor
0 Kudos

FYI -

It was easy enough to set this up and test.

It works OK in ECC 6.0. We do not have the EHP package.

FF

Former Member
0 Kudos

Thanks for the test!

2 options left:

- EHP added someting that is changing the way program works (nothing is activated in IMG, but I saw some enhancements being called from f-n module while debugging)

- one of modifications we have in the system is not behaving correctly, but is very unlikely as in the debugging I haven't seen any data change/manipulation. The change is happening after first commit (save IL) and not in any follow-up actions.

Let's wait for respond from SAP.