Introduction

This Data Flow Specification (DFS) defines the end-to-end data flow required to meet the following requirements:

In a perfect world, we would create a KPI once and share it, to ensure consistency.

If a KPI is only calculated in the Analytical Model, it will not be shared. Reasons for defining at this level are:

• Performance on aggregated data is better
• Some KPI's must be calculated pre aggregation eg price x quantity

Can remove the measures for alternate currency /quantity as we will not use these as per KDD047 Universal parallel Ledgers. But then how does this fit in with currency roles?

Reporting is done in tons so store rather than calc. Where if we dont persist again

Probably the same for value at bud rate. It has been decided that this will not be persisted but rather calculated.

Commentary will be added per model. This is not ideal as there is no leverage. 

GL Account Semantic Tags (Model)

Overview:

GL transactions grouped by GL Accounts as defined by a particular Account Hierarchy

Based on Business Content

Recreates the S/4 model in a more logical fashion that in S/4 (removes the hard coding in the CDS views)

Differs in some way to the Functional Area Semantic Tag model

Purpose:

Simplified reporting using semantic tags

This flow will be shared with other POD's

Notes:

Source System Extractors

Inbound Layer

No inbound field adjustments are applied. Standard technical fields (load date/time, source system) are retained as delivered.

Persist data as found in the source system CDS view. This should be including any extensions.

Any data sourced from both S/4 environments, will be created using delta capture and re-persisted in Harmonisation layer. Assumption is that this data can be in cold storage if available.

In the Business Content, some calculated fields are populated with Null values to make the model compatible with SAP S/4HANA release 2020. These fields will now be added in the 1TL object and mapped, removing the NULL calculation.

CDS View I_SemTagGLACcount from SAP S/4HANA provides the mapping between the G/L accounts and semantic tags. It is the key component of this model.

This CDS view does not have any key fields. The replication of data without key fields from CDS Views is not supported by the Replication Flow at moment. Instead the local table SAP_FI_IL_I_SemTagGLAccount is used in this model to support both SAP S/4HANA Cloud and SAP S/4HANA source systems. The inbound layer view SAP_FI_IL_SemTagGLAccount is based on this table.

Customer should perform the following activities after importing the content package:

• Create a remote table from CDS View I_SemTagGLAccount of the connected SAP S/4HANA system and replicate the data.

• Create a dataflow to populate the local table SAP_FI_IL_I_SemTagGLAccount from the remote table. (For SAP S/4HANA Cloud sources a conversion from Date to String Datatype is needed in the dataflow.)

or

• Replace the local table SAP_FI_IL_I_SemTagGLAccount with the remote table in the inbound layer view SAP_FI_IL_ SemTagGLAccount.

The Inbound layer view G/L Account with Semantic Target (IL) (SAP_FI_IL_ SemTagGLAccount) is based on the local table SAP_FI_IL_I_SemTagGLAccount and has some simple data type conversions like date conversion.

Harmonisation Layer

Both transaction data or master data that is not tier 1 will require a union between environments and re-persisted. This is to improve performance.

Propagation Layer

Reporting Layer

4MA_R2RGLR_SemanticTags

Supports:

• ERP-682 Tax
• ERP-1321 Corporate insurance

Includes technical details for:

• Post-aggregation calculations
• Restricted measures
• Time-based analysis and drill-through

Calculated Measures (Post Aggregation Calculations / exception aggregation etc)

Restricted Measures

tbd

Currency Conversions

tbd

Variables

Data access controls

4MA_R2RGLR_Account Balance & Movements

Supports:

• ERP-1564  Balances
•  cash flow

4MA_R2RGLR_Depreciation

Supports:

• ERP-293 - Depreciation Areas

Includes technical details for:

• Post-aggregation calculations in SAC (e.g., hours conversions, ratios, availability formulas)
• Restricted measures by breakdown / downtime flags and status
• Time-based analysis (malfunction start/end, creation dates) and drill-through to Maintenance Notification

Dimensions & Measures are defined in the Functional Specification under “Dimensions & Measures: Requirements View”; the analytical model exposes those fields at notification grain without pre-aggregation.

Calculated Measures (Post Aggregation Calculations / exception aggregation etc)

Outbound Layer