Classification Class (Create Change Request)

The user can browse through all existing classification classes (including all change requests for new classification classes) and then mark one single class and choose from the choice of change requests types above:

The textual information of a class is edited without changing the concept, but rather to correct mistakes. If the concept of the class is changed, in most cases a new class has to be created instead.

• NOTE: Change Textual Information is possible in any release.

In order to create a CR for changing the textual information of a CC proceed as follows:

1. Select menu entry Change Textual Information under User/Change Request/Classification Class.

2. Select CC for which textual information will be changed in displayed hierarchical structure and press button “Select”.

3. Perform desired changes in Change Textual Info-Dialog dialog and press button Save.

A new classification class is created and positioned in the ECLASS class hierarchy. The levels 1-3 represent procurement markets, the 4th level represents classes of similar products or services. This has to be considered when creating a new class.

First, a requestor has to check whether the class already exists, possibly under a different name or as part of a more general term. The search function is available for this.

Second, the user has to decide on which level the class shall be created. The following questions may help the user to decide:

• 1st level (segment, market): Which procurement market does the product or service belong to?
• 2nd level (main group, market details): Which competence field or expert area does the product or service belong to? (e.g. the whole product portfolio of a wholesale company of machine elements)
• 3rd level (group, deeper market details): What kind of product or service do we deal with? (e.g. the portfolio of a screw manufacturer)
• 4th level (sub-group, commodity): What specific product class or service do we deal with? (e.g. Half-countersunk screw)

In order to create a change request (CR) for a new classification class (CC) proceed as follows:

1. Select menu entry Create Classification Class under User/Change Request/Classification Class:

2. Select parent class of new CC in displayed hierarchical structure and press button “Select”:

3. Fill in information of new CC in fields of Create Classification Class-Dialog and press Save:

A classification class can only be removed from the hierarchy without a successor if it is located on the 2nd or 3rd level and no sub-classes exist anymore. A classification class on the fourth level can only be removed after having created a successor with the help of a SPLIT or JOIN (see below).

• NOTE: REMOVE CC is a structural change and therefore only allowed in a MajorRelease.
• NOTE: REMOVE CC means that the class is marked as deprecated, its identifier cannot be used again. The removed class stays part of former releases, the coded name remains unused within the subsequent MajorRelease, but will be reused in R+2.x
• EXAMPLE: Class 19010101 [ID: AAA123] is part of release 8.1. It will be marked as deprecated in MajorRelease 9.0, but stays part of all recent releases. AAA123 is never used again as a class ID. The CodedName 19010101 cannot be used within all 9.x releases. Starting with MajorRelease 10.0.1 the CodedName 19010101 can be used again.

In order to create a CR for removing a CC proceed as follows:

1. Select menu entry Remove Classification Class under User/Change Request/Classification Class.

2. Select CC to be removed in displayed hierarchical structure and press button “Select”.

3. Enter reason for removal in Remove CC dialog and press button Save.

A classification class can be moved within the ECLASS class hierarchy, i.e. it is assigned to a new parent class. It does not change its identifier (IRDI), but only its CodedName, as the concept does not change, but only the classification location, i.e. the parent class. All assignments of keywords and properties will not be changed (Properties of AC/AS, keywords, attributes remain the same in the target class). Only when moving a class into a different segment, the segment-specific basic property list will change.

• NOTE: All subordinate elements (especially the AC) remain identical with regard to name and content. Identifier of CC remains unchanged. Only Coded Name will be changed.
• NOTE: MOVE CC is a structural change and therefore only allowed in a MajorRelease.
• NOTE: MOVE CC is only possible on the 4th level.
   

In order to move a CC proceed as follows:

1. Select menu entry Move under User/Change Request/Classification Class.

2. System displays the hierarchical structure of elements. In this hierarchy users also have the possibility to search after specific CCs.

3. Select CC in the displayed hierarchical structure (the source CC (on 4th level))and press button “Select”.

4. System displays again the hierarchical structure of elements.

5. Select new (different) “parent” CC in the displayed hierarchical structure and press button “Select”(the previously source-CC will be moved under this parent-CC on 3rd level).

6. After selecting the parent CC on 3rd level, system will display the MOVE CC dialog.

7. In the MOVE CC dialog, system displays the source-CC on 4th level and an editable field for coded name. Only the last 2 digits of the displayed coded name can be edited, whereas he first 6 ones will be inherited from the selected parent and will be displayed in read-only mode.

8. In the Move Classification Class dialog, enter reason for moving the CC and press button “Save”.

One existing CC shall be split into minimum two other CCs, whereas that the valuations (can be) are received together.

• NOTE: SPLIT CC intends that all assigned products and valuations are conveyed in the target CCs.
• NOTE: SPLIT CC is a structural change and therefore only allowed in a MajorRelease.
• NOTE: SPLIT CC does always have to include more than one successor class, i.e. there have to be at least two target classes with two different (new) class coded names. The original class will be automatically deleted, as the content is represented in at least two other classes. No separate CR DELETE CC has to be created by the requestor.
• NOTE: This structural change is only allowed for source classes and target classes on the 4th level, i.e. only a class on the 4th level can be split only into classes on the 4th level. Thereby a predecessor-successor-relation is documented for product classes (4th level) in the RUF and TUF. (There is only one source CC as SE and only on the 4th level, minimum two other target-CCs ALSO on the 4th level (CR or SE) in which it will be split.)
• NOTE: The source CC to be split is automatically deleted.
• NOTE: Consequent to the above-mentioned details, a DELETE CC (CR/CP) is being automatically created, as the content is represented in at least two other CCs. The CR Proposer from SPLIT CC and Reason for request is overtaken from SPLIT CC into automatically created DELETE CC.
• NOTE: Consequent to the above-mentioned details, many SPLIT operations can result into identical TARGET CC.
• NOTE: A SPLIT CC has to be combined with NEW CC-changes, i.e. additional CR have to be created to create the new classes in which the old class will be split into.
• NOTE: When splitting a CC, all property and keyword assignments of the source class will be copied to the target classes, duplicates with the same identifier being automatically ignored. The requestor can manually change this in a second step or simply by withdrawing properties from the source class.
• Example: 19010101 shall be split into new classes 19020201 and 19020202. Three CR have to be created: NEW CC 19020201, NEW CC 19020202, SPLIT CC 19010101 into 19020201 and 19020202. The CR for DELETE CC for 19010101 will be done automatically in the name of the same requestor.

1. Select menu entry Split Classification Class under User/Change Request/Classification Class.

Menu entry used to call function SPLIT

2. System displays the hierarchical structure of elements. In this hierarchy, users also have the possibility to search after specific CCs.

3. In the hierarchical structure of elements, select the source-CC SE (on 4th level) which needs splitting into minimum 2 other CCs (SE or CR).

4. System displays a list of all available CCs (SE and CR) on the 4th level, into which the source CC will be split. Press Select button.

5. System displays a list of available CCs (SE and CR) on the 4th level

6. Select the target CCs (SE or CR) into which the source-CC needs to be split. Use the check boxes, then press button Select.

7. System displays the SPLIT CC dialog containing the source CC and target CCs, as well as two tabs: Properties and Keywords.

• NOTE: The properties of the source CC, which will be used in the target CCs, are displayed under tab Properties (here, users have the possibility to select the properties to be used in the target CCs).
• NOTE: The keywords of the source CC, which will be used in the target CCs, are being displayed under tab Keywords (here, users have the possibility to select and define the keywords to be used in the target CCs).

8. Enter reason for Split Classification Class and press SAVE.

One or more existing CCs shall be joined/merged into one new or existing CC.

• NOTE: JOIN CC is a structural change and therefore only allowed in a MajorRelease.
• NOTE: JOIN CC can be done in an existing CC or a new CC, in which at least one other CC is joined. The original class(es) will be automatically removed (i.e. CR for Remove Classification Class will be automatically created).
• NOTE: This structural change is only allowed for source classes and target classes on the 4th level, i.e. only classes on the 4th level can be joined (on the 4th level). Thereby a predecessor-successor-relation is documented for product classes (4th level) in the RUF and TUF.
• NOTE: A JOIN CC can be combined with a NEW CC-change, in case classes are joined in a new class.
• NOTE: All properties and keywords assigned to the source classes will be joined in the target class, duplicates with the same identifier will be ignored automatically. A manual correction of these properties and keywords can be done afterwards. New properties have to be requested for the target class separately (see #Assign Property).
• NOTE: As the source class(es) is/are no longer necessary, the change requests for deleting the source class(es) will be created automatically by the ECLASS ContentDevelopmentPlatform.
• NOTE: User may run available Business Rule Check "Property assignment in split/join", which checks for split/join CC that every property is assigned to at least one target AC and that no duplicates exist.
• Example 1: 19010101 and 19010102 shall be joined in new class 19020201. Two CRs have to be created: NEW CC 19020201, JOIN CC 19010101 and CC 19010102 in 19020201. The CRs for DELETE CC 19010101 and DELETE CC 19010102 will be done automatically in the name of the same requestor.
• Example 2: 19010102 shall be joined in existing class 19010101. Only one CR has to be created: JOIN CC 19010102 in 19010101. The CR for DELETE CC 19010102 will be done automatically in the name of the same requestor.
• Example 3: 19010101 and 19010102 shall be joined in existing class 19010103. One CR has to be created: JOIN CC 19010101 and CC 19010102 in 19010103. The CRs for DELETE CC 19010101 and DELETE CC 19010102 will be done automatically in the name of the same requestor.

In order to join a CC proceed as follows:

1. Select menu entry Join Classification Class under User/Change Request/Classification Class.

2. Check box(es) in front of the CCs displayed in the Select Source CCs to Join dialog and press button

3. Select „Target CC to Join Into“ (a 4th level CC) from the displayed hierarchical structure and press button “Select”.

4. In the Join CC dialog, enter reason for joining the CCs and press button “Save”.

In order to facilitate the search for product classes, keywords can be assigned to classes.

• NOTE: They cannot have the same PreferredName as the class as this would produce duplicates.
• NOTE: They shall be alternative spellings or alternative names for a class, not generic terms (e.g. KW "Coach bolt" for the CC "Saucer-head screw" is correct, but KW "Screw" or "Machine element" for this CC is too generic and not allowed as it refers rather to the parent classes.)
• NOTE: Keywords are language-specific, i.e. they cannot be translated. An alternative name in two different languages has to be requested a s two separate KW.

In order to assign a Keyword (KW) to a CC proceed as follows:

1. Select menu entry Assign Keyword under User/Change Request/Classification Class.

2. Select CC to have KW assigned to in the displayed hierarchical structure and press button “Select”.

3. Check box(es) in front of desired KW(s) displayed in the Select Keyword dialog and press button “Select”.

4. In the Assign Keyword dialog, enter reason for assigning the KW(s) to the selected CC and press button “Save”.

• NOTE: As keywords are only an addition to the dictionary, changes are not tracked with the help of a version number. Neither does the withdrawal of a keyword have any influence on the classification class.

In order to withdraw a Keyword (KW) from a CC proceed as follows:

1. Select menu entry Withdraw Keyword under User/Change Request/Classification Class.

2. Click on the desired CC containing KW(s) in the Select Classification dialog and press the “Select” button.

3. Check box(es) in front of the desired KW(s) displayed in the Select Keyword dialog and press button “Select”.

4. In the Withdraw Keyword dialog, enter reason for KW(s) withdrawal and press button “Save”.