The purpose of this document is to define the conversion approach to migrate the balance of Capex Project/WBS from legacy system to S/4HANA, so the Project owner and Finance controllers are able to know the total cost of CAPEX Project in scope.
There are 2 group go-live as below:
- Group 1 go-live (1 July 2028) (Source System: PF2)
- Group 2 go-live (1 Jan 2029) (Source System: WP2)
Note: There is possibility to shift into 1 go live date, this option is currently still being considered.
Please refer to column "Company Code (As Is)" and "Group for Go-Live" in Enterprise Structure Catalog - Google Sheets (worksheet 10. Company code), to know which company codes fall under which Group Go live.
Relevancy rules:
Below are the criteria of CAPEX projects that are in scope. This document covers the approach for migrating the balance of CAPEX Projects below for the company codes in scope from Legacy Source Systems into S/4HANA:
- Active CAPEX Project/WBS as per cutover date (i.e. 30 June 2028 for Grp 1 & 31 Dec 2028 for Grp 2)
- Closed CAPEX Project/WBS that have cost in current year (From a portfolio level perspective, there needs to be full current year costs to be able to track against the annual budget allocation)
Conversion specs 1026 will provide the list of the WBS CAPEX that meet the above criteria.
The relevancy rules for this object will follow the relevancy rule in conversion specification 1026 (WBS - CAPEX, OPEX, Statistical) in migrating the balance of CAPEX projects as below:
Group 1 go live (1 July 2028) to migrate the above WBS for:
- Accumulated balance up to 31 Dec 2026. (Life to Date) (Statistical Posting). Project users can only see the total cost for WBS, but not the AUC balance.
- Accumulated balance (AUC) up to 31 Dec 2027. (Actual posting and Reversal of Statistical Posting),
- AUC Value >0 actual posting and reversal of statical
- AUC Value =0 2027 expenses will be posted as statistical no reversal required.
- Monthly balance from 1 Jan 2028 till 30 June 2028. (Actual posting by original G/L ). The monthly balance is required for forecasting purpose, monthly trend report and sleeping AUC report.
Group 2 go live (1 Jan 2029) to migrate the above WBS for:
- Accumulated balance up to 31 Dec 2026. (Life to Date) (Statistical Posting). Project Users can only see the total cost for WBS, but not the AUC balance. Note: The rationale why statistical posting is required so only 1-year worth Trial Balance data (Jan-Dec 2028) for Group 2 is required to be loaded. Please refer to "Trial Balance Extraction" below for more detail.
- Accumulated balance(AUC) up to 31 Dec 2027. (Actual posting and Reversal of Statistical Posting)
- AUC Value >0 actual posting and reversal of statical
- AUC Value =0 2027 expenses will be posted as statistical no reversal required.
- Monthly balance from 1 Jan 2028 till 31 Dec 2028. (Actual posting). The monthly balance is required for forecasting purpose, monthly trend report and sleeping AUC report.
- Accumulated balance(AUC) up to 31 Dec 2027. (Actual posting and Reversal of Statistical Posting)
Please refer to the accounting journal as described in link below:
Example:
Accounting Journal CS 9031.xlsx - Google Sheets
It is expected that the balance of the WBS Elements is zero at each month end, implying that the settlement transactions will be equal to all the primary and other secondary transactions posted to the relevant WBS Element.
- 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. etc.
All these transactions will be totaled by each extraction and posted by WBS and by the original G/L account (which will be mapped to new WBS and G/L in S4/HANA). The approach will also run SAP settlement by each extraction to the relevant Asset Under Construction.
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 each extraction. 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. Therefore, the scope will extend to the reconciliation of the legacy AUC values.
The data from legacy system includes:
- Relevancy rules of object 1026 (WBS - CAPEX, OPEX, Statistical)
The data from legacy system excludes:
- All WBS CAPEX with an out-of-scope company code will not be migrated.
- All closed Project CAPEX as at the end of the previous fiscal year will not be migrated.(Grp 1 Go live 1st of July 2028 and Grp2 Go live 1st Jan 2029)
- All WBS CAPEX marked for deletion will not be migrated.
- All WBS CAPEX marked as statistical will not be migrated.
Reference:
Trial Balance Extraction:
To migrate last financial year monthly movement and current year monthly movements.
Group 1 Go live (1 July 2028):
- Trial balance migration will be periodic balance movement starting from 1 Jan 2027 onwards for each period until 30 June 2028 (1.5-year worth trial balance data).
Group 2 Go live (1 Jan 2029):
- Trial balance migration will be periodic balance movement starting from 1Jan 2028 onwards for each period until 31 Dec 2028 (1-year worth trial balance data)
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 | Extraction of Project cost values for primary cost elements (COSP) | S/4HANA | ||
PF2 and WP2 | Extraction of Project cost values for Secondary cost elements (COSS) | S/4HANA |
Additional Information
Below is the logic for this object:
| Step | Description | Result |
| 1 | List of WBS elements in scope from object 1026. | All WBS in scope (CAPEX) |
| 2 | Extract table PRPS by identifying the WBS elements from Step 1 to get the corresponding object numbers. | Object numbers by company codes |
| 3 | Extract table COBRB by identifying the object numbers from Step 2 and field "Account Assignment Category" as FXA to filter the object numbers belong to CAPEX. | Object numbers by company codes with Asset number for AUC/Final Asset |
| 4 | Extract table ANLA by identifying AUC/Final Asset number from Step 3 to get the corresponding asset classes, in order to know the G/L take-on account to be used. | Asset Classes for AUC and Final Asset |
| 5 | Extract table ANKA by identifying Asset Classes, if the field ANKA-XINVM is ticked then it is Asset class. | Asset Classes for AUC |
| 6 | Refer to links below to get the corresponding Offsetting GL accounts for each AUC class Note: There are 3 take-on accounts for Fixed Asset and AUC:
| |
| 7 | Extract table COSP and COSS by identifying object numbers from Step 3 and specify Dr/Cr indicator ≠ O to get the actual cost posting for each object numbers. | Settlement Posting by cost element for each object number |
| 8 | Execute transaction code CJI3 (by excluding Dr/Cr indicator = O) to get the total cost of actual posting before settlement. | The total cost of actual posting before settlement |
| 9 | Total amount of Step 7 must be the same as total amount of Step 8. | |
| 10 | Extract table ANEP by identifying Asset number (AUC or Final Asset) to get the balance for AUC and Final Asset. | Total balance for AUC and Final Asset |
| 11 | Step 7 and Step 8 and Step 10 (AUC balance or Final Asset balance) should generate the same amount (with the assumption that WBS is always zero at month end). | |
| 12 | Post real posting by using original G/L expense by WBS, with the AUC amount from Step 10, then do settlement to get AUC balance. Note : Exceptions be the mapped target G/L accounts in S/4 based on the original G/L expense account in ECC...there may be constellations where we map original expense from ECC to a non-operating expense account in S/4 in which case we wouldn't be able to use those accounts. | Total AUC Balance by WBS |
| 13 | Post statistical posting (T.code KAFD) for the Final Asset based on the delta balance (Balance from Step 7 - Step 10(Final Asset balance) | Total Final Asset Balance by WBS |
Multi-language Requirement
N/A
Document Management
N/A
Legal Requirement
N/A
Special Requirements
Due to compliance requirement, there will be 2 SAP instances as below:
- SAP instance for Rest of the World (ROW)
- SAP instance for China
SAP instance for CUI
Project actual cost balance will be migrated to respective SAP instances based on the company codes. Please refer to column "Company Code" and "Instance" in Enterprise Structure Catalog - Google Sheets (worksheet 10. Company code).
All the costs incurred for each WBS will be settled to AUC at the Month end, all WBS should be zero balance.
Target Design
The technical design of the target for this conversion approach for real posting to post cost that will be settled to AUC:
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
| ACDOCA | RBUKRS | BUKRS | Company Code | CHAR | 4 | Mandatory |
| ACDOCA | RACCT | RACCT | G/L Account | CHAR | 10 | Mandatory |
| ACDOCA | GKONT | GKONT | Offsetting Account | CHAR | 10 | Mandatory |
| ACDOCA | BLART | BLART | Document Type | CHAR | 2 | Mandatory |
| ACDOCA | BUDAT | BUDAT | Posting Date in the document Note: Syniti to advise: Migration Cockpit GL Balance does not have field "Posting Date". There are 2 options:
| DATS | 8 | Mandatory |
| ACDOCA | BLDAT | BLDAT | Document Date | DATS | 8 | Mandatory |
| BKPF | BKTXT | BKTXT | Header Text | CHAR | 25 | Optional |
| ACDOCA | SGTXT | SGTXT | Item Text | CHAR | 50 | Optional |
| ACDOCA | RWCUR | FINS_CURRW | Transaction Currency | CUKY | 5 | Mandatory |
| ACDOCA | WSL | FINS_VWCUR12 | Amount in Transaction Currency | CURR | 23 | Mandatory |
| ACDOCA | RHCUR | FINS_CURRH | Company Code Currency | CUKY | 5 | Mandatory |
| ACDOCA | HSL | FINS_VHCUR12 | Amount in Company Code Currency | CURR | 23 | Mandatory |
| ACDOCA | RKCUR | FINS_CURRK | Global Currency (Curr type 30) | CUKY | 5 | System generated |
| ACDOCA | KSL | FINS_VKCUR12 | Amount in Global Currency (Curr type 30) | CURR | 23 | System generated |
| ACDOCA | ROCUR | FINS_CURR1 | Freely Defined Currency 1 (Curr type 31) | CUKY | 5 | System generated |
| ACDOCA | OSL | FINS_VOCUR12 | Amount in Global Currency (Curr type 31) | CURR | 23 | System generated |
| ACDOCA | PS_PSP_PNR | PS_PSP_PNR | WBS Element | CHAR | 80 | Conditional |
The technical design of the target for this conversion approach for statistical posting (T.code KAFD) to post the Fixed Asset balance.
There is no standard Data Migration Cockpit to post statistical posting (Transaction code KAFD). Hence there are 2 options as below:
Option 1: Create custom cockpit object
Option 2: Create LSMW
| Table | Field | Data Element | Field Description | Data Type | Length | Requirement |
|---|---|---|---|---|---|---|
| COEP | OBJNR | J_OBJNR | WBS Element | CHAR | 22 | Mandatory |
| COEP | PERIO | CO_PERIO | Period | NUMC | 3 | Mandatory |
| COEP | GJAHR | GJAHR | Fiscal year | NUMC | 4 | Mandatory |
| COEP | KSTAR | KSTAR | Cost element | CHAR | 10 | Mandatory |
| COEP | WTGBTR | WTGXXX | Total Value in Transaction Currency | CURR | 23 (2 decimal) | Mandatory |
| COEP | TWAER | TWAER | Transaction Currency | CUKY | 5 | Mandatory |
| WWERT | WWERT_D | Translation Date | DATS | 8 | Mandatory | |
| COEP | WKGBTR | WKGXXX | Total Value in Controlling Area Currency | CURR | 23 (2 decimal) | System generated |
| COEP | KWAER | KWAER | Controlling area currency | CUKY | 5 | System generated |
| COEP | WOGBTR | WOGXXX | Total Value in Object Currency | CURR | 23 (2 decimal) | System generated |
| COEP | OWAER | OWAER | Object Currency | CUKY | 5 | System generated |
| COEP | WRTTP | CO_WRTTP | Value Type | CHAR | 2 | System generated |
| COEP | VRGNG | CO_VORGANG | Business Transaction | CHAR | 4 | System generated |
| COEP | VERSN | VERSN | Version | CHAR | 3 | System generated |
Data Cleansing
There will be cleansing required in the following DCA:
- 1024 - Project Definition (CAPEX, OPEX)
- 1026 - WBS - CAPEX, OPEX, Statistical
| ID | Criticality C1 - Data cannot be loaded to SAP C2 - Data can be loaded into SAP but not Business Ready C3 - Errors that do not impact Go-Live or do not validate any standard | Error Message/Report Description | Rule | Output | Source System |
|---|---|---|---|---|---|
| 1 | C2 | Settlement rule with field "Account Assignment Category" = G/L with the GL account (which is mapped to Reconciliation Account type A) must be cleansed by Business. Action item: Instead of settled to the Balance Sheet GL account (which is FXA Reconciliation Account), business must settle to AUC number | Extract table COBRB: Company codes in scope Object Number: PR* Field KONTY (Acct Assignment Category) = G/L Field HKONT (G/L account) = 21900100 | List of WBS that is settled to GL 21900100 (FA recon account) | PF2 and WP2 |
| 2 | C2 | Review of assets under construction (AUC) older than 6 months . The aim is to detect if there is any AUC without any new costs for the last 6 months without capitalization to the fixed asset (FXA). This is the existing process that is happening in PF2 and WP2 | Custom reports that already exist in legacy system: PF2 - Z1A_AUC_SLEEP WP2 - ZWFA81B |
PF2 - Use layout /I&D S AUC WP2 - Use layout /I&D S AUC 2 | PF2 and WP2 |
|
Conversion Process
The high-level process is represented by the diagram below:
Process | Activity |
Extract | Extract involves collecting data from the source. There are 2 possible methods at this stage of process: 1. If the source is a system, extract means to pull the required data from source systems into repository. There are 2 steps for this method: a. Perform full data extraction from relevant tables in the source system(s). b. Apply relevancy criteria for filtering the data that will be applicable according to target system. 2. If the source is not a system, the data will need to be manually collected by business. This is to be done using DCT (Data Collection Template). |
Transform | There are 2 steps of Transform activities that can happen:
The WBS mapping (Current vs To-Be) will be provided by conversion object 1026 (WBS - CAPEX, OPEX, Statistical). 2. Prepare load-ready data in the structure and format that is required for loading via standard Load Tool. This step also produces the load data ready for business to perform Pre-load Data Validation. |
Load | This process includes: 1. Execute the automated data load into target system using load tool. Note: There may be some cases where the load is done manually as part of business activities. 2. Once the data is loaded to target system, it will be extracted out and prepared for Post Load Data Validation. |
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
A. Extraction Run Sheet for AUC balances:
| Req # | Requirement Description | Team Responsible | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1. | Identify the WBS items that are in scope to get the asset number for AUC and Final Asset (if any) | Syniti Team | ||||||||||||||||||||||||||||||||||||||||||||
a. Get the list of WBS in scope from object 1026. b. Extract table PRPS by identifying the WBS elements from Step a to get the corresponding object numbers. c. Extract table COBRB by identifying the object numbers (from Step b) and specify 'FXA' into field "Account Assignment Category" to filter the object numbers belong to CAPEX.
System will provide a report as below that will include the following fields:
Result: Get the AUC and Final Asset (if any) numbers from this report. | ||||||||||||||||||||||||||||||||||||||||||||||
| 2. | Identify Asset Classes for AUC and Final Asset | Syniti Team | ||||||||||||||||||||||||||||||||||||||||||||
Extract table ANLA by identifying AUC/Final Asset number from Step 1c to get the corresponding asset classes for AUC and Final Asset. | ||||||||||||||||||||||||||||||||||||||||||||||
| 3A. | Identify Asset Classes for AUC and G/L take-on account to be used for posting based on AUC Asset Classes | Syniti Team | ||||||||||||||||||||||||||||||||||||||||||||
Extract table ANKA by identifying Asset Classes from Step 2 and apply the logic ANKA - XINVM is X then get the asset classes for AUC. Refer to links below to get the corresponding GL take-on account to be used for each AUC class: PF2_ANKA_AUC Classes.xlsx - Google Sheets WP2_ANKA_AUC Classes.xlsx - Google Sheets There are 3 take-on accounts for Fixed Asset and AUC:
| ||||||||||||||||||||||||||||||||||||||||||||||
| 3B. | Identify Asset Number for AUC | Syniti Team | ||||||||||||||||||||||||||||||||||||||||||||
Extract table ANLA by identifying asset classes for AUC and get the asset number for AUC | ||||||||||||||||||||||||||||||||||||||||||||||
| 4. | Identify settlement posting for AUC | |||||||||||||||||||||||||||||||||||||||||||||
The following tables will be used to extract the settlement amount for the object numbers from Step 1
Go to source systems (PF2 and WP2) Primary Costs Total (Table COSP)
Go to source systems (PF2 and WP2) Secondary Costs Total (Table COSS)
From the above, system will generate report as below. The report will need to be summarized by object number, by original G/L, by extraction as below: Group 1 Go live (1 July 2028):
Group 2 Go live (1 Jan 2029):
Step #4 provides what needs to be posted for each WBS Element. These must be posted by using the original cost element (which will be mapped to S/4HANA cost element) with the offsetting GL take-on account from Step 3A. | Syniti Team | |||||||||||||||||||||||||||||||||||||||||||||
| 5. | To ensure settlement amount is the same as the actual posting | Data Team | ||||||||||||||||||||||||||||||||||||||||||||
To ensure that all settlement costs have been collected via these tables (COSP & COSS), run a report (transaction code CJI3) to extract all the costs (by excluding Dr/Cr indicator "O") posted to the WBS Element/s to reconcile against the totals extracted from table COSP & COSS. Compare and agree the reconciliation values before progressing further to the next steps. For each WBS in scope, confirm that the final balance is zero which will ensure that the settlement costs represent all the postings (debit and credit) by WBS Element. | ||||||||||||||||||||||||||||||||||||||||||||||
| 6. | To get the AUC balance | Data Team | ||||||||||||||||||||||||||||||||||||||||||||
Extract the fixed asset values from table ANEP in source systems (PF2 and WP2) to check what has been posted to the Asset under Construction (AUC).
System will generate as below:
This report will need to be summarized by asset number as below: Group 1 Go live (1 July 2028):
Group 2 Go live (1 Jan 2029):
Check against the WBS Element postings (CJI3) before loading into S/4HANA. | ||||||||||||||||||||||||||||||||||||||||||||||
| 7. | Run transaction code S_ALR_87011963 (Asset Balances report) for all AUC assets within the relevant company code. Check each individual asset balance before making any posting to a WBS Element. | Data Team | ||||||||||||||||||||||||||||||||||||||||||||
| 8. | Post expense with WBS then execute settlement to AUC as below: Group 1 Go live (1 July 2028):
Once the AUC balance up to 31 Dec 2026 has been agreed, a statistical posting will be required by WBS and by original G/L account. No settlement is required.
Once the AUC balance up to 31 Dec 2027 has been agreed:
Please refer to Accounting Journal CS 9031.xlsx - Google Sheets
Once the AUC monthly balance from 1 Jan 2028-30 Jun 2028 has been agreed, a real posting will be required (document type 9A) by month, by WBS and by original G/L account and run settlement (CJ8G) Note: We need to run settlement for January before doing the February expense posting, etc. Group 2 Go live (1 Jan 2029):
Once the AUC balance up to 31 Dec 2026 has been agreed, a statistical posting will be required by WBS and by original G/L account. No settlement is required.
Once the AUC balance up to 31 Dec 2027 has been agreed:
Once the AUC monthly balance up from 1 Jan 2028-31 Dec 2028 has been agreed, a posting will be required (document type 9A) by WBS and by original G/L and run settlement (CJ8G) Note: We need to run settlement for January before doing the February expense posting, etc. | Syniti Team |
B. Extraction Run Sheet for Final Asset balance:
| Req # | Requirement Description | Team Responsible | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1. | To get the asset classes for Final Asset: Extract table ANKA by identifying Asset Classes from Step 2 (Section A) and check if ANKA - XINVM is X then get the asset classes for AUC. | Syniti Team | |||||||||||||||||||||||||||||||||
| 2. | To get the asset numbers for Final Asset: Extract table ANLA by identifying Asset Classes from Step 1 (Section B) | Syniti Team | |||||||||||||||||||||||||||||||||
| 3. | To get the object number for the Final Asset: From Step 1c, get the object number for the Final Asset | Syniti Team | |||||||||||||||||||||||||||||||||
| 4, | To get the balance of Final Asset: Extract the fixed asset values from table ANEP in source systems (PF2 and WP2) to check what has been posted to the Final Asset.
System will generate as below:
This report will need to be summarized by asset number as below: Group 1 Go live (1 July 2028):
Group 2 Go live (1 Jan 2029):
| Syniti Team | |||||||||||||||||||||||||||||||||
| 5. | Post statistical posting (Target accounts) (T.code KAFD) for the Final Asset (Step 2 Section B) and object number (Step 3 Section B) based on the balance from Step 4 -Any AUC balances. (Section B) | Syniti Team |
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 |
|---|---|---|---|---|
| N/A |
Data Collection Template (DCT)
N/A
Extraction Dependencies
List the steps that need to occur before extraction can commence
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1. | All CAPEX WBS element cleansing has been completed in PF2 and WP2 | Business |
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)
- To be 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 |
|---|---|---|
| 1. | In ADMM, select Object 9031 and launch this to execute transformation | Syniti Team |
| 2. | Perform transformation for all relevant WBS Elements. Legacy WBS Element is mapped to S/4HANA WBS elements in mapping table. | Syniti Team |
| 3. | Generate Pre-Load reports in ADMM for the extracted WBS Element amounts. | Syniti Team |
| 4. | Validate the transformed file as part of pre-load validation, raise data defects or provide the pre-load sign-off. | Business |
| 5. | Analyze and resolve any pre-load defects logged by business. | Data Team |
Transformation Rules for Real Posting:
| Rule # | Source system | Source Table | Source Field | Source Description | Target System | Target Table | Target Field | Target Description | Transformation Logic |
|---|---|---|---|---|---|---|---|---|---|
| 1 | PF2 and WP2 | COSP | BUKRS | Company Code | S/4HANA | ACDOCA | RBUKRS | Company Code | Conversion specs mapping "Company Code" (BUKRS: Old Company Code to New Company Code) |
| 2 | PF2 and WP2 | COSS | BUKRS | Company Code | S/4HANA | ACDOCA | RBUKRS | Company Code | Conversion specs mapping "Company Code" (BUKRS: Old Company Code to New Company Code) |
| 3 | PF2 and WP2 | COSP | KSTAR | Cost Element | S/4HANA | ACDOCA | RACCT | G/L Account Number | Use GL Account mapping |
| 4 | PF2 and WP2 | COSS | KSTAR | Cost Element | S/4HANA | ACDOCA | RACCT | G/L Account Number | Use GL Account mapping |
| 5 | N/A | N/A | N/A | N/A | S/4HANA | ACDOCA | GKONT | Offsetting GL Account | GL account that is used for mapping AUC reconciliation account is as below:
PF2: Please refer to AUC Classes and its corresponding Offsetting GL account in link below: PF2_ANKA_AUC Classes.xlsx - Google Sheets WP2: Please refer to AUC Classes in link below: |
| 6 | N/A | N/A | N/A | N/A | S/4HANA | ACDOCA | BLART | Document Type | Default to 9A |
| 7 | N/A | S/4HANA | ACDOCA | BUDAT | Posting Date | Please refer to Accounting Journal CS 9031.xlsx - Google Sheets where Posting date is specified for each extraction. | |||
| 8 | N/A | S/4HANA | ACDOCA | BLDAT | Document Date | Document date would be the same as Posting Date. | |||
| 9 | N/A | N/A | N/A | N/A | S/4HANA | ACDOCA | BKTXT | Header Text | Default to “Data Object 9031” |
| 10 | N/A | N/A | N/A | N/A | S/4HANA | ACDOCA | SGTXT | Item Text | Specify legacy WBS Element |
| 11 | PF2 and WP2 | COSP | TWAER | Transaction Currency | S/4HANA | ACDOCA | RWCUR | Transaction Currency |
|
| 12 | PF2 and WP2 | COSP | WTGxx | Value Transaction Curr | S/4HANA | ACDOCA | WSL | Amount in Transaction Currency | xx represents all periods for previous years. Value type (COSS-WRTTP) must be “4” and Dr/Cr Indicator (COSP-BEKNZ) set to “≠O - Special: Sender credit from Logic will be required to determine the posting period from the field name WTGxxx, with xx being the posting month. E.g. 001,002,003, etc. The extraction must refer as below: Group 1 go live (1 July 2028) to migrate the above WBS for:
Group 2 go live (1 Jan 2029) to migrate the above WBS for:
Please consider Currency Adjustment During Migration (TCURX Consideration) as described in Appendix B. |
| 13 | PF2 and WP2 | COSS | TWAER | Transaction Currency | S/4HANA | ACDOCA | RWCUR | Transaction Currency | Copy from source |
| 14 | PF2 and WP2 | COSS | WTGxx | Value Transaction Curr | S/4HANA | ACDOCA | WSL | Amount in Transaction Currency | xx represents all periods for previous years. Value type (COSS-WRTTP) must be “4” and Dr/Cr Indicator (COSP-BEKNZ) set to “≠O - Special: Sender credit from Logic will be required to determine the posting period from the field name WTGxxx, with xx being the posting month. E.g. 001,002,003, etc. The extraction must refer as below: Group 1 go live (1 July 2028) to migrate the above WBS for:
Group 2 go live (1 Jan 2029) to migrate the above WBS for:
Please consider Currency Adjustment During Migration (TCURX Consideration) as described in Appendix B. |
| 15 | S/4HANA | ACDOCA | RHCUR | Company code currency |
| ||||
| 16 | PF2 and WP2 | COSP | WOGxx | Value in object currency (company code currency) | S/4HANA | ACDOCA | HSL | Amount in company code currency | xx represents all periods for previous years. Value type (COSS-WRTTP) must be “4” and Dr/Cr Indicator (COSP-BEKNZ) set to “≠O - Special: Sender credit from Logic will be required to determine the posting period from the field name WTGxxx, with xx being the posting month. E.g. 001,002,003, etc. The extraction must refer as below: Group 1 go live (1 July 2028) to migrate the above WBS for:
Group 2 go live (1 Jan 2029) to migrate the above WBS for:
Please consider Currency Adjustment During Migration (TCURX Consideration) as described in Appendix B. |
| 17 | S/4HANA | ACDOCA | RHCUR | Company code currency | |||||
| 18 | PF2 and WP2 | COSS | WOGxx | Value in object currency (company code currency) | S/4HANA | ACDOCA | HSL | Amount in company code currency | xx represents all periods for previous years. Value type (COSS-WRTTP) must be “4” and Dr/Cr Indicator (COSP-BEKNZ) set to “≠O - Special: Sender credit from Logic will be required to determine the posting period from the field name WTGxxx, with xx being the posting month. E.g. 001,002,003, etc. The extraction must refer as below: Group 1 go live (1 July 2028) to migrate the above WBS for:
Group 2 go live (1 Jan 2029) to migrate the above WBS for:
Please consider Currency Adjustment During Migration (TCURX Consideration) as described in Appendix B. |
| 18 | S/4HANA | ACDOCA | RKCUR | Global Currency |
| ||||
| 20 | S/4HANA | ACDOCA | KSL | Amount in global currency | Automatic, to be kept blank in load template. This is currency type 30. Currently legacy does not have group currency amount, this is yet to be confirmed as to how this will be derived | ||||
| 21 | S/4HANA | ACDOCA | ROCUR | Freely Defined Currency 1 |
| ||||
| 22 | S/4HANA | ACDOCA | OSL | Amount in currency 1 | Automatic, to be kept blank in load template. This is currency type 31. Currently legacy does not have group currency amount, this is yet to be confirmed as to how this will be derived | ||||
| 23 | PF2 and WP2 | COSP | OBJNR | Object Number | S/4HANA | ACDOCA | PS_POSID | WBS Element Number | COSP Object Number will identify the WBS Element from PF2 and WP2 (PRPS table) which will map to the S/4HANA WBS Element identified in WBS mapping table. This mapping will be provided by conversion object 1026 (WBS - CAPEX, OPEX, Statistical). |
| 24 | PF2 and WP2 | COSS | OBJNR | Object Number | S/4HANA | ACDOCA | PS_POSID | WBS Element Number | COSS Object Number will identify the WBS Element from PF2 and WP2 (PRPS table) which will map to the S/4HANA WBS Element identified in WBS mapping table. This mapping will be provided by conversion object 1026 (WBS - CAPEX, OPEX, Statistical). |
| 25 | PF2 and WP2 | COSP | GJAHR | Fiscal Year | S/4HANA | ACDOCA | GJAHR | Fiscal Year | Copy from source |
| 26 | PF2 and WP2 | COSS | GJAHR | Fiscal Year | S/4HANA | ACDOCA | GJAHR | Fiscal Year | Copy from source |
| 27 | PF2 and WP2 | COSP | WTGxx | Value Transaction Curr | S/4HANA | ACDOCA | POPER | Posting Period | The COSP source table stores period-based data in a columnar format, where each period is represented by an amount column suffixed with values such as 001, 002, and so on. To prepare the data for each period, these columns must be pivoted using the remaining attribute columns as qualifiers. The corresponding period numbers will also be derived during this pivoting process. |
| 28 | PF2 and WP2 | COSS | WTGxx | Value Transaction Curr | S/4HANA | ACDOCA | POPER | Posting Period | The COSS source table stores period-based data in a columnar format, where each period is represented by an amount column suffixed with values such as 001, 002, and so on. To prepare the data for each period, these columns must be pivoted using the remaining attribute columns as qualifiers. The corresponding period numbers will also be derived during this pivoting process. |
Transformation Rules for Statistical Posting:
| 1. | PF2 and WP2 | COSP | OBJNR | Object Number | S/4HANA | COEP | OBJNR | Object Number | COSP Object Number will identify the WBS Element from PF2 and WP2 (PRPS table) which will map to the S/4HANA WBS Element identified in WBS mapping table. |
| 2. | PF2 and WP2 | COSS | OBJNR | Object Number | S/4HANA | COEP | OBJNR | Object Number | COSS Object Number will identify the WBS Element from PF2 and WP2 (PRPS table) which will map to the S/4HANA WBS Element identified in WBS mapping table. |
| 3. | PF2 and WP2 | COSP | GJAHR | Fiscal Year | S/4HANA | COEP | GJAHR | Fiscal Year | Copy from Source |
| 4. | PF2 and WP2 | COSS | GJAHR | Fiscal Year | S/4HANA | COEP | GJAHR | Fiscal Year | Copy from Source |
| 5. | PF2 and WP2 | COSP | KSTAR | Cost Element | S/4HANA | COEP | KSTAR | Cost Element | Refer to Mapping legacy GL Accounts to S/4HANA GL Accounts |
| 6. | PF2 and WP2 | COSS | KSTAR | Cost Element | S/4HANA | COEP | KSTAR | Cost Element | Refer to Mapping legacy GL Accounts to S/4HANA GL Accounts |
| 7. | PF2 and WP2 | COSP | WTGxxx | Value in Transaction currency | S/4HANA | COEP | PERIO | Posting Period | The COSP source table stores period-based data in a columnar format, where each period is represented by an amount column suffixed with values such as 001, 002, and so on. To prepare the data for each period, these columns must be pivoted using the remaining attribute columns as qualifiers. The corresponding period numbers will also be derived during this pivoting process. |
| 8. | PF2 and WP2 | COSS | WTGxxx | Value in Transaction currency | S/4HANA | COEP | PERIO | Posting Period | The COSS source tables store period-based data in a columnar format, where each period is represented by an Amount column suffixed with values such as 001, 002, and so on. To prepare the data for each period, these columns must be pivoted using the remaining attribute columns as qualifiers. The corresponding period numbers will also be derived during this pivoting process. |
| 9. | PF2 and WP2 | COSP | WTGxxx | Value in Transaction Curr for relevant period Note: xxx represent the period | S/4HANA | COEP | WTGBTR | Total Value in Transaction Currency | xx represents all periods for previous years. Value type (COSP-WRTTP) must be “4” and Dr/Cr Indicator (COSP-BEKNZ) set to “≠O - Special: Sender credit from settlement”. Logic will be required to determine the posting period from the field name WTGxxx, with xx being the posting month. E.g. 001,002,003, etc. The extraction must refer as below: Group 1 go live (1 July 2028) to migrate the above WBS for:
Group 2 go live (1 Jan 2029) to migrate the above WBS for:
Please consider Currency Adjustment During Migration (TCURX Consideration) as described in Appendix B. |
| 10. | PF2 and WP2 | COSS | WTGxxx | Value in Transaction Curr for relevant period Note: xxx represent the period | S/4HANA | COEP | WTGBTR | Total Value in Transaction Currency | xx represents all periods for previous years. Value type (COSS-WRTTP) must be “4” and Dr/Cr Indicator (COSS-BEKNZ) set to “≠O - Special: Sender credit from settlement”. Logic will be required to determine the posting period from the field name WTGxxx, with xx being the posting month. E.g. 001,002,003, etc. The extraction must refer as below: Group 1 go live (1 July 2028) to migrate the above WBS for:
Group 2 go live (1 Jan 2029) to migrate the above WBS for:
Please consider Currency Adjustment During Migration (TCURX Consideration) as described in Appendix B. |
| 11. | PF2 and WP2 | COSP | TWAER | Transaction Currency | S/4HANA | COEP | TWAER | Transaction Currency | Copy from source |
| 12. | PF2 and WP2 | COSS | TWAER | Transaction Currency | S/4HANA | COEP | TWAER | Transaction Currency | Copy from source |
| 13. | S/4HANA | WWERT | Translation Date | Please refer to Accounting Journal CS 9031.xlsx - Google Sheets where Translation Date is specified for each extraction. |
List of Custom Target Reports for this object is maintained here: Conversion Specification - Custom Reports Register.
Appendix B:
Currency Adjustment During Migration (TCURX Consideration)
In SAP, the TCURX table defines the number of decimal places used for each currency.
This impacts how amounts are stored internally in database tables versus how they are displayed externally in user interfaces or reports.
Currencies such as JPY (Japanese Yen), KRW (Korean Won), or VND (Vietnamese Dong) are typically configured with no decimal places (TCURX-CURRDEC = 0).
Understanding and correctly applying the TCURX rules is essential during data migration to ensure financial consistency between ECC and S/4HANA.
Internal vs External Currency Representation example:
| External Amount | The amount value as displayed to users in SAP screens and reports. | 96015 JPY | |
| Internal Amount | The amount value stored in database tables for computation. | 960.15 | Multiplied by factor = 10² if target has 2 decimals |
During data migration, these internal (technical) amounts must be converted to external amounts to ensure accuracy and consistency in the target S/4HANA system.
Conversion Formula:
External Amount = Internal Amount * 10 to the power (2 - Number of decimals for the currency in TCURX table)
Transformation Mapping
Conversion Specification - Transformation Mapping Register - Google Sheets
| Mapping Table Name | Mapping Table Description |
|---|---|
Company code | BUKRS: Old Company Code to New Company Code |
GL Accounts | HKONT: Old GL Accounts to New GL Accounts |
Profit Centre | PRCTR: Old Profit Centre to New Profit Centre |
Asset Number | ANLN1: Old Asset number to New Asset number |
WBS Elements | POSID: Old WBS Elements to New WBS Elements |
Transformation Dependencies
List the steps that need to occur before transformation can commence| Item # | Step Description | Team Responsible |
|---|---|---|
| 1. | Ensure all the fields that require value mapping, as stipulated in Section "Mapping tables", have the correct values mapped. | Data Team |
Pre-Load Validation
Project Team
The following pre-load validations will be performed by Project Team.
This is to validate the total transactional movement in each open WBS Element. Validate the financial movement of all transactions excluding settlement transactions by WBS Element by Cost Element (GL Account) for the open WBS Elements as the closing balance.
Completeness
| Task | Action |
|---|---|
Verify Counts | Data team to verify the load count is the same as per identified data from Primary Cost Total COSP file and Secondary Cost Total COSS file. |
Validate | Validate that the extracted values from both tables agree with the total transaction costs excluding settlement for each individual WBS Element |
Accuracy
| Task | Action |
|---|---|
| Validate | Validate that the extracted values from both tables agree with the total transaction costs excluding settlement for each individual WBS Element |
| Validate | Validate that the extracted values are identical to those values settled to the Receiver. |
| Reconcile | Total by Asset number to compare to the WBS Element value to be posted. The value to be posted against the WBS Element must agree with the value shown for the relevant Asset Under Construction. See section "Extraction run sheet for legacy WBS element settling to AUCs. |
Business
The following pre-load validations will be performed by the Business.Completeness
| Task | Action |
|---|---|
| Verify counts | Business will use the preload report to validate the number of WBS Elements that will migrate values. |
Accuracy
| Task | Action |
|---|---|
| Validate | Validate that the extracted values are identical to those values posted to the WBS Element |
Load
For loading, please use Migration Cockpit GL account balance as attached for doing real posting.
Load Run Sheet
| Item # | Step Description | Team Responsible |
|---|---|---|
| 1. | Ensure Pre-Load signoffs are obtained. | Data Team |
| 2. | Load a small number of records to verify that the process is stable and will load all records as expected. | Syniti Team |
| 3. | If the above is successful, load all remaining records. | Syniti Team |
| 4. | If the above is unsuccessful, review errors and determine whether the error is data related, or system related. | Data Team |
| 5. | After correction, load corrected file or run corrected program to load data. | Syniti Team |
| 6. | Prepare report for Post Load Validation. | Syniti Team |
| 7. | Validate Post Load report. | Business |
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
Pre Cutover
Configuration
List the Configurations required before loading can commence
| Item # | Configuration Item |
|---|---|
| 1. | Asset Classes |
| 2. | Settlement Profiles |
| 3. | Allocation Structures |
| 4. | Previous Asset Fiscal Year to be opened |
| 5. | Current Asset Fiscal Year to be opened |
| 6. | Settlement cost elements used for settlement available in all company codes in scope |
| 7. | Number ranges for settlement documents to be set up. This is manual config. |
Conversion Objects
| Object # | Preceding Object Conversion Approach |
|---|---|
| 1024 | Project Definition (CAPEX, OPEX) |
| 1026 | WBS - CAPEX, OPEX, Statistical |
| 1067 | GL Account Operational CoA (incl. secondary CE) |
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 |
|---|---|---|
| Configuration | Document type does not exist in S/4HANA | Engage Functional team to fix the error in the system |
| Master Data | AUC take-on account does not exist | Ask GL team to create AUC take-on account |
Post-Load Validation
Project Team
Completeness
| Task | Action |
|---|---|
| Verify counts | Data team to verify the load count is the same as per identified data from Pre Load file |
Accuracy
| Task | Action |
|---|---|
| Verify values | Ensure the Pre-Load report values are the same as in the Post Load Report. These values have to be verified before settling the costs to the AUCs. |
Post Load Activities
A. Settlement to Assets under Construction (AUC)
After validating the WBS Element transaction movements for count and accuracy, run settlement. Ensure that all Settlement objects have been created. For AUCs this will take place during the conversion from CRTD (Created) to REL (Released) status. This will provide balances to the AUCs.
For this data object, the settlement needs to be executed as below:
Group 1 Go live (1 July 2028):
- Accumulated balance up to 31 Dec 2026
- No settlement is required.
- Accumulated balances from 1 Jan-31 Dec 2027
- Execute settlement with posting date 31.12.2027. The Asset Fiscal Year 2027 must be opened.
- Monthly balance from 1 Jan 2028 till 30 June 2028
- Execute settlement for Current Fiscal Year with posting date as month end (e.g. 31 Jan 2028, 29 Feb 2028, etc.). The Asset Fiscal Year 2028 must be opened.
Group 2 Go live (1 Jan 2029):
- Accumulated balances up to 31 Dec 2026
- No settlement is required.
- Accumulated balances from 1 Jan-31 Dec 2027
- Execute settlement with posting date 31.12.2027. The Asset Fiscal Year 2027 must be opened.
- Monthly balance from 1 Jan 2028 till 31 Dec 2028 (Prior Year)
- Execute settlement with posting date as month end (e.g. 31 Jan 2028, 29 Feb 2028, etc.). The Asset Fiscal Year 2028 must be open.
SAP Transaction CJ88 will be used to settle all the WBS Element costs to their respective settlement objects. For those that are settling to the AUCs a reconciliation must be created that will compare the AUCs in the legacy systems (PF2 and WP2) to those that are now in S/4HANA. Table ANLC will be used for this comparison.
The previous Fiscal year cannot be closed until the AUC reconciliation for the previous year is completed and balanced.
Business
Completeness
| Task | Action |
|---|---|
Verify Counts | Business to verify the load count is the same as per identified data from Post Load Report. |
Accuracy
| Task | Action |
|---|---|
| Verify values | Ensure the Post Load report values are exactly the same as in the Pre Load report. These values have to be verified before settling the costs to the AUCs. |
Appendix C
AUC Balance by WBSE can be validated using below reports
- Asset History Sheet (AR02)
- Asset Balances by Asset class (S_Alr_87011964)
Key Assumptions
- Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
- WBS is in scope based on data design and any exception requested by business.
- All WBS Elements/Internal Orders will have a zero balance. If this is not true, there must be a BAU activity to ensure there is a zero balance.
- All costs in source systems PF2 and WP2 (Primary Costs Total Table COSP and Secondary Costs Total Table COSS) will represent the total transactional costs that have been posted to the respective WBS Element.
- There will not be any partial settlements to final asset, always full and final settlement from AUC to Final asset.
Any additional key assumptions.
See also
Jira task crated: and sub tasks
,
,