Purpose

The purpose of this document outlines the conversion process for Right of Use (ROU) assets Master and Transactional data in SyWay S/4 HANA. The ROU Assets migration will move both the master and transactional data in a single step and there will be only one SAP standard template that will be utilized for both Master and Transactional data migrations. Syniti ADMM tool organises the execution of data extraction, transformation & mapping, loading and data quality (ETL). 

ROU Asset master primarily contains of the following information:

• General information: Asset description, asset class, account determination, capitalization date etc. 
• Time Dependent data: Cost Center, Plant, Location etc.,
• Depreciation terms data: Depreciation keys, Useful life and Depreciation areas

Note: This conversion specification will only include to ROU assets that were created from underlying RE-FX contracts from object 1076. All other fixed assets (non ROU) will be managed using objects 1070, 9022 and 9028.

Conversion Scope

The scope of this document is to define a data upload approach for active ROU Assets from legacy systems into S/4HANA following the Master Data Design Standard DD-FUN-050 Master Data Standard_1070-Fixed Assets (incl. Sub Assets) 

Relevancy rule:

The data from legacy system includes:

• Company code is in scope 
• All active ROU Assets

The data from legacy system excludes:

• All non-ROU assets

 Relevancy rule for Extraction: The following relevancy criteria to be considered for extracting active ROU Assets from both WP2 and PF2. Note: PI2 does not have ROU Assets

• Go to table ANLA and filter based on company code (BUKRS) that are in scope and asset class (ANLKL) that are relevant to ROU. Ensure that that deactivation date (DEAKT) is blank.

• Based on the result from step-1, go to table ANLZ (Time dependent terms). Filter the details based on company code (BUKRS), asset number (ANLN1) and asset sub-number (ANLN2)

• Based on the result from step-1, go to table ANLB (Depreciation area terms). Filter the details based on company code (BUKRS), asset number (ANLN1) and asset sub-number (ANLN2). Note: One asset will consist of more than one line item depending on the number of depreciation areas that is set  up in the legacy system

• Based on the result from step 1 and 3, go to table ANLC (Asset values). Filter based on company code (BUKRS), asset number (ANLN1), asset sub-number (ANLN2), fiscal year (GJAHR) and Depreciation areas (AFABE). For filtering on Fiscal year (GJAHR), this will depend on whether it is year end or mid-year migration.

          - Year end migration: This will depend on the data transfer date. Ex: If the data transfer date is 31.12.2027, then fiscal year (GJAHR) will be 2027

          - Mid year migration: This will depend on the data transfer date. Ex: If the data transfer date is 30.06.2028, then fiscal year (GJAHR) will be 2028

After this, retrieve the asset cumulative values.

i) ROU asset cumulative values KANSW
ii) ROU asset accumulated depreciation KNAFA. Note: For year end migration, the accumulated migration will equals to KNAFA + NAFAG as the accumulated depreciation
iii) ROU asset cumulative Unplanned depreciation KAAFA
iv) ROU asset ordinary depreciation posted in the current migration year NAFAG
v) ROU asset posted unplanned depreciation in the current migration year AAFAG

• Go to table ANEP (Asset line item postings), filter based on company code (BUKRS), ROU asset number (ANLN1), ROU asset sub number (ANLN2), fiscal year (GJAHR) and accounting document number (BELNR). Then, retrieve the following:

• Go to table ANLV (Insurance data), filter based on company code (BUKRS), ROU asset number (ANLN1) and ROU asset sub number (ANLN2). Then, retrieve the data for ROU asset insurance information.

• Go to table ANLU (Asset master: user fields), filter based on company code (BUKRS), ROU asset number (ANLN1) and ROU asset sub number (ANLN2). Then, retrieve the user fields data for ROU assets

There are 2 group go-live as below:

• Group 1 go-live is planned for 1 July 2028
• Group 2 go-live is planned for 1 Jan 2029

If the currency of the depreciation area in the target S4 system is the same as the currency of the mapped depreciation area in the source system, the ROU asset balances will be copied from the mapped depreciation area of the source system. Otherwise, the asset balances will be converted from the asset balances of the depreciation area of the source system as per the mapping table by using the exchange rates for conversion as below:

• For Group 1 Go live:  B/S spot rate as of 30 June 2028 will be used for Group Depreciation Areas  
• For Group 2 Go live:  B/S spot rate as of 31 Dec 2028 will be used for Group Depreciation Areas

Note: If company codes (where local currency is not EUR) have depreciation area in EUR, this EUR depreciation area is currently not used anymore. (In the past, these EUR depreciation areas were used when BFC was not the consolidation tool).

