| Status | |
|---|---|
| Owner | |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
Purpose
The purpose of this document is to define the conversion approach to create Template Project in S/4 HANA.
As per Syensqo design: Templates Projects consists of both a Project definition and/or WBS elements. In Syway, these Templates are created as Operative Projects templates starting with letter T, these are not STANDARD Projects and Standard WBS elements. Once created, the template project status is locked.
There will be 2 types of Template Project Definitions
- Template Project definition assigned to Item types - Used to create Project structure automatically from PPM item.
- Template Project Definition which are not assigned to item types - Used to create sub-hierarchy of WBS on an existing project rather than creating wbs element individually
Project Templates can be created for any of the
ZPS0001 | CAPITAL/ Operational Expense |
ZPS0002 | Operational Expense |
ZPS0003 | Statistical Expense |
ZPS0004 | Intercompany Recharges |
ZPS0005 | Provisional Expense |
Applicable Project code as per design
Project ID | Description |
A | Coding Mask for Capital Projects |
E | Coding Mask for Internal/ Operational Projects |
R | Coding Mask for R&I Projects |
T | Coding Mask for Project Templates |
Conversion Scope
The scope of this document covers the approach for converting active Template Project from Legacy Source Systems into S/4HANA following the Template Project Master Data Design Standard.
The scope of this document covers the approach for converting active Project Definition from Legacy Source Systems into S/4HANA following the Master Data Design Standard for Template Projects.
Scope include:
- Project definitions and wbs elements to be assigned to PPM item types
- Template Project Definition which are not assigned to item types - Used to create sub-hierarchy of WBS on an existing project rather than creating wbs element individually
The data from legacy system includes:
All the projects below will be migrated from legacy source systems (PF2 and WP2) into S/4HANA –
- ??? Template projects
The data from legacy system excludes:
- Templates linked to excluded controlling areas, company codes, plants
List of source systems and approximate number of records
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
PF2 and WP2 | S/4HANA | |||
DCT | ||||
Additional Information
Multi-language Requirement
N/A
Document Management
N/A
Legal Requirement
N/A
Special Requirements
N/A
Target Design
With Functional input, document the technical design of the target fields that are in the scope of this document.
The technical design of the target for this conversion approach.
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
| PROJ | PSPID | PS_PSPID | Project definition | CHAR | 24 | Mandatory |
| PROJ | POST1 | PS_POST1 | PS: Short description | CHAR | 40 | Mandatory |
| PROJ | STSPR | PS_STSPR | WBS status profile | CHAR | 8 | Mandatory |
| PROJ | VBUKR | PS_VBUKR | Company code | CHAR | 4 | Mandatory |
| PROJ | VKOKR | PS_VKOKR | Controlling area for the project | CHAR | 4 | Mandatory |
| PROJ | PWHIE | PS_PWHIE | WBS currency (project definition) | CHAR | 5 | Mandatory |
| PROJ | PLFAZ | PS_PLFAZ_CHG | Project planned start date | DATS | 8 | Mandatory |
| PROJ | VGPLF | PS_VGPLF | Planning method for project basic dates | NUMC | 1 | Mandatory |
| PROJ | EWPLF | PS_EWPLF | Planning method for project forecast dates | NUMC | 1 | Mandatory |
| PROJ | PROFL | PROFIDPROJ | Project Profile | CHAR | 7 | Mandatory |
| PROJ | BPROF | BP_BPROFIL | Budget Profile | CHAR | 6 | Mandatory |
| PROJ | BESTA | PS_BESTAND | Project Stock | CHAR | 1 | Mandatory |
| PROJ | SCOPE | Object Class | Mandatory | |||
| PROJ | XSTAT | PS_XSTAT | Statistical WBS element | CHAR | 1 | Conditional |
| PROJ | SCPRF | PS_SCHDPRF | Profile for WBS scheduling | CHAR | 12 | Mandatory |
| PROJ | PPROF | BP_PPROFIL | Planning Profile | CHAR | 6 | Mandatory |
| PROJ | PLINT | PLINT | Indicator for Integrated Planning | CHAR | 1 | Mandatory |
| PROJ | SCHTYP | PS_SCHED_TYPE | Scheduling scenario | CHAR | 1 | Mandatory |
| PROJ | FUNC_AREA | FKBER | Functional Area | CHAR | 16 | Mandatory |
| PRPS | POSID | PS_POSID | WBS element ID | CHAR | 24 | Mandatory |
| PRPS | POST1 | PS_POST1 | PS: Short description | CHAR | 40 | Mandatory |
| PRPS | PBUKR | PS_PBUKR | Company code for WBS element | CHAR | 4 | Mandatory |
| PRPS | PKOKR | PS_PKOKR | Controlling area | CHAR | 4 | Mandatory |
| PRPS | PRART | PS_PRART | Project Type | CHAR | 2 | Mandatory |
| PRPS | PLAKZ | PS_PLAKZ | Planning element | CHAR | 1 | Conditional |
| PRPS | BELKZ | PS_BELKZ | Account assignment element | CHAR | 1 | Conditional |
| PRPS | FAKKZ | PS_FAKKZ | Billing element | CHAR | 1 | Conditional |
| PRPS | PWPOS | PS_PWPOS | Currency | CHAR | 5 | Mandatory |
| PRPS | SCOPE | SCOPE_CV | Object Class | CHAR | 2 | Mandatory |
| PRPS | XSTAT | PS_XSTAT | Statistical WBS element | CHAR | 1 | Conditional |
| PRPS | IMPRF | PS_ZSCHM | Investment Profile | CHAR | 7 | Conditional |
| PRPS | EEINH | PS_EEINH | Unit of measure | CHAR | 3 | Mandatory |
| PRPS | FUNC_AREA | FKBER | Functional Area | CHAR | 16 | Mandatory |
| PRPS | PSPHI | PSPID | Current number for project | CHAR | 24 | Mandatory |
| PRPS | STUFE | PS_STUFE | Level in Project Hierarchy | IN1 | 3 | Mandatory |
| PRPS | LEFT | PS_POSID | WBS_LEFT | CHAR | 24 | Mandatory |
| PRPS | UP | PS_POSID | WBS_UP | CHAR | 24 | Mandatory |
| PRPS | ZX01 | CAPEX/ OPEX Indicator | CHAR | 10 | Mandatory |
Data Cleansing
All data cleansing should take place in the data source system as defined in this document, unless system limitations prevent it.
If data cleansing is managed outside of the source system (e.g. Syniti Migrate, 3rd Party Vendor, DCT), the necessary documentation must be produced and appended to this deliverable for sign-off.
| ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
Conversion Process
The high-level process is represented by the diagram below:
Summarize High-Level Process. Include diagrams, where applicable. Include information supporting details of Extract, Transform and Load specific to the Data Object
Data Privacy and Sensitivity
N/AExtraction
Extract data from a source into Syniti Migrate. There are 2 possibilities:
- The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. There are 3 methods:
- Perform full data extraction from relevant tables in the source system(s).
- Perform extraction through the application layer.
- Only if Syniti Migrate; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
- The data does not exist (or cannot be converted from its current state). The data is manually collected by the business directly in Syniti Migrate. This is to be conducted using DCT (Data Collection Template) in Syniti Migrate
The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads
Extraction Run Sheet
| Req # | Requirement Description | Team Responsible |
|---|---|---|
Selection Screen
If applicable, this section will give the details on any selection screen parameters, including the parameter type, that are required to be entered to ensure consistent data extracts.| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
Data Collection Template (DCT)
Target Ready Data Collection Template will be created for Template Project data with exception of some fields which require transformation as mentioned in the transformation rule.Template Project DCT Rules
| Field Name | Field Description | Rule |
|---|---|---|
| Project Level | ||
| PROJ_PSPID | Project definition | Unique Identifier for the Project template, manually generated via coding mask starting with "T-000000". |
| PROJ_POST1 | PS: Short description | Template name entered manually. |
| PROJ_VBUKR | Company code | Represents legal entity . Refer configuration table field T001-BURKS for data validation. The project template will have the default company code 1000. |
| PROJ_PROFL | Project Profile | The profiles contain default values and control parameters for processing objects and functions in the Project System. This field is maintained on the templates. The templates mapped to PPM item are assigned to project profile ZPS0001 and ZPS0002 Other templates will be assigned the project profiles ZPS0003, ZPS0004, ZPS0005. Project template "Detailed Engineering and construction" is not mapped to a PPM item but is assigned to project profile ZPS0001 . |
| PROJ_XSTAT | Statistical WBS element | Indicator to specify whether a WBS element is only for statistical purposes or whether it may carry actual costs. Mandatory for Statistical Projects with Project profile ZPS0003. Derived from the profile ZPS0003. |
| PROJ_FUNC_AREA | Functional Area | The Functional Area allows classification of project-related costs by function. Defined on the project template, and WBS elements will inherit the value. For project templates linked to Item Types Z001, Z002 & Z003 the Functional Area will be "IS". For project templates linked to Item Types Z004, Z005, Z006 & Z007 the Functional Area will be "R&I". For project templates linked to Item Types Z008 & Z009 the Functional Area will be "IT" |
| WBS Level | ||
| POSID | WBS element ID | Unique Identifier for the WBS Element template as per project coding mask. Starts with "T" |
| POST1 | PS: Short description (1st text line) | 40 character description of the WBSE template |
| PBUKR | Company code for WBS element | Represents legal entity and inherited from the Project Definition. Refer configuration table field T001-BURKS for data validation. The project template will have the default company code 1000. |
| PRART | Project Type | It is an attribute that serve as classification field that help to define the nature, purpose, and governance of a WBS element. They are useful for reporting, controlling, and compliance alignment. Refer configuration table field TCJ1-PRART for allowed values. Project Type will be mainatined as per rules defined in Appendix |
| BELKZ | Account assignment element | This indicator enables financial posting on the WBS element. It will be checked in below conditions: 1. Template WBS elements linked to DP of Item types Z001- Z009 will have AA Blank on L1 and L2 WBS 2. Template WBS elements for linked to DP of Item types Z010, Z012, Z013, Z014 will have AA active on L2 WBS 3. Template not linked to Item type but Project Profile = ZPS0001 will only have AA Active from L3 and beyond 4. Templates not linked to item type but project Prfoile = ZPS0003, ZPS0004, ZPS0005 will have AA active on all levels |
| IMPRF | Investment Profile | Investment Profile on WBS element is used to enable auto generation of AuC w.r.t. predefined asset class. Applicable to only those Templates that are not linked to Item type but Belonging to Project profiles = ZPS0001. Mandatory on Template WBS where Level = 3 and Capex/OPex indicator = Capex. Refer to Appendix. |
| FUNC_AREA | Functional Area | For template WBS linked to Item Types Z001, Z002 & Z003 the Functional Area will be "IS". For template WBS linked to Item Types Z004, Z005, Z006 & Z007 the Functional Area will be "R&I". For template WBS linked to Item Types Z008 & Z009 the Functional Area will be "IT"For WBS elements governed by project profiles ZPS0004 & ZPS0005, this field will be maintained manually or derived from Responsible Cost Center. |
| PSPHI | Current number for project | Project ID assigned to the WBS elements in the project template. |
| STUFE | Level in Project Hierarchy | Level of the WBS element within the template. |
| LEFT | WBS_LEFT | This field represents the left-adjacent WBS element in the same hierarchy level required for navigating sibling relationships within a WBS hierarchy. |
| UP | WBS_UP | This field represents the immediate superior WBS element (parent node) required for establishing parent-child relationships in the WBS hierarchy. |
| ZX01 | CAPEX/ OPEX Indicator | This field identifies expense is CAPEX or OPEX. It is maintained on the project template's WBS elements. - For project profile ZPS0001 this field will not be maintained on project template. - For project profiles ZPS0002 & ZPS0003 this field will be set to OPEX on the project template. |
Extraction Dependencies
List the steps that need to occur before extraction can commence
| Item # | Step Description | Team Responsible |
|---|---|---|
Transformation
The Target fields are mapped to the applicable Legacy field that will be its source, this is a 3-way activity involving the Business, Functional team and Data team. This identifies the transformation activity required to allow Syniti Migrate to make the data Target ready:
- Perform value mapping and data transformation rules.
- Legacy values are mapped to the to-be values (this could include a default value)
- Values are transformed according to the rules defined in Syniti Migrate
- Prepare target-ready data in the structure and format that is required for loading via prescribed Load Tool. This step also produces the load data ready for business to perform Pre-load Data Validation
Transformation Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
Transformation Rules
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
Transformation Mapping
Use the exact name and reference this section in the “Transformation rules” above| Mapping Table Name | Mapping Table Description |
|---|---|
Transformation Dependencies
List the steps that need to occur before transformation can commence| Item # | Step Description | Team Responsible |
|---|---|---|
Pre-Load Validation
Project Team
The following pre-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Business
The following pre-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Load
The load process includes:
- Execute the automated data load into target system using load tool or product the load file if the load must be done manually
- Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation
Load Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
Load Phase and Dependencies
Identify the phase as to “when” the load for this object will occur. <Pre-Cutover, Cutover, Post Cutover> and list the steps that need to occur before the load can commence
Configuration
List the Configurations required before loading can commence
| Item # | Configuration Item |
|---|---|
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| list the exact title of the conversion object of only the immediate predecessor – this will then confirm the DDD (Data Dependency Diagram) | |
Error Handling
The table below depicts some possible system errors for this data object during data load. All data load error is to be logged as defect and managed within the Defect Management
| Error Type | Error Description | Action Taken |
|---|---|---|
Post-Load Validation
Project Team
The following post-load validations will be performed by the Project Team.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Business
The following post-load validations will be performed by the business.Completeness
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Accuracy
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Key Assumptions
- Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
- Data Object is in scope based on data design and any exception requested by business.
Any additional key assumptions.
See also
Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.