Introduction
This Data Flow Specification (DFS) defines the end-to-end data flow required to meet the following requirements:
| Sub area | Model | Purpose | Notes | Jira |
|---|---|---|---|---|
| Financial Ledger Reporting | Semantic Tags (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) | This model provides all journal entry details. Organizational entities such as Company Code, Profit Centre, Cost Centre, Business Area, Functional Area, Financial dimensions like Ledger, G/L Account, Segment, Financial Document Type, Posting Key, Debit/Credit Code, are available in this data model. The model provides a source ledger as well as all the ledgers that apply to the relevant company codes. This model maps the journal entries to the semantic tags defined based on G/L Accounts. The semantic tags based on functional areas are not considered in this model. Differs in some way to the Functional Area Semantic Tag model | Incld Headcount, Plan | Tax |
| AR/ AP | Operational Acctg Documents | The Operation Accounting Document item view provides details of an operational accounting document item (sourced from BSEG) like clearing document details, payment data, and tax data. The model can be used as the foundation of accounts receivable and accounts payable analysis, such as total payables and receivables, overdue receivables and payables, and future receivables. | Leading ledger only | |
| Fixed Assets | fixed assets (need all depreciation areas) | |||
| Lease FX | ||||
| Movements between periods | movements between balances (look at stock, treasury and Group Reporting for inspiration) | |||
| cash flow - maybe covered by GR rather | ||||
| Statistical Key Figures | SKF | |||
| Group Reporting | cash flow | |||
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.
Source System Extractors
| System | Code | Extractor Name | Purpose | Delta | Type | Frequency | Jira Ref | Extended fields | Texts |
|---|---|---|---|---|---|---|---|---|---|
S/4 x | ACDOCA | I_GLACCOUNTLINEITEMRAWDATA | View does not implement the logic for extension ledgers (just basis ledgers) | Y | TD | continuous | there will be | ||
| S/4 x | BSEG | I_OPERATIONALACCTGDOCITEM |
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 |
| TL | 1TL_BSEG | 1TL_S4HR_I_OperationalAcctgDocItem | Adds flag for cleared, based on date |
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 Requires delete and recreate and you lose all the conversions |
| VR | 2VR_GLAccItm | 2VR_HARM_GLAccountLineItem | Changing name to replicate the corresponding CDS in S/4 Dates: cast to DATE | Could I combine with the next level? Would love to add XREF from BSEG |
| VF | 2VF_GLAccItmV1 | 2VF_HARM_GLAccountLineItem V1 | I_LedgerSourceLedger joined to I_LedgerCompanyCodeCrcyRoles to provide all the ledgers available to a company code This has the effect of exploding the rows to ensure that all ledgers are created for every source ledger Calculations: derive when statistical assignments for WBS, Sales Doc, Order, Cost Centre | pic shows as relational, sap is fact Why would i add the ledgers and then share , only for others to then filter to leading ledger? assume better to share base model |
| TL | 2TL_BSEG | 2TL_HARM_I_OperationalAcctgDocItem | Persist after union for performance |
|
| VR | 2VR_HARM_I_OperationalAcctgDocItem | Adds flag for cleared, based on date |
|
Propagation Layer
Only at this layer will we add additional datasets like plan and headcount
| Type | Code | Tech Name | Logic | Potential Changes |
|---|---|---|---|---|
| 2VR_ActPlnItm | Union with the plan data | |||
| VF | 3VF_AcPlSemTag | ActlPlnJournalEntryItemSemTag | Remove redundant measures Join ActPlan N:N SemTagGLAccount (filter for validity dates and excld FunctArea) | Can we reduce initial projection? Need to add headcount somewhere, maybe here? |
| VF | 3VF_PFSemTag | ProfitLossSemanticTag | Create parameters for FinStatemtVersion and Category Reduce dimensions (need to align to our needs) Add associations | |
| SemTag Leading Ledger | ||||
| VR | 3VR_LeadLed | 2VR_HARM_GLAccountLineItemLeadingLedger | join on Leading Ledger | this is the view in question regarding adding ledgers and then removing |
| JEI/Operation view | ||||
| Balance with movements | ||||
| Headcount |
Reporting Layer
| Type | Code | Tech Name | Logic | Potential Changes |
|---|---|---|---|---|
| MA | 4MA_PL_SemTag | 4MA_R2RGLR_SemanticTags 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 |
|---|---|---|---|---|
Inverted amount | Amount In Global Currency * -1 | Calculated | ||
Amortization of Intangible Asset | Inverted amount when Semantic Tag = 'AMORINASST' | Restricted | ||
COGS | Inverted amount when Semantic Tag = 'RECO_COS' | Restricted | ||
Depreciation of Tangible Assets | Inverted amount when Semantic Tag = 'DPRTASSET' | Restricted | ||
Gross Revenue | Inverted amount when Semantic Tag = 'GROSS_REV' | Restricted | ||
Income Tax | Inverted amount when Semantic Tag = 'INCOMETAX' | Restricted | ||
Net Income | Inverted amount when Semantic Tag = 'PL_RESULT' | Restricted | ||
Net Revenue | Inverted amount when Semantic Tag = 'RECO_REV' | Restricted | ||
Employee Expense | Amount in Global Currency when Semantic Tag = 'EMPLEXP' | Restricted | ||
Operating Expense | Inverted amount when Semantic Tag = 'OPEREXP' | Restricted | ||
Recognized Revenue | Inverted amount when Semantic Tag = 'RECO_REV' | Restricted | ||
Gross Profit | Recognized Revenue + COGS | Calculated | ||
Gross Margin | (Gross Profit / Recognized Revenue) * 100 | Calculated | ||
Total Operating Expense | COGS + Operating Expense | Calculated | ||
Operating Profit | Recognized Revenue + Total Operating Expense | 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 |