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. 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 - Standard Pattern

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

Tier 2 Master Data - Standard Pattern

Tier 3 Master Data - Standard Pattern

Exceptions

How to use this document

This document is designed to:

• Be an aid in to the initial design of a data flow for the reporting functional consultant
• Be the means of communication between the reporting functional consultant and the developer as to what is to be built
• Be the long term repository for the documentation of the actual technical build.

Fill in the document following the steps below and keeping close alignment with the SAP Analytics and Reporting Standards.

First, copy this template, copy the template data flow diagram inside it, replace the template DFD with the new DFD in the new document.

In DFD:

1. Lay out the spaces.
2. Populate the spaces with the tentative objects depicting object type with the appropriate box. (Build the entity relationship model).  Use a short, meaningful, code for the object name to keep the boxes small and the design flexible till complete.
   1. Be aware of and respect the colour coding for boxes as seen in the key at the top of the DFD.
   2. N.B. do not include master data objects in transaction data DFD unless they are actively joined to (i.e. not just used as attributes). MD objects have their own DFD.
   3. Where an object's data flow belongs in a different DFD (e.g. S2P consumes an object from O2C), just reference the object, don't include its full flow.
3. Once the data flow makes sense (i.e. will deliver the desired solution), populate the technical names for relevant objects in the boxes into the tables beneath the data flow diagram.  This allows you to add / change the names without having to reconfigure the diagram.

In the confluence document:

1. Update the details of any business logic  below the data flow diagram. Updates to be made according to the layer and type.

Please see the example DFD done for a fictional requirement that wishes to show original purchase order item and value alongside the PO history according to Purchase Order Creation date.