Article Hierarchy (SAP Library - Article Hierarchy)

Article Hierarchy

Use

The article hierarchy enables you to group your articles, using a customer-oriented structure. You can then map any grouping of articles, in particular the consumer decision tree (CDT). The CDT is oriented around consumers and their needs and, as far as possible, it reflects how, and according to what needs the consumer makes a purchase decision.

Note

The grouping of articles in a customer-oriented structure supports the eight-step-process for business planning in Category Management. This business planning process was developed by SAP, together with Roland Berger – Strategy Consultans and it follows the findings of ECR Europe’s Category Management Best Practices Report.

You define the category by considering the possible choices a customer has when taking a purchase decision. The category of a CDT should be clear and delimited. The articles of a category should be similar or interchangeable.

Examples of criteria for defining different structure levels (for example, subcategories, segments, subsegments) are different product forms (for example, roll-on deodorant, deodorant sticks and sprays), consumer (for example, child or adult) or ingredients (for example, caffeinated or decaffeinated). There are no restrictions as to the depth of an article hierarchy. However, experience has shown that a structure depth of a maximum of seven levels is recommendable.

The following graphic shows the possible structure of a CDT:

This graphic is explained in the accompanying text

Integration

Required function:	Required component:
Connection to merchandise and assortment planning (MAP)	at least plug-in 2001.1
Connection to SAP BW	at least plug-in 2001.1and SAP BW 2.1C
Connection to a workflow	at least plug-in 2001.1
Connection to a product hierarchy	at least plug-in 2001.1
Connection to the integrated article maintenance	at least plug-in 2001.1and SAP R/3 4.6C

Note

As of SAP BW 3.0A you have the option to maintain the CDT in SAP BW.

Features

Article hierarchy maintenance provides you with an option for easy Article Hierarchy Maintenance in the dialog box.

Article hierarchy mapping takes place in a strict hierarchy that can be assymetrical. This allows you to define several different article hierarchies at the same time.

You can define distribution chain-dependent article hierarchies. Articles can then be assigned to several article hierarchies.

A role that implicitly applies to all lower-level nodes of the CDT can be assigned to the category.

You can assign a strategy to every node/article of the CDT. The strategies of the nodes can be passed down to all lower-level nodes. Alternative strategies are overwritten by the inheritance strategy.

Within an article hierarchy or a subtree of the hierarchy it is possible to Reassign Nodes for example, to reassign a subcategory to a category. Article assignments are reassigned at the same time.

You can copy changes to a hierarchy (for example, copy a new CDT to another hierarchy). The article assignments are copied simultaneously.

Change documents can be written for every change in an active article hierarchy. This can be necessary for carrying out changes.

From the integrated article maintenance (new) articles can be Assigned to the Article Hierarchy . Article assignment is only supported at client level, this means that articles cannot be assigned to a distribution chain-specific hierarchy.

The maintenance of the article hierarchy is controlled by the Authorization Concept. You can then, for example (depending on the user) allow or forbid access to a category and the assigned CDT.

For planning support the article hierarchy is connected to Merchandise and Assortment Planning. To support analysis and reporting for categories, it is possible to export the article hierarchy to BW.

You cannot transfer the article hierarchy to the product hierarchy. Articles must also be assigned to the lowest node in the CDT. The article hierarchy also provides easy maintenance of the product hierarchy.

Constraints

Planned changes are activated at one point in time. It is not possible to control activation of planned changes using a future point in time.

Version creation of an article hierarchy, for example collecting all old versions of an article hierarchy under one version number from where they can be called up, is not possible.