Introduction
This Data Flow Specification (DFS) defines the end-to-end data flow required to meet the following requirements:
- ERP-xx Business Case
- etc.
The models below are designed for
- semantic tag - gl account
OperationalAcctgDocItem
- fixed assets (need all depreciation areas)
- Lease FX
- tax
- movements between balances
- cash flow (flows?) - maybe covered by GR rather
- SKF
- Headcount
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
| System | Code | Extractor Name | Purpose | Delta | Type | Frequency | Jira Ref | Extended fields | Texts |
|---|---|---|---|---|---|---|---|---|---|
S/4 x | I_GLACCOUNTLINEITEMRAWDATA | View does not implement the logic for extension ledgers (just basis ledgers) | Y | TD | continuous | there will be | |||
| S/4 x | I_LEDGERCOMPANYCODECRCYROLES | Per company the ledgers and currency roles | N | D | new company | ||||
| S/4 R | I_LEDGERSOURCELEDGER | Ledger mapping to source ledger | N | D | adhoc/never | ||||
| S/4 R | I_PLANNINGCATEGORY | Versions for plan data | Y | D | new versions | ||||
| S/4 R | I_GLACCOUNTHIERARCHY | GL Account hierarchy | N | H | changes | ||||
| S/4 R | I_SEMTAGGLACCOUNT | Per hierarchy/CoA (option for FArea) | N | D | changes | ||||
| S/4 R | I_FI_LEDGER | Leading ledger | N | D | never |
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.
| Type | Code | Tech Name | Logic | Potential Changes | Partitioning |
|---|---|---|---|---|---|
| TL | 1TL_ACDOCA | 1TL_S4HR_I_GLAccountLineItemRawData | Retain all 402 fields even though SAP Business Content has 60 fields less. As the BCT is based on SAP 2023, I assume that these are new fields | extensions | Source Ledger = 0L, CO, LG, LT, TX (will always be specified) Fiscal Year = I guess can be specified |
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.
| Type | Code | Tech Name | Logic | Potential Changes |
|---|---|---|---|---|
| TL | 2TL_ACDOCA | 2TL_HARM_I_GLAccountLineItemRawData | Persist after union for performance remove additional amount/quantity fields Perform any calculations likes tonnes conversion and potentially conversion to budget group currency | Set as Delta Capture (does not support Premium Outbound). Requires delete and recreate and you lose all the conversions |
| VR | 2VR_GL Acc Line Itm | 2VR_HARM_GLAccountLineItem | Changing name to replicate the corresponding CDS in S/4 Dates: cast to DATE NULL: set 26 columns to null (incld mainly consolidation and clearing items) - why null rather than remove? | functional currency? also set to null |
| TL | 2TL_Curr Role | 2TL_HARM_I_LedgerCompanyCodeCrcyRoles | Persist after union for performance | |
| VR | 2VR_Curr Role | 2VR_HARM_I_LedgerCompanyCodeCrcyRoles | Set 2 additional currency codes as NULL? | Remove the 8 currencies not used |
| VR | 2VR_Src Ledgr | 2VR_HARM_I_LedgerSourceLedger | No change | |
| VR | 2VR_Lede / Cur | 2VR_HARM_I_CoCodeLedgerSourceLedger | Join Ledger and currency roles views (left join n:n on ledger) | |
| VF | 2VF_GL Acc Line Itm v2 | 2VF_HARM_GLAccountLineItem V2 | Ledgers: Ledger, Source Ledger, company code Inner join n:n on compcode / source ledger - picking up all the available ledgers Calculations: derive when statistical assignments for WBS, Sales Doc, Order, Cost Centre | |
| VR | 2VR_Plan Cat | 2VR_HARM_I_PlanningCategory | ||
| VR | 2VR_Plan Cat2 | I_PlanningCategory_V2 | why | |
| VR | 2VR_GLActHier | 2VR_HARM_I_GLAccountHierDir | ||
| 2VR_GLActHier2 | 2VR_HARM_I_GLAccountHierDir_V2 | why | ||
| VR | 2VR_SemTagAccnt | 2VR_HARM_I_SemTagGLAccount | ||
| VD | 2VD_HARM_I_Ledger | Leading ledger | ||
| 2VR_HARM_GLAccountLineItemLeadingLedger | join on Leading Ledger |
Propagation Layer
| Type | Code | Tech Name | Properties | Logic | Potential Changes |
|---|---|---|---|---|---|
| VR | ActlPlnJournalEntryItemSemTag | Fact | Remove redundant measures Join ActPlan N:N SemTagGLAccount (filter for validity dates and excld FunctArea) | Can we reduce initial projection? | |
| ProfitLossSemanticTag | Fact | Create parameters for FinStatemtVersion and Category Reduce dimensions (need to align to our needs) Add associations | |||
| SemTag Leading Ledger | |||||
| JEI/Operation view | |||||
| Balance with movements | |||||
| Headcount |
Reporting Layer
| Type | Code | Tech Name | Logic | Potential Changes |
|---|---|---|---|---|
| MA | 4MA_PL_SemTag | ProfitLossSemanticTagKPIs | Measures: 19 restricted by Semantic tags and simple calculations Variables: FinStatemtVersion, Category, Date | |
| Balance with movements | ||||
| Assets | ||||
| Restructering | ||||
| HSE |
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)
| Report Field Description | SAP Table-Field Name / process | Comments / Calculation / Formula / Restriction dimensions and values | Aggregation of data | Example SAP field data |
| Notification Count | Process: constant 1 per notification row in unplanned projection | Counts maintenance notifications used in the unplanned side of the downtime fact. Supports: (a) Loss Driver # notifications per asset (ERP-1012) where required in dashboards, (b) general notification volume analysis. Implemented as 1 per row sourced from I_PMNotifMaintenanceData (notification grain). | SUM | 1 |
| Technical Availability % (optional) | SAC Calculated Measure: (AvailableTime - TotalUnplannedDowntime) / AvailableTime * 100 | High-level availability KPI. AvailableTime must be defined by business rule (e.g., 24h days in period, with or without planned windows). Not sourced from CDS. | CALCULATED |
Restricted Measures
tbd
Currency Conversions
tbd
Variables
| Field | Required/Optional | Scope | Default | Comment |
| Periods (Weeks / Months / Quarters) | Optional | Interval (Date or Fiscal Period) | Default = last xxxxx | Applied using CreationDate or CreationDateTime |
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)
| Report Field Description | SAP Table-Field Name / process | Comments / Calculation / Formula / Restriction dimensions and values | Aggregation of data | Example SAP field data |
| Notification Count | Process: constant 1 per record | Base measure for notification-level counting. | SUM | 1 |