Material Classification

Any new/replacement/consolidation of material classification or changes to the R/3 material classification in term of format require the regeneration of the BI datasource. The character is identified from which material class and added in the datasource The datasource is activated and replicated in BI side and 1:1 transformation or routine is created to fetch the changed/new attribute values.

If it is a new attribute, a new global infoobject needs to be created from the template box upon approval from the Infoobject forum (agrees on the type, length and naming) and to be included as the regional material infoobject either as navigational or display attribute. The process chain is enhanced to automate the load of the new attribute.

If the new attribute is created as a navigational attribute, the infocube which contain data for reporting needs to have the navigational attribute activated. If it is used as a characteristic in the cube dimension, then the cube needs to be remodeled to include the new infoobject. The query is also changed to pull the new attribute from the cube to the reporting column.

One point to note when making decision on using dimension or navigational attribute is
if dimension attribute is used, there will be a need to delete the transactional data before master data can be deleted where else if the navigation attribute is used, you can delete the 'unclean' master data directly.

Transport of material classification to test, regression and production is to ensure the consistency but if the client is different, the datasource need to be regenerated directly in the system via CTBW.

A lot of time, there is a need to view snapshots of historical view. User might want to see the master data at that period of time. The most significant one is material master whereby they are new attributes and obsolete attributes over a period of time. The process of master data standardization across regional R/3 system require the changes on material master data attributes and the way it was reported as well.

Eg:
Material 123

2008 Jan

Attr1 - Yes
Attr2 - No
Attr3 - NA
Attr4 - Yes

July 2008

Att1 - Yes
Att2 - Yes
Attr3 - No
Attr4 - Yes

Jan 2009

Attr1 - No
Attr2 - Yes
Attr3 - No
Attr4 - Yes

Options:
1) Including those characteristic into the cube
2) time dependent navigational attributes and introduce the key dates in the query
3) Version dependent hierarchy

Option 1
Will show and sums up figures according to the historical master data even when the user wants to see the latest one

Option 2
Cant have two key dates in the query and the user cannot compare two previous snapshots, eg. if master data was brought in on 15.12.2007 and the second was brought in on 11.12.2008.

Option 3
Does not cater for a lot of characteristics and not all characteristics are parent-child node related


In scenario like this, most common approach is Option 1 but with another navigational attribute which represent the latest correct master data in the reporting infocube.


Most of the time when a product evolves , the R/3 system will need to create a new class for certain material group with new characteristics assign to it. This changes will require changes in BI as well. The main material infoobject has to be extended to take the new characteristics as its attribute which is populated in new infoobjects. The new material group also has to be included in any hardcoded product category or UOM derivation.