ROU Assets will be migrated to respective group go live as described in Enterprise Structure Catalog - Google Sheets (worksheet 10. Company code).

Additional Information

Multi-language Requirement

It was decided to apply approach below:

• Field “Description Line1” (ANLA-TXT50) = Migrate as it is from legacy system to S/4HANA. The description could be any languages (not only the 4 core languages but also any other non-core languages.
• Field “Description Line2” (ANLA-TXA50) = Migrate as it is from legacy system to S/4HANA. The description line 2 is used to add information on the description of the asset when the line 1 length is not enough.
• Field "Asset main no.text" (ANLH-ANLHTXT) must be in English 

Document Management

N/A

Legal Requirement

There are no legal requirements relevant to data migration of ROU Assets

Special Requirements

N/A

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. Note: DCT is not required for this object 9108. DCT is shown in table below for reference only, just in case in the future data migration, DCT may be required.

The conversion process will be largely automated using Syniti ADMM as the conversion tool:

Data Privacy and Sensitivity

Extraction

The ROU Assets shall be extracted from SAP ECC and migrated using the Syniti Migrate. There are 2 possibilities:

1. The data exists. Syniti Migrate connects to the source and loads the data into Syniti Migrate. 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 Syniti Migrate. This is to be conducted using DCT (Data Collection Template) in Syniti Migrate. Note: DCT is not applicable for this object 9108

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)

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

The ROU asset takeover values will be based on the currency of the target depreciation area as depreciation areas are defaulted from the chart of depreciation assigned to the company code in the target system. Thus, depreciation area/chart of depreciation in the target system will be mapped to the depreciation area/chart of depreciation in the legacy system if the currency is the same.

 - If the target depreciation area is found in the mapping table, the takeover values will be copied from the source depreciation area.

 - Otherwise, will be translated from the gross values found in the Book Depreciation area, refer to section "Depreciation area in Foreign Currency".

Depreciation area in Foreign Currency:

Asset Balances in Group Currency depreciation area will not be migrated as per values Group depreciation areas in the legacy system. If the target depreciation area/chart of depreciation is not found in the mapping table, the corresponding balances for the depreciation area will be derived from the Book Depreciation area i.e. 01-Leading.

For conversion, the exchange rate would be as below:

• For Group 1 Go live:  B/S spot rate as of 30 June 2028 will be used for Group Depreciation Areas   
• For Group 2 Go live:  B/S spot rate as of 31 Dec 2028 will be used for Group Depreciation Areas

The translation will be done in ADMM and align to the Trial Balance Conversion. 

Translation logic to determine the balance:

In SAP, currencies (data type CURR) are stored with 2 decimal number but can be configured to display with different number of decimals (Table TCURX)

The logic to determine the balance (this logic should apply to all currencies):

1. Check table T093B in legacy system to retrieve the currency for the company code and depreciation area.
2. Check table TCURX in legacy system to find the number of decimal places for the currency. If '0', multiply the amounts by 100, else (including no entry found in TCURX), no action

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:

Internal Vs External Currency Amount Representation:

The amount value as displayed to users in SAP screens and reports is 96015 JPY (external), whereas, the amount value stored in database tables for computation is 960.15 JPY (internal). 

During data migration, these internal (technical) amounts must be converted to external amounts to ensure accuracy and consistency in the target S/4HANA system through multiplied by factor = 10² if target has 2 decimals

Conversion Formula: External Amount = Internal Amount * 10 to the power (2 - Number of decimal for the currency in TCURX table)

Transformation Mapping

Transformation Dependencies

Pre-Load Validation

Project Team

Completeness

Accuracy

Business

Completeness

Accuracy

Load

ROU Assets will be migrated using the SAP tool 'Migration Cockpit' and 'Object: Fixed asset (incl. balances and transactions)'. Migration template is attached as a reference.

Source data for Fixed asset (incl. balances and transactions).xml

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

The load phase for this object is Pre Cutover and this object will be loaded before RE-FX Contracts (object 9108) is loaded. 

Configuration

The table below shows a key configuration elements

Conversion Objects

Error Handling

The table below shows 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

Post-Load Validation

Project Team

The following post load validations will be performed by the project team.

Completeness

Accuracy

Business

The following post load validations will be performed by the business.

Completeness

Accuracy

Key Assumptions

• Master Data Standard is up to date as on the date of documenting this conversion approach and data load.
• ROU Assets are in scope based on data design and any exception requested by business.
• ROU asset master cleansing is completed.
• All ROU assets (associated with RE-FX contracts) must be deactivated (i.e. populate the deactivation date field).

See also

Change log