You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Introduction

This document details the technical flow for master data objects.  The approach is different to transaction data documentation as a 'cookie-cutter' approach is taken meaning that the master data design is the same for most objects. Separate data flow documentation is BY EXCEPTION only: I.e.

  • Where a master data object follows the standard approach, it does NOT need to be defined individually.
  • If an object does not need certain aspects of the core design, i.e., some aspect of the complete standard design (e.g. it has no texts or hierarchies or MD), it can still be considered a standard pattern.

The table in Appendix 1 IS completed for master data objects following the standard design.  This links the MD object to the source CDS views / datasources.

If a master data object does not follow a standard pattern, it will be documented under the exceptions heading.  E.g. Business partner may need to have additional logic to include identifications types, such as Dun and Bradstreet number.  This object will need its own documentation.

Standard Patterns

In SyWay, there are three types of master data:

Tier 1: Master data is maintained centrally.  The same master data will exist in every S/4 system.  Build master data objects based on RoW source tables.

Tier 2 with number ranges: Master data is defined centrally and will exist in unique number ranges in each system but no single system contains all the data. Create data flows from each system to a single table in the EDW space and build master data objects on these tables.

Tier 3 and Tier 2 without number ranges:  Master data is maintained separately in each S/4 system and there is a risk of MD key clashes.  Create data flows from each system to a single table in the EDW space, add source system to the key of this table and then build master data objects on these tables.

These tiers will have slightly different approaches:

Tier 1 Master Data

It is expected that most master data objects used in Datasphere will fall into the Tier1 category:

Key points to note:

The MD object is created in the SEDW_ space. This approach allows an easy pivot to the Tier 2 pattern if it is found that this is necessary.

Tier 2 Master Data - Standard Pattern

Key point to note: Data from the 3 systems is brought together into a single 2TL table via data flows for consumption by the 2VR views.  The 2TL table does NOT need to have source system in the key.

Tier 3 Master Data - Standard Pattern

This is the same as the Tier 2 pattern with the exception that the source system field is added to the key of the 2TL tables to prevent master data 'collisions'. (I.e. where the same MD key exists with different master data values in the different systems).

Exceptions

DFD and logic to be created with details as to why there is the exception.  

Business Partner

...

Product

...

Appendix 1: Standard Pattern Extraction Information

Master data objectMaster data extractorTextHierarchyHierarchy textHierarchy NodeHierarchy Node Text
CostCenterI_COSTCENTERI_COSTCENTERTEXTI_COSTCENTERHIERARCHYI_COSTCENTERHIERARCHYTI_COSTCENTERHIERARCHYNODEI_COSTCENTERHIERARCHYNODET


















  • No labels