With PIM 8 new functionality in the area of attributes has been introduced, like the Feature-Attribute Match, which enables the inheritance of attributes from the structure groups down to the attributes on item level, as well as the context less selection of preset values which don't require the selection of a context any longer. In order to make these and future functionality possible a clearer definition of structures was essential.

Companies which use a PIM system always have a structure in which they classify and maintain their items and products as well as defining the relevant features for a specific category of products. Some customers have more than one maintenance structure but always one leading structure. And most customers have one or more output structures, which represents e.g. the categories of a web shop.

The older versions of PIM don't reflect this situation, there is no differentiation of the structures. Therefore the structure types were redefined together with the Informatica Professional Services and based on the Informatica Professional Service best practice recommendation and consulting book.

Goals:

• Always know the relevant preset values for an attribute. The relevant preset values are the ones of the assigned maintenance structure.

• It must be possible to display these relevant preset values even without the explicit "context" in the user interface. In older version it was necessary to set the context of an attribute by selecting its structure group first because the preset value list was not unique for an attribute.

• Display preset values for attributes which are based on features from different maintenance structures at the same time in the attributes table.

• Allow the synchronization of features from the maintenance structure group down to items and products (feature-attribute match)

• Essential foundation for additional future attribute enhancements

Rules:

• There will be exactly one primary maintenance structure at any time, but multiple secondary maintenance structures

• Attributes may only have one Attribute-Feature Reference to a maintenance structure (primary or secondary). However, the attribute can still have more mappings to non maintenance structures (Output structures, classification structures).
  The first assignment of the attribute to a maintenance structure will be accepted, all other attempts to connect the attribute to an other maintenance structure will be rejected.

• Maintenance structures may not be multi classification

• Output structures only have "different default value". However, it is possible to change the value of the assigned maintenance structure in the UI context of the Output structure.
  

• Maintenance structures inherit features as attributes like today, output structures not . In an output structure existing attributes will still be mapped to the feature if the names are equal.
  

• Maintenance structures may have products and items assigned to leaf levels only

The following types of structures are available

• • Primary maintenance structure

  • Secondary maintenance structure

  • Output structure (Default selection in the wizard)

  • Classification system

  • Material group system

• The old entries "User-defined classification system" and "Print structure" are no longer available

• If additional structure types are added by professional service (e.g. input structure) the default behavior is like an output structure

There is always one primary maintenance structure.

• The purpose of this structure is to unambiguously classify the products by their characteristics.

• All features are defined in this structure. separated by purpose. This way the same attribute is available for multiple target systems and can be reused multiple times

• Attributes are created on basis of the features in this structure (dependent on the attribute type e.g. product, item...)

• Defines the allowed values

• Defines which attributes are mandatory

• can be classified on leef group only to be as specific as possible

• single classification to be as specific as possible and avoid conflicting lists of allowed values and features