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:
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 reorganise 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.
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!