Purpose

The purpose of this document is to define the conversion approach to migrate the balance of active OPEX WBS from legacy system to S/4HANA, so Project manager is able to know the entire cost of its active OPEX project.

Only certain closed OPEX project types (e.g. R&I, Maintenance OPEX) that have cost in current year must also be migrated. 

For To-Be design, Internal order will be mapped to either to real or statistical OPEX WBS. Business must identify which I/O master data and balance that must be migrated. Then new real/statistical OPEX WBS will be created for these I/O and subsequently load its balance.

Group 1 (Go live 1 July 2028):

• Extract accumulated balances up to 31 Dec 2026
  • All the financial transactions posted of all open WBS Elements as of 31 Dec 2026 will be totaled into the one single value and then be posted to the relevant WBS Elements in S/4HANA. Then run settlement from WBS to Cost Center.
• Extract monthly balances from 1 Jan 2027 till 31 Dec 2027
  • All the financial transactions posted of all open WBS Elements from 1 Jan 2027 till 31 Dec 2027 will be totaled by month into the one single value and then be posted to the relevant WBS Elements in S/4HANA in each posting period. Then run settlement from WBS to Cost Center.
• Extract monthly balances from 1 Jan 2028 till 30 Jun 2028
  • All the financial transactions posted of all open WBS Elements from 1 Jan 2028 till 30 Jun 2028 will be totaled by month into the one single value and then be posted to the relevant WBS Elements in S/4HANA in each posting period. Only certain closed OPEX project types (e.g. R&I, Maintenance OPEX) that have cost in current year must also be migrated. Then run settlement from WBS to Cost Center.

 Group 2 (Go live 1 Jan 2029):

• Extract accumulated balances up to 31 Dec 2027
  • All the financial transactions posted of all open WBS Elements as of 31 Dec 2027 will be totaled into the one single value and then be posted to the relevant WBS Elements in S/4HANA. Then run settlement from WBS to Cost Center.
• Extract monthly balances from 1 Jan 2028 till 31 Dec 2028
  • All the financial transactions posted of all open WBS Elements from 1 Jan 2028 till 31 Dec 2028 will be totaled by month into the one single value and then be posted to the relevant WBS Elements in S/4HANA in each posting period. Only certain closed OPEX project types (e.g. R&I, Maintenance OPEX) that have cost in current year must also be migrated. Then run settlement from WBS to Cost Center.

Conversion Scope

The scope of this document covers the approach for converting active OPEX WBS element from Legacy Source Systems into S/4HANA.

All the relevant WBS Elements (after applying the approved relevancy rules) open as at end of last month before go live that have received primary and secondary transactions posted to the cost elements within the WBS Elements

• Primary transactions refer to original postings from all sources whether it is debit or credit.
• Secondary transactions refer to allocations from sources such as allocations from payroll, work orders, other WBS Elements or cost centers. These postings will be subject to any settlement rules set up in the individual WBS Element.

The scope of this document will therefore extract the settlement transactions from each individual WBS Element to provide a base for posting to the S/4HANA WBS Elements as at end of last month before go live.  The total of the transactions will be used to compare to the balance in the Cost Center that is used for settlement. The total of the settlement transactions will also be reconciled against the total costs posted to the WBS Element to ensure that all costs have been captured. 

The data from legacy system includes:

1. All OPEX WBS with status not equal to Closed (CLSD).
2. Only certain closed OPEX project types (e.g. R&I, Maintenance OPEX) that have cost in current year must also be migrated.

The data from legacy system excludes:

1. All OPEX WBS with status as Closed (CLSD).

Additional Information

Multi-language Requirement

Document Management

Legal Requirement

Special Requirements

Target Design

The technical design of the target for this conversion approach.

Data Cleansing

Conversion Process

The high-level process is represented by the diagram below:

Data Privacy and Sensitivity

Extraction

Extract data from a source into . There are 2 possibilities:

1. The data exists. connects to the source and loads the data into . There are 3 methods:
   1. Perform full data extraction from relevant tables in the source system(s).
   2. Perform extraction through the application layer.
   3. Only if ; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
2. The data does not exist (or cannot be converted from its current state). The data is manually collected by the business directly in . This is to be conducted using DCT (Data Collection Template) in

The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads

Extraction Run Sheet

Selection Screen

Data Collection Template (DCT)

DCT Rules

Extraction Dependencies

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 to make the data Target ready:

1. Perform value mapping and data transformation rules.
   1. Legacy values are mapped to the to-be values (this could include a default value)
   2. Values are transformed according to the rules defined in
2. 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

Transformation Rules

Transformation Mapping

Transformation Dependencies

Pre-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Load

The load process includes:

1. Execute the automated data load into target system using load tool or product the load file if the load must be done manually
2. Once the data is loaded to the target system, it will be extracted and prepared for Post Load Data Validation

Load Run Sheet

Load Phase and Dependencies

Configuration

Conversion Objects

Error Handling

Post-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• is in scope based on data design and any exception requested by business.

See also

Change log

Workflow history