Skip to Content

QM/Characteristics/Specifications/Classification – Blog 1

QM/Characteristics/Specifications/Classification – Blog 1.

This is the first blog of a series of blogs and documents I intend to write and post.  The series of postings will attempt to explain the relationships and issues with how specifications are kept in SAP and in particular how batch management is impacted.  Or probably more accurately how batch management affects QM.

I’ll not only include the technical process around this subject, but I’ll try to provide some functional information around these processes.  The how’s, the why’s, the pitfalls, the benefits, the pros, the cons, etc…  I’ll also try to provide some real world examples of how certain techniques can be used.

I also hope that other QM experts here will chime in with their own comments.  I will take all comments constructively and will make every attempt to correct or update the blog/document where necessary.  For those experienced QM folks, please have patience with these blogs.  A lot of these blogs and documents will be old stuff to you.


But hopefully you can comment and add to what is presented. 

So, to begin this series, I think some background knowledge should be covered.  One of the first things that I think is crucial to understanding these QM processes is understanding the relationship between Master Inspection Characteristics (MIC’s) and General Characteristics, (GC’s), You may find SAP documentation as well as consultants or clients referring to general characteristics as batch characteristics, or class characteristics.  In this series of blogs and documents I will use the term general characteristics.

The first key concept to understand is that MIC’s are only known to the QM module in SAP.  General characteristics are used by all other areas of SAP.  With only a handful of exceptions, QM does not really know about GC’s. Why is this?  To be honest, I don’t know 100% for sure but I’ll give you my thoughts on this.  Maybe a true SAP historian can comment and let me know if I’m right or not.

In any case, the QM module pre-dated the classification system. I believe classification was introduced back in 3.1, I think with the 3.1F version.   I’m going to guess that classification was developed by an SAP customer/third party firm and then bought out by SAP and added to SAP. That’s a total guess however.  In any case, you have to remember that SAP was at the time, a business system.  It wasn’t designed as a full blown LIMS.   It was to provide the basic laboratory functions to support the business.  The QM module wasn’t really meant to do much outside of collect final product test results, provide a certain amount of in-process testing and control, and allow a formal way to release product and print test results on a certificate to support the required SD documents.  It’s grown a lot since then!  There was no batch management and quality and testing was mostly plant centric.  So MIC’s were plant centric data.

With the release of batch management and classification, there came a need to get QM test data into the batch record.  Batches were designed to use general characteristics, and since by definition, batches can only have one current test value for any given test, they had to figure a way to get QM and Classification to integrate somehow.

I am sure there were a ton of design meetings and I’m sure many things were considered.  But for better or worse, the infamous linkage between MIC’s and GC’s was created.  A field (ATINN) was appended to the QPMK table and the marriage was made.

Now since GC’s are really client level data, and MIC’s are plant level data, this now impacts the QM design.  Since only one MIC can be assigned to one GC this can cause some problems.  If you have a MIC, say VIS003 in plant 1000 and VIS003 in plant 1001, you cannot assign them to the same general characteristic VISCOSITY. 

Typically, (BTW: for future reference that’s my way of saying that nothing is absolute, and somewhere, there is probably a valid exception but you really, really want to avoid the exception), you do not want to create multiple general characteristics to match up with multiple MIC’s across multiple plants.  If you think you have this need, go back and think it through carefully.  Think about how batches work, the batch level you use, the transfer of material between plants, to distribution centers, to consignment stock, how the production chain works, producing certificates, using batch determination, batch derivation, copy inspection results, etc…  You’ll hopefully see that it would be a bad idea.

Fortunately, SAP allows us to share MIC’s across our inspection plans and tasks lists.  Doing this does allow us to  minimize the number of MIC’s required.

So, define a master data plant.  Even if you’re on a small project and only have one plant, make sure you design from the start as if you have more than one plant.  Define the one plant as your master data plant up front.  Have it recognized as part of your design documents as the master data plant right from the start.  You might even suggest creating a virtual plant just for master data. Other modules often can find a master data plant valuable. 

Screen Shot 2013-09-23 at 10.54.18 AM.png

If you are in what I call a silo’ed business, whether for practical reasons, (GMP reason),  or political reasons, (I don’t want people seeing my data), a virtual plant allows you to provide appropriate users access to the virtual plant, without giving them access to another plants data.  If you have two or more very disparate businesses working in the same SAP client, you might need to have two or more master data plants.

In lieu of having a specific virtual master data plant you might consider using a “plant” that was only set up to be used as a corporate location or sales location.

In any case, hopefully now, your design has all the MIC’s created in one master data plant, and each MIC will be linked to one and only one general characteristic.  This is important as I will be basing the remaining blogs on this concept.  At appropriate places I will try to point out what issues would happen if you used a multiple mic’s across multiple plants design.

Ok… this is probably a good stopping place.  The next blog of the series will discuss the impact of linking MIC’s with general characteristics and some of the more technical issues associated with the linkage. It will serve as a basis of how specifications are maintained.

