Inspect with TL and Material Specification - Side effects of COPY

[Martin_H]

Current situation:

• We have two inspection plans (one for plant A, one for B) and one material specification. The material is assigned to both inspection plans with the applicable plant.
• The two inspection plans for the material are not identical as the MIC are different (say A1, A2, B1, B2). We are using reference MIC in order to easily be able to adjust them.
• In the material specification we are setting the values for all the four MIC (A1=x, A2=y,...).
• Both inspections (for TL and for MatSpec) are active in the material master for the relevant inspection type

Issue:
As the material specification is not plant specific we now face the following situation when an inspection lot is created for plant A:

• IL is generated based on plan A and MatSpec
• All MIC that are specified in the plant A inspection plan (with sampling procedure) and are detailed in the MatSpec are fine in IL (and have a correct sample size) (MERGE)
• All MIC that are specified in the plant A inspection plan and are not contained in the MatSpec are fine as well
• All MIC that are specified in the plant B inspection plan are not relevant for this inspection (as plan B is not considered) --> which is correct
• However, as they are specified in the MatSpec, they are added to the IL as well(COPY). And even worse: as they are only in the MatSpec they are added with a sample size equal to the lot size. This is really unwanted *g*

The same of course happens vice versa when creating an inspection lot for plant B. I know that this is a "system works as designed" thing (the picture on http://help.sap.com/erp2005_ehp_06/helpdata/EN/2d/350fff448c11d189420000e829fbbd/frameset.htm shows this really clear), but I am trying to find some alternatives for this issue...

Possible solutions:

I cannot set the values for the MIC in the inspection plan as we are using reference MIC. One idea that came to my mind is to somehow prevent the system from doing the COPY step, and only allowing to do MERGE. As this would then have to be steered on a case by case basis(e.g. through an attribute in the plan?) it would definitly require some programming (user exit QMCF0001???).

Does anyone have another idea how to solve this issue or some idea for another setup?

Regards
MH

[former_member42743 · Accepted solution]

The problem I would first ask is why are you using two different sets of MIC's?

If you used one set of MIC's you wouldn't have the issue at all.

I have had this discussion with many clients over the years.

It is usually my first "battle" with the plants on an implementation.  To come up with a single list of tests performed by the company across all plants with no duplicate listings of tests.  I typically define a "test" by method, UOM, and number of decimals.  Method here means the process used, not necessarily the method number used by individual plants.

The second battle is the spec for a material.  You can't make a material in multiple plants and use two different specs.  I know there are a few gray areas and some exceptions here and there, but generally, if the final specs aren't the same, it's not the same material.

MIC's are a plant specific item but they can be shared across plants in inspection plans .  And plans themselves can shared across plants.  Especially when batch managing materials, you should create all the MIC's in a central plant, or even a virtual master data plant.  That way, every test only appears once in the system.  Specs are then set in the batch class, or material's classification view which then of course get automatically copied to the material spec and then to the inspection lot when created.

In my "ideal" company, we also have only one set of plans per usage as well that are maintained centrally in a virtual plant.  We then simply assign other plants materials to them.

FF

[Martin_H · Accepted solution]

There is nothing to add except the fact you probably know: sometimes you make the proposal but not the decision(or you arrive at the site and the setup has already been done)....and then you are where I am now: finding a solution for this "not so ideal" situation.

There are always two ways: the "easier" way - keeping the stuff and technically solving it (most time not good but as not much work required on business side mostly preferred) and the "right" way: cleaning up the MICs...

Regards

MH

[former_member42743 · Accepted solution]

Martin,

I totally sympathize with you your position. Believe me!  I've been there!

Unfortunately, I don't have a good answer for you.  The design you have is, I think a good basic design. The flaw of course is the multiple MIC's across plants as you already know.  You inherited a flawed design.  Any development to make a work around to this is probably going to be costly and could impact future upgrades.

That said, there is one enhancement that you might look at that could possibly help you.  QMCF0001is an exit that is called (according it it's documentation), if either indicator, inspec by spec or inspec by config is ticked on when the inspection lot is being created.  I don't know if that exit will allow you a way to remove the unwanted MICs' for the given inspection lot or not.  I have never used it so i have no first hand knowledge of it.  I just saw it in my list of exits and read the documentation.  In the table T_QMSP_SPECTAB you might be able to delete the unwanted plant MIC's.  But I don't know if that is possible or if this is called before merging it with the task list or after.

My first preference of course would be to push back hard on the client to fix the basic problem since that is the "right" thing to do.  And to be honest, i don't think it would be that difficut, especially if a plan was made to address this over time.  I.e. fix the 10-20% of the materials first that make up 80-90% of the production. 

FF

[Martin_H · Accepted solution]

Fire Fighter wrote:
(...)
My first preference of course would be to push back hard on the client to fix the basic problem since that is the "right" thing to do.  And to be honest, i don't think it would be that difficut, especially if a plan was made to address this over time.  I.e. fix the 10-20% of the materials first that make up 80-90% of the production.  
FF

I always tell that "working around the system" is not a good idea and will result in later (bigger) issues most of the time. This is why I will definitly push for the "right" solution: harmonizing the MICs.

However, we all know that sometimes these technical solutions are unavoidable and then already having evaluated further options is something a good consultant should have done before (if you don't have to put them out of the drawer - even better!).

Regards

MH

[former_member42743]

Separate side issue:

Are you batch managed and using batch classes?  If so, why are you unlocking the MIC's in the material spec instead of either in the class or in the material master classification veiw?

FF

[Martin_H]

We are having some materials batch managed (not all), but we are using one batch class globally. Has a lot of advantages but I would assume that this does not play very good into specifying the MIC in the batch class(es).

Specifying the specs in the classification of the material master: I have not done that before but could think that we might have the same problem here as with the MatSpec: as long as the MICs are not harmonized they would appear in both inspection lots, right?

MH

[former_member42743]

You are correct. It does not resolve the MIC issue.

I'm sure you probably know this already but using one global batch class is very much not recommended by SAP. There are a couple of OSS notes on this.  It does of course depend on how you use batches. 

But using one global class can lead to excessively long batch selection times if you are using any batch search strategies of FIFO or similar picking strategies. 

It can also cause excessively large tables with many unused records.

SAP has indicated in the past that classes with more than 60-70 characteristics can cause performance issues.

FF

PS> you did see my response above as well?

[Martin_H]

We are having only very few batch class attributes...so actually i is working quite well currently. Nevertheless, I did some searching at the service marketplace, but could not locate the notes you are mentioning (I found 1318048, but this is not applicable since we do not have many attributes). Can you point me at the relevant keywords or the SAP notes? Specially the large table issue I would then forward to the basis team for monitoring.

MH

[former_member42743]

At my current client I don't have an OSS account so I can't search for you and I didn't download those particular notes at the time.  It's been a few years since I was working on them specifically.  You might look under the terms "performance" + "batch search".  That would be my first query. 

As far as tables, the main impact is on table AUSP.  This contains the characteristic values.  As soon as a batch is classified, an entry is made in AUSP for every characteristic assigend to the materials batch class.  So in your example, with just 4 mics, two for plant A and two for plant B, you would have four entries.  If these were the only MICS you utilized, you would have a 100% increase in the number of entries in the AUSP than what you actually use.  I've seen clients with a global batch class with only 40-50 batch characteristics in it but for any one material only 6-12 are actually used for a given material.

If you make 1000 batches a year, that would be 40-50,000 records in AUSP.  In a small one plant facility, probably not an issue.  But for a multi-plant company with say 10-15 plants, making a total of 15-20,000 batches a year, it could mean up to 1,000,000 records a year.  Of which only maybe 200,000 are actually utilized.  In just a few years AUSP can quickly grow.  And this is just batch records.  AUSP contains characteristic values for other classified objects as well.

Now, unless SAP has changed their queries, when a batch search strategy is used, or something like CL30n or BMBC, when the system searches for matches, the FIRST thing it does is retrieve ALL records from AUSP that match the general material/plant values.  Once these are retrieved, then it looks at the characteristic requirements and determines a match. So if a material has 1000 batches to look at, it is retrieving from AUSP 1000 * 50 characteristics or roughly 50,000 records to do a compare or search against.  It does not retrieve only the characteristic records specified in the search strategy or transaction. 

So on a smaller system, and especially early on, you probably won't ever see an issue.  It only becomes an issue as the number of records grows.  Now if you have a good archiving program, you might never have a problem.  But I find very few places with good archiving programs in place!

Hopefully you can get something to work out with the user exit I suggested above.

Good Luck.  I appreciate what you are up against.  Please don't take anything I've said personally.  I'd also be trying to present whatever other options could be possible.  You would be remiss not to as a consultant.

FF

[Martin_H]

Fire Fighter wrote:
(...)
Please don't take anything I've said personally.  (...)
FF

Thanks for the batch feedback...and don't worry, I just wanted to explain why I am looking for some technical solutions. To my opinion it always is good if you get a response like "reconsider your (clients) approach/change the situation/..." instead of just getting an answer to the question. This shows that the person giving the answer thought about your problem - and much more about the cause of the problem - instead of just answering.

MH

[anand_rao3]

Hi Martin,

Correct me if goes wrong in understanding!

1. Lets say you have created MICs as follows.

• MICA1 and MICA2 in Plant A
• MICB1 and MICB2 in Plant B

2.  For a certain material you have created inspection plan in both plants

• Inspection plan in plant A contains, MICA1 and MICA2
• Inspection plan in plant B contains, MICB1 and MICB2

3. You created material specification also. In QS61 you used any one of above MICs (along with respective plants where those MICs have been created). Lets consider you have used following MICs in material specification

• MICA1
• MICB1
• MICB3 (This could be the MIC created in plant B and not used in any inspection plans either)

4. Now when inspection lot is generated it must be showing following MICs in result recording screen

• MICA1
• MICA2
• MICB1
• MICB3

1. MICA1 is reference MIC and hence got merged and not repeated in RR screen in QA32
2. I think, if the MIC is complete (not reference) and is used both in inspection plan and material spec, then you get duplicate entries at the time of result recording.
3. Ensure all are reference characteristics to avoid this.
4. The reason you are getting lot size = sample size would be you must not have defined any sampling procedure either in material spec or in inspection plan. Kindly verify the same.

1. I would not prefer using material spec and task list together (unless it is genuine requirement where you want to avoid excess masters creation) which may lead a chaotic situation as above.
2. Or the MICs maintained in QS61, should not be used in any inspection plan to avoid duplicate entries in RR screen
3. I would prefer create same sets of MICs in all required plants though one can use other plant's MIC in inspection plan of else's plant.

Regards,

Anand Rao

[Martin_H]

Hi Anand,

your summary is completly right.

Concerning

1. If you want to use reference MICs, but have e.g. different tolerances for different materials, then you cannot avoid MatSpecs, or am I wrong?

2. This is right, but would only prevent duplicates. The MICs in the MatSpec still would be copied to all inspection lots

3. This is normally my preferred way, but in the case mentioned above I have to cope with an existing situation....

Thanks

MH

[anand_rao3]

Kindly excuse me Martin, I could not understand your point number 1....different tolerances for different materials, then you cannot avoid MatSpecs

1. I believe material specifications are defined at client level. (Though you can use MICs of any plant there)
2. If there are multiple plants in a system and a certain material is extended to all these plants; and if the material has same set of inspection parameters for all plants, you probably have 2 ways to decide upon.
3. Either create those many inspection plans in every plant (which would perhaps tends towards creating those many same MICs in every plant) OR create multiple specification (creating only one MIC) one time which would be shared by all plants.

I am not also getting how reference characteristic is impacting your system? Whether you want to change tolerances of reference characteristics in inspection plan or multiple spec? As per my knowledge this is not feasible. If we change the tolerances in QS24 it automatically gets modified in to material spec or in plan.

Regards

Anand Rao

[Martin_H]

Hello Anand,

I probably have assumed that most persons know this scenario and did not mention it explicitly (my fault, sorry): the MICs are unlocked in the MatSpec and the values are entered there. This setup (used by quite some companies I know so far) enables you to centrally managed the MICs (like: controlling that there is only one MIC for length, and not several like length, length_extern, length_front,...) and at the same time keep the specs at individual material level. IF, and this is my issue here, if you use a commonly agreed MIC set.

Regards

MH