Classes and Characteristics:

Transactions in characteristics/classes:
Activities in the Classification System

Transaction Activity

CC04 Product structure

Classification

CL30N Find objects in classes

CL31 Find by class type

Master Data

CT04 Characteristics management

CL02 Class management

CLHP Graphical maintenance of class hierarchies

Assignment

CL20N Assignment of object

CL24N Assignment of class

CLMM Mass change to assigned values

CL22N Class hierarchy

CL26 Mass release

Specification System

SPEC01 Process template

SPEC02 Process data sheet

Reporting Functions
CT10 Characteristics list

CT11 Characteristic value list

CL6AN Class list (ALV)

CL6A Class list

CL6D Class without superior

CL6C Class hierarchy

CL6BN Object list (ALV)

CL6B Object list

CL60 Object comparison

CL2A Classification status

Other Classification System Functions

CL2B Class type settings

CL6E Copy DIN standard

CL6F Copy DIN characteristics data

CLGT Set up tables for accelerated search

CLST Create class statistics

CL6H Classes: convert/split/merge

Introduction
Hi folks,this is the start of a several-part series in which I want to give an in-depth explanation of the
classification functionality in SAP ERP®. Starting with this post, where I give an overview of the topic and
mention important terms, I will go through the data model and demonstrate how to read data from
classification and how to set up authorization. I will also explain the user exits that can be used in
classification.

Here, I’d like to give you a general overview about what the SAP ERP® classification can do. In plant
maintenance, we often have a situation where we manage many different objects of the same kind, which
have the same specific properties and require to be handled the same way. Let’s say we want to maintain
our company fleet as PM equipments, which is not uncommon to do. Cars have very specific properties,
such as color, number of doors, fuel type, et cetera. With classification, there is an easy way to maintain
this in the equipment master data transactions (and much more, as we’ll see) without doing any
development or customizing. Instead, we follow these steps to set up classification for our object.
Maintaining characteristics – transaction CT04

Characteristics Maintenance

To add custom data to objects, the first thing we need to do is create Characteristics for it. A characteristic
describes a specific property of an object. For a car, you might want to create a characteristic called
“COLOR” to maintain the color of your cars.

Basic Data
When creating a characteristic, you can choose between different data types. The system offers you data
types for character fields, currency, dates, numbers, or time. Depending on what data type you pick, you
can further refine options for the characteristic field. In this case, the character field we choose lets us
enter the maximum number of characters as well as an indicator for case sensivity.

Restrictions for a characteristic

It’s also possible to mark the characteristic as multi-value. In this case, it can be entered more than once
for any object (which doesn’t really make sense for color). The “entry required” indicator will make this
characteristic mandatory during classification.
Value Control
In the Values tab, we have very detailed control over the values that the characteristic will allow. By
clicking the Other Value Check button, we can pick four ways to suggest or restrict the values.

Methods to verify characteristic values

Allowed Values
This way of value control allows to create suggestion values for characteristics that the user can pick from
during object classification. By unchecking the Additional Values box it’s also possible to restrict the
possible values to only the ones listed in this tab.

Check Table
A table which contains the allowed values can be named here. It must have exactly one field and its data
type must correspond exactly to the characteristic’s data type.