Next Blog:

You must be Logged on to comment or reply to a post.
  • Finally this series has started! Am looking forward to get some insights on the GC usages, that’s a very interesting topic, also because SAP provides quite some different ways on solving issues here.

    I personally also do support the concept of a virtual plant, while having played with all different kind of concepts so far.

    Will you also be writing about different batch strategies (plant, client, …) and their impact on the GC/MIC concepts (if there is any)?


    I just want to make some advertising to our document:, where one can see some advantages/disadvantages on MIC architectures.

    • Thanks Martin,

      I tried to send you a direct message but it said we weren’t connected.  Can you try?  Maybe I can reply back.



  • Craig,

    Thank you for this great blog series. I am currently designing similar scenario  and my client has a requirement where specifications of quality attribute vary among different grades in Same plant/ across plant for same grade which  means I have to create same GC with different spec and create those many MIC’s.

    I was hoping I can have broad specification range at GC/MIC and have material specific specification in inspection plan, but  it is not allowed to change in inspection plan. Any thoughts here-

    • I haven’t added to that series in a long time.  I really should.. just not much time.

      You can create one GC and one MIC.  Keep them linked. Maintain the actual spec in the material master batch classification view for those characteristics that have a different spec range. If nothing is modified in the material’s batch classification screen, the spec value comes from the batch class the material is assigned to.


  • Thank you Craig. I did try and did not seem to work.

    I see Inspection by configuration is available in QM view for 01.03.04 inspection type.

    Inspection by batch classification is available for inspection type 10,11,12.

    I am using 89 inspection type. I have specs in characteristics linked to MIC so Inspection plan gets it from class characteristics.   Am I missing something in master data so It can pick from material master classification view – batch class?

    • Try maintaining QS61 and see if that does it.  Just open it and save it.   Don’t change anyting in QS61.  Everything should just copy in if your MIC’s and GC’s are correct.

      • In the inspection type set up you need to have both “Insp. with task list” and “Insp with mat spec.” checked on in the materials 89 inspection type setup.

      • Yes, it did worked with QS61. I tested it few minutes back. so I can have  inspection plan ( plant specific) and material spec ( client level). It takes everything ( Including sampling procedure ) from inspection plan and only specifications come from material specs. works great. Only challenge is to convince all plants on single specs for shared material.



        • FYI – at one client we created a batch job that ran nightly that looked for new batch class assignments for materials and if one was found the program ran the QS61 transaction for them as it requires no user input.  That way they never missed creating the QS61.

      • Craig, I found another easy way to do it in inspection plan itself. We can have class characteristic with broadest specification range and linked with MIC. When we use MIC in inspection plan, we can unlock its reference and edit specifications in inspection plan itself but need to make sure specification is under the broad range specified in class characteristics other wise it does not flow to batch.



        • The issue was getting individual material specs down from the material.  Yes, you can unlock the characteristics in the plan and maintrain specs in the plan. and on a material basis.  The only downside for that is that if you need to create a new version of the MIC, you have to manually update every plan it’s used in.  Of course once the MIC’ are created and are stable, these usually change very infrequently.

          Also, if you need to change specs, you have to change each plan that might be used.  Some places map their inspection types on a one-to-one basis to plan usages. So if 4 inspection types are activated for a material, you may need to update 4 plans.

          The other downside I find with keeping specs in plans is that it usaully requires a client to develop a separate program to provide the specs to other interested people in the company.  Few people outside of QM would be able to figure out how to look at the specs and it wouldn’t be as a group.  A development or report is necessary if someone might ask “What is the spec for material xxxxxxxx?”.   Many places uses third party tools for specs so it might not be an issue in many places.

          By maintaining the specs in the material master, anyone with MM03 can look up a spec.  In addition you can use classification transactions like CLMM to make mass changes to specs across multiple materials if you know how to do it via CLMM.


          • I agree 100% with your insights. Thank you very much.  For me having specs at material master is challenging because I have different specs for material in each plant and classification is at client level in material master. I am trying to drive client towards standardization and hopefully would like to adopt method you suggested. But I do have fall back plan  of unlocking MIC’s in inspection plan in worst case.

          • Yes. that is a challenge.  I see that quite often and I don’t normally understand it.  If a spec is different from plant to plant, it is not the same material.  Seems like a basic concept but many companies don’t see it that way. Confuses the heck out of me.


  • Nice document ,  thanks for the story .  MIC is really important , I still feel confused and try to get  read the three posted blogs . Here thanks again for the nice document .

  • Hi Craig, I wonder if you can help me with an issue I have raised with no answer yet. I have an scenario of single results characteristics and I want to pass the maximum value measured for the characteristic (normally stored in QAMR-MAXWERT) instead of the mean value (QMAR-MITTLEWERT) to the batch classification. Do you know if I can achieve this via standard? I’m trying to avoid using code for this.  If you would like to reply to my question, please find the link below: