Concern catalog provides a decision tree data model supporting decision making. It has been designed for vehicle service to effectively guide potential user to indicate and report the failure. From quite generic observations trough set of questions down to specific problem, using descriptive hierarchy nodes, user is able to identify and pick a complaint. Along with a concrete complaint, a concern code is selected, which, with its description serves as a base for job creation in Service Order. Using a flexible lean condition engine, packages or additional attributes can be assigned to a concern code.
Concern catalog does not deliver data. It provides a complex framework using which a decision tree can be built from scratch
Being a part of Common package, Concern Catalog data model is ready to be used by other Business Functions.
General idea behind Concern Catalog structure can be presented by simple graph:
The main purpose of the Concern Catalog is to allow user to select proper Concern Code (possibly with additional attributes).
Main functionalities of Concern Catalog can be grouped into:
Path: SAP Easy Access > Logistics > Logistics Execution > Vehicle Sales and Service > Master Data > Mobile Service Advisor > Concern Catalog > Maintain Concern Catalog
Screen elements:
2.Unique catalog ID
To create a catalog, provide unique Catalog ID and press create button on the toolbar.
New catalog can also be created as a copy of existing catalog. To do so, provide an existing catalog ID and select Copy Concern Catalog under Concern Catalog top-menu.
When copying new catalog can be created or existing entries can be moved to another catalog
New Concern Catalog AttributesFollowing entries are important when creating new Concern Catalog:
| Field | Description |
|---|---|
Catalog ID | Unique Catalog ID |
Description | Meaningful catalog description |
Usage | Usage is an object of Lean Condition mechanism. Lean condition is used to determine additional attributes of concern conde using flexible criteria i.e. determine packages for particular vehicle, demand type for SRS etc. Usage defines parameters and data structures. Usage is selected depending on the business purpose and the application in which Concern Catalog is being used. For MSA purposes, standard usage is delivered within DBME package: /DBME/MD8_CCVA MSA Concern Catalog Code Values ! Usage is mandatory when additional attributes are to be created for a concern code. As part of usage additional customizing may be required. From catalog definition user can directly branch to condition table definition and access sequence definition for usage used.  Lean Condition for Concern Catalog |
Stack mode | When stack mode selected, application generates hierarchy nodes automatically extending hierarchy node by parent id. Not mandatory. |
Separator | In this field, separator used for stack mode – code generation is used. Separator defined here will be used to concatenate parent and child node. Not mandatory. |
Assigned text types | Text types valid for catalog nodes. Will appear then when maintaining hierarchy nodes and concern codes. |
3. Hierarchy maintenance
To create hierarchy node/nodes following menu entry needs to be chosen from right-click menu on the concern catalog definition.
It is recommended to create a root node as the top level of the catalog. Additional text / inquiry can be assigned to the root node and displayed by target applications. I.e. in MSA root text serves as a query for the highest level of the catalog.
Following approaches are possible when maintaining catalog hierarchy nodes:
Each catalog hierarchy node can hold additional text as set in the catalog definition:
Hierarchy node textsAdditional settings for the hierarchy node accessible on double-click on the relevant node:
Hierarchy node additional attributes| Field | Description |
|---|---|
Hierarchy ID | Current / Selected hierarchy ID |
Description | Hierarchy description |
Hier. Group | Additional parameter allowing to group hierarchy nodes with similar attributes. Field values can be customized under: /DBME/SPRO -> |
Mutually Exclusive | Flag to be used by frontend applications to control navigation through concern catalog |
Do not include in path | When the flag is selected API reading the catalog will skip the node when building full path description |
Do not include in stack ID | Nodes created / assigned under the node having this flag selected will not inherit parent id automatically |
Parent ID | Current parent ID to which selected node is assigned |
Icon/Image | Icon/Image path that can be included in the catalog definition. Handling of graphical elements has to be implemented within frontend application using the catalog. |
Full path | Field displays current full path for selected hierarchy node |
As a rule of thumb, hierarchy node id’s have to be unique within the catalog.
There is no strict limitation when it comes to hierarchy levels. Hierarchy ID has a limited length of 12 characters therefore approach to defining the hierarchy identifiers will determine how many levels would fit into the data model.
4.Concern Code maintenance
Concern code can be created and assigned to the hierarchy level by accessing right-click context menu on the hierarchy element and picking Create-> Code
Concern Code CreationCode creation is similar to hierarchy node creation. Concern code is the object to which additional attributes can be assigned like package, damage type, estimated time using lean condition technique.
New Concern Codes entry viewFollowing approaches are possible when maintaining concern codes:
Additional settings for the concern code accessible on double-click on the relevant node:
| Field | Description |
|---|---|
Code ID | Current / Selected concern code ID |
Description | Hierarchy description |
Short ID | Short description of the code – optional |
Allow empty value | If flag selected, API reading the catalog will not return these codes if no additional attributes from lean condition are found |
Parent ID | Current parent ID to which selected code is assigned |
Parent ID | Current parent ID to which selected node is assigned |
Icon/Image | Icon/Image path that can be included in the catalog definition. Handling of graphical elements has to be implemented within frontend application using the catalog. |
Full path | Field displays current full path for selected concern code |
As a rule of thumb, concern codes have to be unique within the catalog.
Concern code length has 20 characters which should be taken under consideration when designing data model for whole concern catalog.
5.Value / Attribute maintenance
Additional attributes can be assigned to a concern codes by means of Lean Condition technique. Specific usage assigned to the whole catalog determines how the values are to be maintained. To create condition tables and access sequences user needs to be familiar with Lean Condition mechanism.
Lean condition maintenance will not be described in this chapter.
As a precondition, valid usage must be assigned to a concern catalog to enable value assignment to the concern codes.
Value maintenance can be accessed either via menu or via context menu under right click on any code.
Depending on defined Lean Condition Criteria tables, user needs to provide additional attributes of particular concern code. In the example below, a package is being assigned to a concern code:
Attributes assigned to the concern code are also displayed on the overview of the hierarchy:
6.Catalog determination and usage
Concern Catalog provides a master data model and a framework for building decision tree. Frontend for the concern catalog is implemented in MSA and Online Appointment Scheduling (SRS).
Determination of the concern catalog for MSA can be found in:
/DBE/SPRO > VSS > Order > Mobile Service Advisor > Application > Concern Catalog Determination
Lean Condition is used to determine right catalog depending on various business criteria.