Function Module
A function module can be entered here that allows the implementation of custom logic to check the
characteristic value. This is by far the most sophisticated (and work-intensive) way to check the values for
a characteristic in SAP ERP®. More information on how to do this can be found in the F1 help for the
function module name field or here: Function Module Interface.
(http://help.sap.com/erp2005_ehp_05/helpdata/en/ec/62a9c8416a11d1896d0000e8322d00/content.htm)

Catalog Characteristic
Via the Catalog Characteristic strategy, the characteristic can be linked to a Selected Set. A Selected Set
can be created using transaction QS51. It can contain codes from multiple catalogs, which then restrict
the possible values of the characteristic if the set is linked. However, it only works for catalogs 1
(Characteristic Values) and 3 (Usage Decisions, this is needed in the QM calibration process).

Allowed Values

In our case, we use the Allowed Values strategy to create suggestions for the colors our cars usually
have, but leave the user free to enter more. Also, we set Black as the default by checking the respective
box. Note how if we use this method of value assignment, the values are created as key/value pairs. This
will have an impact on how the data can be read later on.

Additional Data
In the Additonal Data tab, you get even more control over the way the characteristic behaves during
classification. You can link the characteristic to a table field, creating what is called a Reference
Characteristic. If you do that, the properties (such as name, data type and possible values) are entirely
deducted from the data element of the field you linked to; any previous entries are overwritten. You can
also link to multiple table fields, extending the value possibilities to all the tables entered. However, the
referenced fields must have exactly the same data type.

In addition to that, links to documents can be added here. This can be displayed by the user during
classification for additional information - in our case, we can add a color chart. Furthermore, you have
some control over how (or if) data is entered. You can set the characteristic to “display-only” or hide it
entirely. Obviously, this only makes sense if the characteristic value is inferred from another characteristic,
something that I will probably cover in a later article.
 Additional Data for Characteristics

Restrictions
If you create a characteristic, it can be used in all classes, as we will see in the next chapter. It is,
however, possible to restrict the classes that the characteristic can be used in. This is done on the
Restrictions tab.

Creating a class – transaction CL02

Characteristics cannot be assigned directly to objects. To do that, we need to add them to a Class first –
hence the name Classification. Classes are maintained in transaction CL02. The first thing you will need
to do is pick a Class Type. The Class Type you pick determines which objects can be classified with this
class (and many more things, actually – this will be covered in another part of this series). SAP ERP®
comes with a bunch of Class Types already prepared. In this case, I will use the Class Type 002, which
allows me to classify equipments.

Basic Data
The basic data of a class includes a description, a status (only classes with status Released can be used
in objects), a group for quicker class search, the possibility to check for identical classification values, and
organizational area, as well as some authorization data (which we will use in a later part of this series). All
we really need to enter here is a short description.
 Class Basic Data

Keywords
It is possible to enter keywords for a class that can be used when searching for classes – this is done
here.

Characteristics
The Characteristics tab is where we get to the core of classification. To add characteristics to a class, they
must be entered in the list displayed here. They will be available later during classification of an object.
You can also insert some additional control data here.

Adding Characteristics
The overwrite functionality should be mentioned here as well. By pressing the Overwrite Characteristics
button at the bottom of the list, you will be taken to the characteristic maintenance screen. However, the
changes you make here will only apply to the characteristic if it is used in the context of the particular class
you’re editing. It will remain unchanged on other classes where it is used. The same also works for the
characteristic values – with the Overwrite Values function, you can modify the existing characteristics
without influencing the usage of the characteristic in other classes.

You should note, however, that this creates additional complexity and maintenance effort – in some cases,
it might be better to create new characteristics. If, for example, the original characteristic values get
updated, the changes will not be taken over automatically to the overwritten characteristic. Instead, you
will need to access the characteristic from the class via the Overwrite Values button and then use the
function Extras → Overwrite → Update Values to take over updated data from the master characteristic.

Assigning an object to a class – transaction

CL20N
Now that we’ve created a class with a characteristic in it, it’s time to assign it to an object so we can enter
some values. This can be done in most object transactions; I could classify my equipment in IE01/IE02 as
well. Here, however, I will show the more general approach: using CL20N. The first thing we will need to
do, again, is pick a class type that determines which object to classify.

Assign Objects to Classes

After having entered the object, we can select the class(es) which we want to assign. By setting the
Standard Class indicator, we can tell the system to display the characteristics of this class by default if the
object is assigned to more than one class. We also have the possibility of setting a classification status
that restricts if and how the object is found in classification search. With this it’s possible to mark a
classification as incomplete, retrieve additional needed data and come back later to finish it.

When that is done, the characteristics that we assigned to the class are listed below the class selection
area. They can be assigned values there, depending on which methods of entry and value check
strategies we chose. Since we’ve suggested allowed values for our COLOR characteristic, these are
supplied in a pop-up window here. When you click the Document (original) button at the top, the document
that was linked to the characteristic is displayed to support the user when making his choice.
 Maintaining Characteristic Values

Mass classification – transaction CL24N

Of course, it’s rather tedious to assign objects to classes one at a time. That’s what transaction CL24N is
for. Instead of choosing an object and assigning multiple classes to it, we can pick a class and assign
multiple objects to it. However, the valuation of characteristics must still be done one at a time. There must
be a better way to do this…

Mass valuation of objects – transaction CLMM

Copy Characteristic Values

And of course there is – transaction CLMM allows us to perform a mass valuation of objects or copy the
valuation of one object to many others. That makes classification of multiple objects quite convenient.
Finding objects via classification
When working with classified objects, of course it is important to be able to find them according to their
characteristic values. SAP ERP® offers two transactions to deal with this. These are CL30N – Find
Objects in Classes and CL31 - Find Objects in Class Type.

Find Objects in Classes

Transaction CL30N will let you search for objects in a specific class. You can enter the class type and
class and will be able to set filter criteria for each characteristic in that class. This transaction is also the
only one where overwritten values are searchable, because the characteristics will be loaded in the
context of one specific class.

Find Objects in Class Type

On the opposite, transaction CL31 lets you search for objects in a class type. Here, you have the
advantage of being able to enter characteristics from multiple different classes – very useful if you’re
using multiple classes for objects. However, characteristics are not loaded in the context of a class, so
overwritten values will not be available as search criteria.
More interesting topics
Where-Used List and Object List
There are some more interesting transactions in the classification environment that can help you find what
you look for. One of those is the transaction CT12 – Where-Used List of Characteristics. It is a flexible
way of finding various elements where characteristics are used, such as classes and classified objects. It
is thus another means to find classified objects in SAP ERP®, this time using the prettier ALV tree
structure.

Another nice transaction to know is CL6BN – Object List. It gives you another convenient way to get a
quick overview about classified objects of a certain type and their valuation.

Classification Object List

This concludes the first part of my series on classification. It was a general introduction to the classification
functionality in SAP ERP®, giving an overview about the most frequently used features. In the next part, I
will address the developer community when I discuss the data model of classification and show you how
the classification system is reflected in the actual database tables.

Read on…
After I introduced you to the classification system in SAP ERP® in the first part of this series, I’d like to go
into more technical detail and explain the data model that is behind the classification. Why is this relevant?
While it’s true that there are function modules to read and write classification data, sometimes (and by
sometimes, I mean most of the times) it’s faster to read classification data directly – if you know how. This
will be demonstrated in the next part of the series. First, however, I will introduce the tables that are
involved. I also prepared a handy cheat sheet which you can use to get a quick overview about the
relevant classification tables.
 These are the relevant tables for classification in SAP ERP®.

Note that this cheat sheet does not include all table fields. The key fields are complete, but non-key fields
are only listed if necessary for the following explanation.

Classifiable Objects – Table TCLT

TCLT is the starting point for classification. It defines the Classifiable Objects, meaning that only objects
listed in this table can be classified. It contains the primary data table for the object (for example table
EQUI) in the field OBTAB. This field plays an important role in the classification data model.

Object Keys – Table TCLO

Table TCLO defines how the Object Key that is used throughout classification in SAP ERP® is built.
Usually, the object key corresponds to the key fields of the object table, but this does not have to be so. In
customizing, it’s possible to use up to 9 fields from the object table to build the classification key of
objects. The names of these fields are saved in the fields KEYF1 to KEYF9 in table TCLO. Let me give
you an example (from plant maintenance, of course):

Table IFLOT, which contains functional locations, is listed in TCLT as classifiable. In table TCLO, the field
KEYF1 contains the entry TPLNR. Other fields are not filled. That means that the object key for functional
locations throughout the classification system will be the field IFLOT-TPLNR (which, by coincidence, is the
primary key for the functional location table). For keys that consist of more than one field, the field values
are concatenated. This means that for example plant-independent batches, which have the table MCH1
and the key fields MATNR and CHARG, will have the concatenated value of MCH1-MATNR and MCH1-
CHARG as their classification key.

Class Types – Table TCLA

After defining the classifiable objects and their key, it’s time to check the Class Types. These are saved in
table TCLA with all their important properties. Usually, class types correspond to exactly one object type –
for example, the class type 002 can be used only for PM equipments. Consequently, the table EQUI is
saved in the field TCLA-OBTAB. However, it’s also possible to classify more than one object type with a
single class type – for example, class type 023 can be used for batches and materials. If this is the case,
TCLA-MULTOBJ contains an ‘X’ – note this for later because we will need it when we talk about table
INOB. Since more than one OBTAB is required in such cases, entries in another table are made.

Multiple Objects in Class Types – Table TCLAO

If more than one object table is required per class type, they will be stored in table TCLAO with a
reference to table TCLA. The settings in TCLA will be overridden by those in TCLAO in such cases.

Class Headers – Table KLAH

Of course, after class types are defined, we can create classes for them, as demonstrated in part one of
this series. The header data for classes is stored in table KLAH. This table introduces the Internal Class
Number which is stored in the field CLINT. It is needed to find out which objects are classified in a certain
class. The textual identifier that you enter during class creation (such as “CAR”) is stored in field CLASS.

Characteristics – Tables CABN and CABNT

Characteristic Headers are stored in table CABN. They also have an internal ID in field ATINN, which is
needed to read classification data for this characteristic. The other key field, ADZHL, is only used if
Engineering Change Management (ECM) is in use. It is then incremented for each change done. If ECM is
not used, ADZHL has an initial value (0000). This applies to all tables which have ADZHL as key field. The
textual characteristic identifier is stored in field ATNAM. To read the text for a characteristic, you’ll have to
look into table CABNT additionally.

Reference Characteristics – Table CABNZ

If a characteristic is a Reference Characteristic, it has an entry in CABNZ. Here, the table and field to
which it refers are saved.
Characteristic Values – Tables CAWN and
CAWNT
The table CAWN contains the proposed or allowed values for a characteristic if the “Allowed Values”
strategy is in use. If other strategies, such as check table, are used, CAWN does not contain any values.
Again, to read the value text in the correct language, table CAWNT has to be read.

Allocation of Characteristics to Classes – Table

KSML
After all these master data tables, now we’re starting to come to the root of classification. As we learned,
characteristics must be assigned to classes in order to work. This assignment is saved in table KSML. For
each internal class ID (CLINT), it has the position of the characteristic in the class in field POSNR, which
is just incremented by one with each characteristic added. The actual characteristic ID is in the non-key-
field IMERK. Again, the field ADZHL is not relevant if you’re not using ECM.

A quick example is in order here. Let’s remember the example from the first part – we assigned the
characteristic COLOR to the class CAR. This is what it looks like in KSML:

An assignment of characteristic to class in KSML.

The class CAR has the internal class number 0000000481 in CLINT. Since it’s in first position, POSNR is
001. The internal ID of the characteristic COLOR is saved in field IMERK.

Mapping of Internal Numbers to Objects – Table

INOB
Remember how I said the field TCLA-MULTOBJ would become important? Here it is now. To explain what
the table INOB does, we have to remember again that it’s possible to classify multiple objects with one
class type. This is the case for class type 023 (batches) – you can classify materials and batches with it.
However, this leads to a problem. Material numbers have a defined classification object key, batches have
a different one. How does the classification system know with which key it should read classification data?
This is where INOB comes into play. For class types where TCLA-MULTOBJ is set, the classification
object key as defined in TCLO is mapped to an internal number, which is then used as the object key in
the tables that contain classification data (KSSK and AUSP). That means that for class types that allow
the classification of multiple different objects, you need to map the external object key that is defined in
TCLO to the internal one defined in INOB. Only with this internal key is it possible to read data from KSSK
and AUSP.

If the class type you’re using does not allow classification of multiple objects, the external object key can
be used to read data directly from the data tables. In this case, table INOB is completely irrelevant and will
hold no entries for the class type.

Some additional information:

Normally, after classification of multiple objects has been activated, it cannot be revoked again if objects
have been classified. Consequently, it can’t be activated afterwards as well. There are, however, two
reports mentioned by SAP to reorganize this data: RCCLUKA2 and RMCLINOB. For more information on
this, read the F1 help in SPRO -> Cross-Application Components -> Classification System ->
Classes -> Maintain Object Types and Class Types -> Details of your Class Type -> Field Multple
objs allowed.

In a nutshell:

 If TCLA-MULTOBJ is set for your class type, read the internal object key in field INOB-CUOBJ to
access classification data. Use the external classification key (which is determined by the settings
in table TCLO) as selection criterion on field INOB-OBJEK.
 If TCLA-MULTOBJ is initial for your class type, use the external object key to access classification
data directly.

Allocation of Objects to Classes – Table KSSK

After this prelude, it’s time to get down to the real classification data. If an object is classified in a class,
this is saved in table KSSK. KSSK is one of the most important tables in the SAP ERP® classification
system. If you want to know if an object is assigned to a certain class, that’s where you look it up. The key
fields are set up as follows:

 OBJEK is the classification key of the object you’re looking for. It’s either the external one as
defined in TCLO or the internal one from INOB.
 MAFID is called Indicator: Object/Class. This field contains an “O” if we’re classifying anything but
a class, in which case it contains a “K”.
 KLART is the class type we’re reading from.
 CLINT is the internal ID of the class which comes from table KLAH.
 ADZHL, once again, is used only when Engineering Change Management is active.

Characteristic Values – Table AUSP

Once you know this data, you can go ahead and read the actual classification values from AUSP. You’ve
seen all the key fields in here before, so I’m not going to comment these again. Basically, you need your
object key (internal or external), your internal characteristic ID and the class type. However, notice that
there are several different fields for values, depending on which data type the characteristic in question
has. Reading these values is a bit tricky and deserves its own article.
Summary
Congratulations if you stayed with me throughout the whole article – you now know exactly how the SAP
ERP® classification system’s data model works. However, that’s not the end of the story. If you’ve taken a
look in table AUSP, you might have noticed that the values saved in there are not exactly formatted as
one would expect. This is why the next part of this series is dedicated to reading and displaying data from
AUSP.

Stay tuned!

Hi all,

After creating a KMAT material, configurable, i create a variant class 300, with characteristics.
When I create a PO with specific values for the characteristics,

I'm able to get the characteristics and values for that configurable material on the PO ME23N
but in what table these values are stored ???

that's to say i need a table with both PO number, and values of the characteristics on the item.

many thanks in advance for every help and suggestion.

table IBINOWN gives instance

table IBINVAL_SEL_F shows values for characteristics.
module fonction VC_I_GET_CONFIGURATION gets characteristics
(fill field 'instance' with the instance in ibinow)