Results recording not getting transferred to batch charachterstics

[former_member214626]

Hi Friends ,

I have followed following proces to transfer my RR to batch charaterstics after saving UD and stock posting with inspection type 9 but results are not getting transferred to batch :

1. Create a charaterstic in CT04 with data type NUM and char roup : Batch Characterstics status released .

2. Createed a class (type 023) with Cl01 and asigned above charc to it . :

3. Created a MIC (QS21 using the char created in step 1 .

4. Created a plan and assigned this MIC to it .

5. when recurring lot is getting generated , i m doing RR and then doing UD , stock posting . After that when i m going to MSC2N to check the values

in batch characterstics RR's MIC is not having any value .

Please help .

[former_member42743 · Accepted solution]

In the configuration, under the QM plant settings, on the tab for inspection lot completion.  Look for an indicator at the bottom that is labelled "Batch valuation without material spec".  Make sure this is clicked on.

If you don't have this indicator on, then you need to maintain the material spec in QS61.

FF

[nitin_jinagal · Accepted solution]

You may also check the scope of MIC. It should be set to 'Fixed scope' so that value gets locked after the results are entered. In my case, everything was fine still faced same problem. Overcame it after changing this setting.

Values were not flown to batch characteristics if results were not locked even if UD and stock posting was done.

It should help.

Regards,

Nitin

[former_member214626 · Accepted solution]

hi FF ,

Thank you for answer . that checkbox was not checked . If I check this checkbox will I be able to create inspection plan with MIC having link to class characterstics only or I can also add MIC to inspection plan without class characterstics ??

REgards

[nitin_jinagal · Accepted solution]

You can assign both type of MICs.

Regards,

Nitin

[former_member214626 · Accepted solution]

HI FF ,

My above doubt is solved. we can do that .

One more related question is : We can not assign a class characterstics to more than one MIC ( at client level) .

1. So do we need to create separate class charaterstics for each MIC in every plant .

2. Also if batch class and charaterstics are at client level so why we can not assign a class charaterstic to MIC if that class characterstic is already assigned to some other MIC (may be mic of same plant or other plant) .

please help

regards

[former_member42743 · Accepted solution]

You can only assign one general (class) characteristic to a MIC. I usually have the client designate a plant as the QM master data plant.  Sometimes it's a virtual plant, sometimes the largest, sometimes a corporate office site.  Maintain the MIC's in this master data plant.  You can use these MIC's in any plant.  The MIC's do not have to be created in the plant they are being used in.  I.e. you can share MIC's.

The reason you can only assign one mic to one general characteristic is because SAP said so.    Sorry, no real good answer for you on that.

The main reason I think is what if you had a class characteristic of "Brookfield _Viscosity".  Now you create a MIC 800020 linked to that.  But Brookfield viscosity is dependent on the spindle, RPM and temperature.  I can run several Brookfield tests on  given material.  What if I had 3 Brookfield MIC's to run?  Would you link them to the same Brookfield_Viscosity test?  You can't.  I'm guessing SAP felt it was just simpler to enforce this.

Plus, the settings of the General and the settings of the MIC have to be compatible.  I.e. UOM, # decimal places, interval values, etc., etc..

And since you can share MIC's across plants, it's usually not a problem.

FF

[former_member42743 · Accepted solution]

Fixed scope should not affect the transfer of results to the batch record.  What does affect them is the closing of the MIC in the inspection.  Only characteristics with a status of "5" (Locked) are considered as completed and available to transfer results to the batch.

In your case Nitin, setting the fixed scope allowed other config settings to automatically lock the characteristics for the user.  But the fixed scope setting itself has no impact on the actual transfer of values to the batch.

You must not have any of your characteristics set as "required" as you cannot make a UD on an inspection lot with unclosed required characteristics.  If you try to do so, you get a pop up asking if you want to force close the characteristics. This is typically a bad thing.  Users should never be in the habit of force closing characteristics.

Also, even on optional characteristics, users should be trained to lock the results before saving after recording values.

Personally, I don't like setting up characteristics as optional.  In some scenarios you need to. But that should be the exception. All inspection lots should have some required characteristics at the very least.

FF

[nitin_jinagal · Accepted solution]

Hi FF,

Yes you are right!! We have maintained the MICs as 'optional' since this suits well to our business scenario and users. I agree that MIC should be maintained as required if it is there in task list but as you said, this exception thing, it is very common to our scenario as we are steel manufacturing industry and inepction is done on the bais of several factors and process parameters. Number of mat codes assigned to a particular product type may be inspected differently based on grades, end use, metallurgical parameters and few other things and thus, a particular parameter or MIC may not be required to inspect for each material in a product type and vice versa.

Therefore, maintaining the char as 'Optional' and keeping the scope 'fixed' ensures that results are closed before user proceeds to UD and resuls are flown to batch values.

And as always, your content is very valuable and I would follow the same in my next project

Regards,

ntn

[former_member214626 · Accepted solution]

Hi FF ,

Thanks a lot . Can you please also share any implications of sharing MIC of different plant in inspection plan or any concerns related to same .

[former_member42743 · Accepted solution]

No drawbacks that I have found with regard to sharing MIC's across plants.  You of course have an authorization issue if you keep them in a central plant or master data plant.  But access to creating and maintaining MIC's really should be limited to a handful of people.

If you keep them in a actual working plant, you'll probably wind up granting access to other QM objects in that plant if you authorize people from other plants the ability to edit/change MICs' in that master data plant.  Some places that can be an issue.  In other businesses, its a non-issue.

But it's one of the reason I usually use a virtual plant or a corporate office plant.  Some large projects set up a virtual plant just for master data objects as other functional areas sometimes have a need to maintain master data objects or templates as well.

Other than that, I can't think of drawbacks.  Each plant can still have their own methods assigned to the MIC.

Also, be aware that you can also share all your inspection plans as well and I've had places where we create all the inspection plans in a single master data plant.  Then we just make the material/plant assignments to those plans.  This works well when you have a central QM team responsible for master data.  So, for a given product,  instead of having three inspection plans in three separate plants, you have one plan in the central plant to which a material/plant assignment is made for each of the three plants.

FF

[former_member42743 · Accepted solution]

Yes. the steel industry does propose it's own unique challenges.  I have done some work in that area.  Thank you for your kind comments.

I didn't mean to point you out or anything Nitin, I just didn't want people seeing this in the future, or the OP looking at fixed scope as the root cause for results not going to the batch record.

Thanks!

FF

[Martin_H · Accepted solution]

I took this post to do what I wanted to do for a longe time: draft a document together with the different architectures and their advantages/disadvantages. Based on this and older threads we had on this topic and some of my experiences I had so far: http://scn.sap.com/docs/DOC-46288

As this is a document it just waits for more content to be added...

Regards

MH

[nitin_jinagal · Accepted solution]

Hi FF,

There is nothing about poiniting the things , still I would say that maintaining it as 'Required' along with 'Fixed' would ease the task and like you said earlier, users do not need to be trained for locking results when it can be done automatically.

Just a thought

One more thing, Im under moderater's review and I do not know when it gets posted next. It is taking 4-5 days these days .

Regards,

ntn

[former_member214626 · Accepted solution]

Hi FF ,

Thanks a lot for your comments and help . I dont know why SAP allows forced UD and there is no standard way of making RR mandatory before UD is done (except User status ) .

REgards