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 and Down plan	124	672	9036	2 views, month, category
	Snapshot?					No request? Potentially just a version copy?
Item	Item Planning	Plan Project Cost(FEC)	669	2665	9035 / 1022	month, category, initiative?
	Business Case	Calculate Return on Investment Only Financial relevant projects Commentary	263		9105	Portfolio MD (defaults) Item MD P&L Cash Impacts Subsidies Calculations
	Scoring	Make comparable		need		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

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

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

Source System Extractors

System	Code	Extractor Name	Purpose	Delta	Build Jira Ref For Extension Information	Extended fields	Texts

The 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.

Inbound Layer

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

Harmonisation Layer

Type	Code	Tech Name	Logic	Potential Changes

Propagation Layer

Type	Code	Tech Name	Logic
VR	3VR_Bucket	2VR_HARM_I_ProjectPortfolioBucket
VR	3VR_Item	2VR_HARM_I_ProjectPortfolioItem	Join with long texts (excluding Z07) Create Odata connection to fill the master data required by SAC planning

Reporting Layer

If you want to show the external format and text in SAP Analytic Cloud instead of the internal format the modelling in the Analytic Model needs to be done like this example:

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