Introduction
This Data Flow Specification (DFS) defines the end-to-end data flow required to meet the following requirements:
| Level | Process | Description | Jira Sty | Jira Mod | Migration | Details |
|---|---|---|---|---|---|---|
| Bucket | Bucket Planning | Top-down and Bottom-up planning | 124 | 672 | 9036 | 4 views, year, category |
Snapshot? | No request? Potentially just a version copy? | |||||
Item | Item Planning | Plan Project Cost(FEC) & FY Budget Request | 669 | 2665 | 9035 / 1022 | 2 views, month, category |
| Business Case | Calculate Return on Investment Only Financial relevant projects Commentary | 263 |
| 9105 |
| |
| Scoring | Make comparable | 2875 | Probably just a view in the DDFS rather than an AM Separate model (persist data for snapshots) | |||
| Prioritisation | Priority | Req 519 | ||||
| Item Retraction | Export to S/4 | 671 | Issues regarding the filter and locking | |||
| Item Snapshots | Change of Gate or variation | Req 879 | Quarterly, Variation, Gates, Adhoc | |||
| Item Automation | Quarterly or adhoc snapshot accuracy calc | Req 759 | Overwrite plan with actuals (business need, not reporting solution) mass update of scoring, update accuracy | |||
| Project | WBS Planning | Plan costs | 670 | 2664 | 1026 | Adding WBS and account |
| Reporting | Req 152 Req 760 |
All of the above is delivered by master data covered in the MDM DDFS.
We do not extract any transaction data from S/4, hence the Harmonisation layer is blank
The diagram below only shows the data that is planned in SAC
Source System Extractors
| System | Code | Extractor Name | Purpose | Delta | Build Jira Ref For Extension Information | Extended fields | Texts |
|---|---|---|---|---|---|---|---|
| S4HR | Auths | P_PPM_AUTHORIZATIONBYUSER | no | enable extraction | no | no | |
| S4HR | T_Scoring | /SYQ/T_SCORING | no | outstanding | no | no | |
| S4HR | T_RiskM | /SYQ/T_RISK_MAGNITUDE | Starting Risk Magnitude, Residual Risk Magnitude | no | outstanding | no | no |
| S4HR | T_RiskL | /SYQ/T_RISK_LKLHD | Starting Risk Likelihood, Residual Risk Likelihood | no | outstanding | no | no |
| S4HR | T_RegM | /SYQ/T_REG_MAGNITUDE | Regulatory Risk Magnitude | no | outstanding | no | no |
| S4HR | T_RegL | /SYQ/T_REG_LKLHD | Regulatory Risk Likelihood | no | outstanding | no | no |
| S4HR | T_RegT | /SYQ/T_REG_TIME_HORIZON | Regulatory Mandated Time Horizon | no | outstanding | no | no |
The Item and Bucket hierarchy will not be extracted but rather built in DSP via the Parent UUID. This will work perfectly for the SAC planning component but the DSP reporting component will need to be tested.
All of the above are considered as Tier 1 and only maintained in RoW
Inbound Layer
No inbound field adjustments are applied. Standard technical fields (load date/time, source system) are retained as delivered.
/SYQ/ replaced by SYQ
Harmonisation Layer
2VR_Auths → 2VR_HARM_SYQI_AuthorizationUser
Purpose:
Assigns Item UUID to authorised users where there is sensitive project. Will be read and added to ProjectPortfolioItem Read/Write fields
2VR_TScore → 2VR_HARM_SYQ_T_Scoring
Purpose:
Parameter table used in scoring
2VR_TRiskM → 2VR_HARM_SYQ_T_RiskM
Purpose:
Parameter table used in scoring
2VR_TRiskL → 2VR_HARM_SYQ_T_RiskL
Purpose:
Parameter table used in scoring
2VR_TRegM → 2VR_HARM_SYQ_T_RegM
Purpose:
Parameter table used in scoring
2VR_TRegL → 2VR_HARM_SYQ_T_RegL
Purpose:
Parameter table used in scoring
2VR_TRegT → 2VR_HARM_SYQ_T_RegT
Purpose:
Parameter table used in scoring
Propagation Layer
Join with long texts (excluding Z07)
Create Odata connection to fill the master data required by SAC planning
2VR_LeadLed → 3VR_PrjAct
Purpose:
Restrict to PPM relevant data
Filter:
where project <> ''
Comments:
Ensure we have commitments in this view
Data Migration approach:
Normally stored in a separate model, however, as this is seamless planning and the data will need to be amended along with new data, it will have to be loaded as normal data in the same model.
- Subject to change in planning process
- Needs to be displayed in the same version when planning
- potentially could identify using an audit trail
Comments:
Long texts are required from STXL
Types of projects:
Expenditure on capital (Capex), which always is managed via a project using PPM
Capital maintenance is assigned to a project
Operation expenditure (Opex) can be managed via PPM but does not have to be - eg finance only projects
Master data:
When attributes need to be planned, we will try and plan as measures rather than attributes
Scoring:
I feel this needs to be a separate model
- Financial driven projects read from the Business Case
3VR_Bucket - 2VR_HARM_I_ProjectPortfolioBucket
3VR_Item - 3VR_xxxxx_ProjectPortfolioItem
Purpose:
Read data from planning model to be used further in DSP
Source:
4MP_Item
Project Score is calculated according to 3 methodologies, determined by ; Financial, Risk or Regulatory.
- Retrieve Item Scoring Methodology from Investment Reason on PPM Item Planning Transaction Data
How is this score used (attribute or measure) - prioritisation as a number to be sorted
Calculation - sac planning action vs DSP persisted vs on the fly
| SAC Action | DSP persist | On the fly | |
|---|---|---|---|
Include value in snapshot - read score when snapping (better to persist)
I have split this into 3 views for simplicity, but they could be combined
3VR_IntFin - 3VR_xxxxx_IntFin
Purpose:
Calculate the Financial Intensity Index
Source Views:
2VR_Item (Actuals have been updated into Plan)
2VR_ItemSS (if we calculate on the fly)
5 * 2VR_TScore (1 for each parameter)
Filter:
2VR_Item - where Type = Financial and Version = 20
2VR_TScore - where CALCULATION = 'Financial Intensity Index'
Aggregation:
Project cost
Join:
Left outer to 2VR_TScore
Formula:
Intensity Index = Initial Starting Point + NPV / Cost Weighting * (NPV / Project Cost (FEC)) * MIRR Weighting / MIRR Comparison Rate * MIRR^MIRR Exponent
3VR_IntRisk - 3VR_xxxxx_IntRisk
Purpose:
Calculate the Risk Intensity Index
Source:
Filter:
Type = Risk
Views:
Union:
3VR_IntReg - 3VR_xxxxx_IntReg
Purpose:
Calculate the Regulatory Intensity Index
Source:
Filter:
Type = Regulatory
Views:
Union:
3VR_Score - 3VR_xxxxx_Score
Purpose:
Project Score is calculated according to 3 methodologies, determined by ; Financial, Risk or Regulatory.
- Retrieve Item Scoring Methodology from Investment Reason on PPM Item Planning Transaction Data
How is this score used (attribute or measure) - prioritisation as a number to be sorted
Calculation - sac planning vs DSP (union of 3 different views)
Include value in snapshot - read score when snapping (better to persist)
Source:
Views:
Union:
Reporting Layer
4MP_Item
Purpose:
This is for planning
Functional Spec:
ERP-2665 Data Model - PPM Items
Comments:
Include live data 3VF_PrjAct (must be exposed for consumption)
Outbound Layer
When retracting, you cannot filter on the company code, even if in the model, as restricted to the fields in the API.
Options: play with having 2 fin view types which can be corrected on the API mapping.
Maybe the guids have a number range sequence

