How to use this document

Please see the SAP Analytics Approach document, section 'Documentation' for more information about the context of 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.

Source System Extractors

Standard extractors do not need to be documented unless extended.

Where custom extractors  / extensions are required, reference the FSD for that enhancement.

Inbound Layer

Inbound layer objects only need documentation if some field adjustment is made (over and above the standard load date / time and source system stamp).

1TL_S4Hx_C_PURCHASEORDERDEX

Field XYZ converted to date. 

Field ABC converted from BIGINT to... 

Harmonisation Layer

Every table will have it's own harmonization view.  This only needs to be documented if field adjustments are required. E.g. Conversion of data field / type.

Where actions are performed to improve reusability, e.g. joining header and item tables, details of the join (left outer, which is left, which is right, fields to join with, cardinality etc) should listed.

Each node inside the view will appear as a heading 3 in this document detailing what it does and, if not obvious, why.

2TL* Tables

Each 2TL* table in the Harmonisation layer will be populated from the corresponding 1TL* tables for each source system (RoW and China).

A Source System Identifier will be included as part of the primary key in the 2TL* tables to uniquely distinguish records originating from different source systems.

2VD_PurchaseOrderItem

A dimension view will be created joining 2VR_S4HARM_C_PurchaseOrderDex and 2VR_S4HARM_C_PurchaseOrderItemDex. The join will be an inner join based PO Document Number and Source System Identifier. All unique and relevant attributes from both header and item views will be included in the output.

Calculation

Calculated measure: CM_PRICE = Value / Quantity. (Ubiquitously true, reusable change made at lowest level possible).

2VR_S4HARM_POHdrItm

Join

Purpose: Join PO header and item to create reusable view at item level that contains all fields from PO header

LHS: 2VR_S4H_C_PurchaseOrderDex

RHS: 2VR_S4H_C_PurchaseOrderItemDex

Join Field: POHeader to POHeader

Join type: Left outer join

Cardinality: 1: Many

Projection

Remove fields that occur in both PO Header and Item views leaving fields from PO Header side.

Propagation Layer

3VR_S2PP2R_POHdrItm

Calculation

A line item level calculation which applies specific business rules that are owned by the POD would be added here.

3VR_S2PP2R_POHisAcc

Join

Purpose: etc

Join

Purpose: etc

Join

Purpose: etc

Calculation

Calculated measure: CM_DocItemValue = DocQuantity * CM_PRICE

3VF_S2PP2R_POHisAcc

Union

Purpose: To bring in values from PO level alongside lower level granularity documents

Associations to master data

List objects where material master associations are to be made.

Calculated Measures (Pre-Aggregation Calculations)

Reporting Layer

4VA_S2PP2R_POHisAcc

Link to FSD (Each Analytic model should have its own FSD).

Include technical details for: 

Calculated Measures (Post Aggregation Calculations / exception aggregation etc)

Restricted Measures

Detail restrictions

Currency Conversions

Detail rate type, from currency

Variables

Data access controls

Outbound Layer