Scenario
ItelO has concerns about the master data maintenance of employees. A rough estimate is 10.000 employees, who are assigned to 20 organizational units and three company codes. Is there a way to minimize the effort of maintenance, instead of storing the company code for each of the 10,000 employees?
ItelO also wonders how SAP BW/4HANA can provide up-to-date master data values when changes are made in the source system.
Another concern regarding master data is the use of Business Partner. How can the system distinguish between the roles of a buyer and a supplier, without duplicating the storage?
Transitive Attributes
Considering the scenario, 10,000 employees are assigned to 20 organizational units and three company codes. However, the company code only depends on the organizational unit. Instead of storing the company code for each of the 10,000 employees, it is sufficient to store the organizational unit of each employee. Then, the company code of each organizational unit can be derived.
This can be set up using transitive attributes.
How does it work with InfoObjects? In SAP BW/4HANA, you can switch on Transitive Attributes for InfoObject characteristics with attributes. Thus, you can enhance your data model with the attributes of your display attributes or navigation attributes. These can then be defined as display-only attributes or as ready for navigation.
You find the maintenance function of the feature in the context menu of the Display and Navigation Attributes pane of the Attributes tab, in the InfoObject screen.
Note
The SAP BW/4HANA concept of transitive attributes is limited to one step (from the first-level attribute, for example, the organizational unit; to the transitive attribute, for example, company code.) An attribute of the transitive attribute, for example, the country of the company code, cannot be made available to the basic characteristic; for example, employee. One solution is to load the country information as an attribute of the organizational unit, which can then becomes a transitive attribute of the employee.Virtual Master Data
Another requirement that's mentioned in the scenario is up-to-date master data values. For this scenario, you can use virtual master data for an InfoObject by using an SAP HANA Calculation View. You enable this with setting Read Access Type to "SAP HANA View" in an SAP BW/4HANA InfoObject.
This offers the following advantages:
Existing SAP HANA Information Models are exposed and usable as virtual master data (virtual navigation attributes and texts) in SAP BW/4HANA.
Changes in the underlying tables are immediately reflected without latency.
Higher levels of transitive attributes can be modeled (attributes of attributes of attributes).
Transitive attributes can be made available without offering the intermediate attribute.
No data staging of SAP HANA master data is required.
By using SAP HANA Calculation views, attributes of attributes can be derived by joins. There's no limit to the number of joins.
If the relationship between characteristic and attribute is stable, there is a different way to model a hierarchy of attributes. If the first two letters of a product number determine its type, you can use a formula in an SAP HANA Calculation view to derive the type of the product. If further letters of the product number define lower level product groups, a hierarchy of product attributes can be derived.
Caution
However, this concept is only useful if you are sure that the assignment is stable. For instance, if it's based on a chemical or physical relationship, or if the product ID is always a combination of type, material and color, and a new type or color requires a new product ID.Reference Characteristics
Another scenario regarding master data is the use of Business Partner. How can the system distinguish between the roles of buyer and supplier without duplicating the storage? In this case, and also for other characteristics, such as Profit Center, reference characteristics can be defined.
Reference characteristics use the master data of a referenced characteristic.
If the list of all attributes and the content is the same in both roles, and you receive transactional record information about both roles, the concept of reference characteristics can be used. This means that there is one storage for the InfoObject business partner, and the business partner roles (0SOLD_TO, 0PAYER) are read from the common master data list. Usually it's not an issue if the common list (business partner master data) contains more values than are needed. For this model, no compounding is needed.
The following table is an example of a reference characteristic U00_CHBY referenced to P_EMPL. It shows which changes are possible.
Changes to Reference Characteristic U00_CHBY, Referencing to Referenced Characteristic P_EMPL
| Changes to Reference Characteristic U00_CHBY | Possible? |
|---|---|
| Change the description of U00_CHBY | Yes |
| Make U00_CHBY authorization-relevant | Yes |
| Turn texts on for U00_CHBY | No |
| Make hierarchies version dependent | No |
| Remove an attribute | No |
Check attribute 0D_NW_ORGU (which is a navigational attribute of P_EMPL) as a navigational attribute. | Yes All attributes, which are checked as navigational attributes in the referenced characteristic (P_EMPL) are by default not checked as navigational attributes in the reference characteristic (U00_CHBY), but can be optionally checked as navigational attributes in the reference characteristic (U00_CHBY) |
| Change attribute 0D_NW_USER (which is a display attribute of P_EMPL) to a navigational attribute | No |
| Turn off transitive attributes | No |
| Turn on transitive attributes | No |