SAP Classification Explained Part 2: Classification Tables

DevWorkbench    Tuesday February 12th, 2013   

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.

Classification Data Model

These are the relevant classification tables 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 concidence, 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 be needing 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.