Status
Owner	Soumen Laru
Stakeholders	PILLAY-ext, Lawrence WELENSKY-ext, Dave GARCIA-ext, Angel Luis BECHTER-ext, Alex TJAHJO-ext, Maytingsari

Purpose

The migration of General Ledger (GL) Open Items is a critical component of the overall financial data migration process during the transition from SAP ECC to SAP S/4HANA. This activity ensures that all outstanding balances and unreconciled entries in open item-managed accounts are accurately carried forward to the new system.

GL Open Items as of the defined cutover date are extracted from the source ECC system. These items are then validated, transformed, and loaded into S/4HANA to maintain financial activities and support reconciliation between legacy and target systems. 

This document outlines the approach, scope, data extraction methodology, transformation logic, validation rules, and posting strategy for the successful migration of GL Open Items.

Conversion Scope

By principle, only the accounts which are open item managed in source, will be part of migration of GL Open items.

Accounts are considered open item managed when the Open Item Management indicator is enabled at the company code level. This can be verified in table SKB1, where the field XOPVW = 'X' indicates that the account is open item managed.

An important point needs to be noted here. No separate take-on account will be used for migration open item managed GL accounts in the migration of TB. Offset entries for GL open items will post to the same accounts or Trial Balance(TB) offset account. 

As part of the Trial Balance (TB) migration, open item managed GL accounts are included for both:

• Periodic balance migration

• Opening balance

Further details are available in the Trial Balance Conversion Specification.

Migration Approach and handling in each period

• For each period in scope, TB data will be migrated as life-to-date balances with the posting date set to the last day of the respective period.

• These entries will be reversed using mass reversal (T-code F.80) on the first day of the subsequent period.

• This approach ensures that open item managed lines are automatically reversed and cleared for all periods up to (but not including) the go-live period.

Go-Live Period Handling

There are three possible approaches to manage the GL Open Item data migration process during the go-live period.

• Option 1:

  • During go-live (posting date = cutover date), open item–managed lines migrated through the Trial Balance will remain open.

  • These open items must be cleared against the offset lines of CNV-9010 GL Open Items, ensuring that only CNV-9010-derived open items exist in S/4HANA. The offset entries will be posted to the same GL account.

  • This approach ensures data integrity and prevents residual open items.

  ---

  Option 2:

  • During go-live (posting date = cutover date), open item–managed account lines migrated through the Trial Balance will remain open.

  • These lines will then be reversed using the cutover posting date.

  • Subsequently, CNV-9010 GL Open Items will subsequently be migrated with a Trial Balance offset account ( Account number: 5310998 ).

  • This approach ensures clean and accurate open item data.

  ---

  Option 3:

  • During go-live (posting date = cutover date), balances of open item–managed accounts ( Included in CNV-9010 GL Open Items) will be migrated into GL take-on account 5310998 (in place of the actual accounts) as part of the Trial Balance migration process. GL take-on account 5310998 is the same account as Trial Balance offset account

  • Subsequently, CNV-9010 GL Open Items will be migrated with offset lines recorded in the trial balance offset account 5310998, ensuring alignment between the trial balance and open item data.

  • This ensures data accuracy and prevents duplicate or additional open items requiring clearing.

Option 3 is the preferred option ( Transformation section is based on this )

Relevancy Rule:

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

Basis of relevancy is based on the table below.

ECC ( SKB1-XOPVW)	S4 ( SKB1-XOPVW)	In Scope?	Strategy
Open Item -Yes	Open Item -Yes	Yes	Migrate as GL Open Items
Open Item -No	Open Item -Yes	No	Migrate as GL Balance - Lump sum open item will be created at the profit centre and any other entity level as needed and will be detailed out in the GL Balance spec
Open Item -Yes	Open Item -No	Yes	Migrate as GL Open Items
Open Item -No	Open Item -No	No	Migrate as part of Trial Balance

Read all the records from table BSIS ( and BSAS for specific needs described later in this segment) for the company codes as listed in the source column of the mapping file of company codes .  ( Source company codes can be referred to where check the worksheet 10. Company Code with filter on column "In Scope as S/4 Company Code?" as in "In-Scope")  

• Determine Open Item Relevance

  • Based on extracted BSIS records, read table SKB1 in the source system using keys (BSIS-SAKNR, BSIS-BUKRS) to retrieve the Open Item Management indicator (SKB1-XOPVW).

  • Map the ECC Company Code (BSIS-BUKRS) and GL Account (BSIS-SAKNR) to their respective target S/4HANA Company Code (BUKRS) and GL Account (SAKNR).

• Mock Cycle Data Relevancy Considerations

  • As month-end closing and extraction activities may occur several days after the cutover date, it is critical to identify true open items as of the cutover date for each Mock Cycle (MC).

  • During this gap, certain open items may be cleared, or new items may be posted. Hence, logical filtering is required.

• Open Item Selection Logic (for Mock Cycles)

  • • Step 1: Select records from BSIS where
      Posting Date ≤ Mock Cycle Cutover Date.
    • Step 2: Select records from BSAS where
      Clearing Date > Mock Cycle Cutover Date and
      Posting Date ≤ Mock Cycle Cutover Date.

  • The combination of BSIS and BSAS ensures accurate identification of open items that were still outstanding as of the cutover date.

• Production Cutover Exception

  • For the Production Cutover, a data freeze will be enforced between the conversion and extraction dates. Therefore, only BSIS data is required for extraction, as no additional clearing activity will occur post cutover.

Example for MC1, MC2, MC3 etc:

BSIS.BUDAT <= ‘ conversion Cut-Over date’

BSAS.BUDAT <= ‘ conversion Cut-Over date’ and BSAS.AUGDT > ‘ conversion Cut-Over date’.

Example for Production Cut-Over:

BSIS.BUDAT <= ‘Production Cut-Over Date’

Note: GR/IR Open items is not in scope of GL Open Items and they will be dealt with GR/IR open item data loading.

List of such accounts will be given in an exception list as below (List subject to change as we discuss with stakeholders like R2R functional team, R2R Business)

Source	ECC Company Code	ECC GL Account	Account Type - Desc	Exclude
PF2	*	2320000000	GR/IR Clearing Account	Y
PF2	*	2340000000	GR/IR Clearing Account	Y
PF2	*	2330000000	GR/IR Clearing Account	Y
PF2	*	2320200000	GR/IR Clearing Account	Y
PF2	*	2320002000	GR/IR Clearing Account	Y
PF2	*	2330000010	GR/IR Clearing Account	Y
WP2	*	40100310	GR/IR Clearing Account	Y
WP2	*	40100300	GR/IR Clearing Account	Y
WP2	*	46900320	GR/IR Clearing Account	Y
WP2	*	40800300	GR/IR Clearing Account	Y
WP2	*	40100315	GR/IR Clearing Account	Y

List of source systems and approximate number of records 

Source	Scope	Source Approx No. of Records	Target System	Target Approx No. of Records
PF2	GL Open Items	1,042,609	S4HANA	TBD
WP2	GL Open Items	1,665,227	S4HANA	TBD
PI2	GL Open Items	TBD	S4HANA	TBD

Additional Information

Multi-language Requirement

Not Applicable

Document Management

Not Applicable

Legal Requirement

Not Applicable

Special Requirements

Not Applicable

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 (Decimals)	Requirement	Requirement ( Mandatory or Optional) R = Required O=Optional
BSIS	BUKRS	BUKRS	Company Code	CHAR	4	Described in the Transformation Rules	R
BSIS	XBLNR	XBLNR	Reference Document Number	CHAR	16	Described in the Transformation Rules	R
BSIS	DOCLN	DOCLN	Line Item Number	Number	6	Described in the Transformation Rules	R
BSIS	HKONT	HKONT	G/L Account	CHAR	10	Described in the Transformation Rules	R
BSIS	GKONT	GKONT	Offsetting Account	CHAR	10	Described in the Transformation Rules	R
BSIS	BLART	BLART	Document Type	CHAR	2	Described in the Transformation Rules	R
BSIS	BLDAT	BLDAT	Document Date	Date	8	Described in the Transformation Rules	R
BSIS	WWERT	WWERT	Translation Date	Date	8	Described in the Transformation Rules	R
BKPF	BKTXT	BKTXT	Header Text	CHAR	25	Described in the Transformation Rules	R
BSIS	SGTXT	SGTXT	Item Text	CHAR	50	Described in the Transformation Rules	R
BSIS	WAERS	WAERS	Transaction Currency	CHAR	5	Described in the Transformation Rules	R
BSIS	WRBTR	WRBTR	Amount	Number	23	Described in the Transformation Rules	R
BKPF	HWAER	HWAER	Company Code Currency	CHAR	5	Described in the Transformation Rules	O
BSIS	DMBTR	DMBTR	Amount	Number	23	Described in the Transformation Rules	R
BKPF	HWAE2	HWAE2	Group Currency	CHAR	5	Described in the Transformation Rules	R
BSIS	DMBE2	DMBE2	Amount	Number	23	Described in the Transformation Rules	O
BKPF	HWAE3	HWAE3	3rd Local Currency / 1st Freely Defined Currency	CHAR	5	Described in the Transformation Rules	R
BSIS	DMBE3	DMBE3	Amount	Number	23	Described in the Transformation Rules	R
BSIS	RASSC	RASSC	Company ID of Trading Partner	CHAR	6	Described in the Transformation Rules	O
BSIS	ZUONR	ZUONR	Assignment Number	CHAR	6	Described in the Transformation Rules	O
BSIS	RMVCT	RMVCT	Transaction Type	CHAR	3	Described in the Transformation Rules	O
BSIS	VALUT	VALUT	Value Date	Date	8	Described in the Transformation Rules	O
BSIS	HBKID	HBKID	Short Key for House Bank	CHAR	5	Described in the Transformation Rules	O
BSIS	HKTID	HKTID	ID for Account Details	CHAR	5	Described in the Transformation Rules	O
BSIS	PRCTR	PRCTR	Profit Center	CHAR	10	Described in the Transformation Rules	R
BSIS/BSEG	XREF1	XREF1	XREF1	CHAR	20	Reference key for line item	O
BSIS/BSEG	XREF2	XREF2	XREF2	CHAR	20	Reference key for line item	O
BSIS/BSEG	XREF3	XREF3	XREF3	CHAR	20	Reference key for line item	O

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
1.	Medium	Open Item is overdue and aged, should be cleansed.	Select <GL Open Lines> from BSIS where BUDAT <= Current Date - 2 years for the Accounts with status as SKB1-XOPVW = 'X'  for legacy accounts on legacy to target GL Account mapping and ECC BUKRS in scope based on Company Code List    where check the worksheet 10. Company Code with filter on column "In Scope as S/4 Company Code?" as in "In-Scope"	Report	PF2 / WP2

Data Privacy and Sensitivity

Summarize Data Privacy and Sensitivity Requirements, if any

Extraction

Extract data from a source into 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 Syniti Migrate; cannot connect to the source, data is loaded to the repository from the provided source system extract/report.
2. The data can't be extracted from source or cannot be converted from its current state. Therefore, it will be manually collected by the business users directly within the Syniti Migrate tool using the Data Collection Template (DCT) functionality.

Extraction Run Sheet

Req #	Requirement description	Team responsible
1.	Ensure source tables BKPF, BSIS, BSAS are extracted in tool according to the agreed cut-off date in the project plan	Data team
2.	Perform preliminary completeness check based on the relevancy details documented in section of Conversion Scope	Data team
3.	Raise issues as defects if Req # 1 to 2 are not met	Data team
4.	Repeat Req # 1 to 3 if required	Data team
5.	Report extraction result to person in charge of APOI conversion	Data 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)

Note: Option of Data Collection is not expected to be used and therefore, does not need to be considered in migration design. However, if such a scenario arises ( for e.g PI2 system) whereby GL Open collection becomes necessary, a data collection template is attached in this section. 

Target Ready Data Collection Template will be created for GL Open Items data using attached template below.

Note:  Current migration cockpit template does not have fields ( XREF1, XREF2, XREF3 ). Necessary modification of cockpit object will need to be carried out before these fields can be used in collection template. 

Decimal validation - Check table TCURX for the document currency key and if Decimals (TCURX-CURRDEC) is ‘0’, validate that no decimal value is populated and amounts are given correctly for the relevant currencies. Please check the details under the section - Currency Adjustment During Migration (TCURX Consideration)

Extraction Dependencies

List the steps that need to occur before extraction can commence

Item #	Step description	Team responsible
1.	Any period / year end close activities have been fully completed	Business
2.	Reconciliation for intercompany payables have been completed, and adjustment made in legacy SAP system	Business
3.	Reconciliation of migrated Purchase Order is completed before the extraction of Accounts Payable Open Items	Business and Data

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:

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 Syniti Migrate
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

Item #	Step description	Team responsible
1.	Ensure all the fields that require value mapping, as stipulated  Mapping tables, have the latest signed-off mapping files imported into toolMigrate.	Data team
2.	In tool, select the GL Open Items.	Data team
3.	Go to Process Area Launch and Process the Object - GL Open Items- GL Open Items.	Data team
4.	Launch the Objects to execute transformation.	Data team
5.	Monitor the transformation progress and ensure performance and completion is within allowed timeframe	Data team
6.	Generate Pre-Load reports .	Data team
7.	Generate data load count.	Data team
8.	Log errors as defects, if any and address resolutions. Close defects.	Data team
9.	Re-transform and re-validate the Pre-load reports if necessary.	Data team
10.	Validate the transformed file as part of pre-load validation, raise data defects or provide the pre-load sign-off.	Business
11.	Analyse and resolve any pre-load defects logged by business.	Data team
12.	Repeat steps 6 to 11 if necessary	Data team
13.	Proceed to pre-load validations	Data team

Transformation Rules

Note: for Each GL open line in scope of migration, an offset line to be created with the same GL Account.   

In Migration cockpit, offset account number field is set in the same line and therefore, it will create offset line on its own. So, transformed data will be one line for each legacy in-scope line but will be automatically created with an offset line. 

Posting Date ( which is generally the cut-over date ) is not part of the template, as posting date will be maintained by the Syensnqo data team in the view FINSV_MIG_CTRL_1. This posting date will be used across all the financial transactions migrations ( exception is Trial Balance ).

Rule #	Source system	Source Table	Source Field	Source description	Target system	Target Table	Target Field	Target description	Transformation logic
1	ECC	BKPF	BUKRS	Company Code	S/4HANA	BSIS	BUKRS	Company Code	Map Company Code from ECC to S4 Mapping File Location:
3	ECC	BSIS	XBLNR	Reference Document Number	S/4HANA	BSIS	XBLNR	Reference Document Number	Copy as is
4	ECC	BSIS	BUZEI	Line Item Number	S/4HANA	BSIS	BUZEI or DOCLN	Line Item Number	Copy as is
5	ECC	BSIS	HKONT	G/L Account	S/4HANA	BSIS	HKONT	G/L Account	Map Old GL Account to new GL Account Mapping File Location:
6	ECC	BSIS	GKONT	Offsetting Account	S/4HANA	BSIS	GKONT	Offsetting Account	TB Balance Offset Account ( Account Number:  5310998  )
7	ECC	BKPF	BLART	Document Type	S/4HANA	BSIS	BLART	Document Type	Default to '9S'
8	ECC	BKPF	BLDAT	Document Date	S/4HANA	BSIS	BLDAT	Document Date	Copy as is
9	ECC	BSIS	WWERT	Translation Date	S/4HANA	BSIS	WWERT	Translation Date	To be kept blank Note: By-Default Posting Date BUDAT is used as translation date.
11	ECC	BKPF	BKTXT	Header Text	S/4HANA	BKPF	BKTXT	Header Text	Header Text will contain the unique key combining legacy fields -, BKPF-BUKRS, BKPF-GJAHR, BKPF-BELNR, BSIS-BUZEI
12	ECC	BSIS	SGTXT	Item Text	S/4HANA	BSIS	SGTXT	Item Text	Copy as is
13	ECC	BSIS	WAERS	Transaction Currency	S/4HANA	BSIS	WAERS	Transaction Currency	Use Currency Key Mapping File Mapping File Location:
14	ECC	BSIS	WRBTR	Amount	S/4HANA	BSIS	WRBTR/TSL	Amount	This is for currency type 00 Copy as is with Signage as '-' if the posting key is 50 or else '+' Also consider Currency Adjustment During Migration (TCURX Consideration) below this table
15	ECC	BSIS	HWAER	Company Code Currency	S/4HANA	BKPF	HWAER	Company Code Currency	Automatic, to be kept blank in load template
16	ECC	BSIS	DMBTR	Amount	S/4HANA	BSIS	DMBTR/HSL	Amount	This is for currency type 10 Copy as is with Signage as '-' if the posting key is 50 or else '+' Also consider Currency Adjustment During Migration (TCURX Consideration) below this table
17	ECC	BSIS	HWAE2	Group Currency	S/4HANA	BKPF	HWAE2	Group Currency	Automatic, to be kept blank in load template
18	ECC	BSIS	DMBE2	Amount	S/4HANA	BSIS	DMBE2/KSL	Amount	Group Currency 2 This is for currency type 30 ( Global currency / Group currency ) Note: Currently, legacy does not have group currency amount, the plan is let exchange rate to populate this. Very Important point to be noted here - take the relevant exchange rate from the exchange rate table ( refer to CNV-9013 TB CY (0L - IFRS = 31 GC Val Ledger) Monthly Movement  exchange rate DCT section ) based on the cut-over date ( Period + Year ) for this object ( 9010 - GL Open items )
19	ECC	BSIS	HWAE3	Freely Defined Currency	S/4HANA	BKPF	HWAE3	Freely Defined Currency	Automatic, to be kept blank in load template
20	ECC	BSIS	DMBE3	Amount	S/4HANA	BSIS	DMBE3/VSL	Amount	Group Currency 2 This is for currency type 31 ( Freely Defined currency type 2 ) Note: Currently, legacy does not have group currency amount, This is yet to be confirmed as to how this will be derived, Copy as is with Signage as '-' if the posting key is 50 or else '+' Also consider Currency Adjustment During Migration (TCURX Consideration) below this table Very Important point to be noted here - take the relevant exchange rate from the exchange rate table ( refer to CNV-9013 TB CY (0L - IFRS = 31 GC Val Ledger) Monthly Movement  exchange rate DCT section ) based on the cut-over date ( Period + Year ) for this object ( 9010 - GL Open items ).
21	ECC	BSIS	RASSC	Company ID of Trading Partner	S/4HANA	BSIS	RASSC	Company ID of Trading Partner	to be kept empty
22	ECC	BSIS	ZUONR	Assignment Number	S/4HANA	BSIS	ZUONR	Assignment Number	Copy as is
23	ECC	BSIS	RMVCT	Transaction Type	S/4HANA	BSIS	RMVCT	Transaction Type	to be kept empty
25	ECC	BSIS	VALUT	Value Date	S/4HANA	BSIS	VALUT	Value Date	to be kept empty
26	ECC	BSIS	HBKID	Short Key for House Bank	S/4HANA	BSIS	HBKID	Short Key for House Bank	to be kept empty
27	ECC	BSIS	HKTID	ID for Account Details	S/4HANA	BSIS	HKTID	ID for Account Details	to be kept empty
29	ECC	BSIS	PRCTR	Profit Center	S/4HANA	BSIS	PRCTR	Profit Center	Map Old Profit Centre to New Profit Centre  Mapping File Location: Note:  For line items missing profit centres, a generic(across all financial transaction objects) enrichment construct page in ADM containing company code, default profit centre will be used to populate a default profit centre. Further discussions will be necessary on this.
30	ECC	BSIS	XREF1	Reference key for line item	S/4HANA	BSIS	XREF1	Reference key for line item	Copy as is (Note:  Current migration cockpit template does not have fields ( XREF1, XREF2, XREF3 ). Necessary modification of cockpit object will need to be carried out before these fields can be used in  uploading )
31	ECC	BSIS	XREF2	Reference key for line item	S/4HANA	BSIS	XREF2	Reference key for line item	Copy as is (Note:  Current migration cockpit template does not have fields ( XREF1, XREF2, XREF3 ). Necessary modification of cockpit object will need to be carried out before these fields can be used in uploading)
32	ECC	BSIS	XREF3	Reference key for line item	S/4HANA	BSIS	XREF3	Reference key for line item	Copy as is (Note:  Current migration cockpit template does not have fields ( XREF1, XREF2, XREF3 ). Necessary modification of cockpit object will need to be carried out before these fields can be used in  uploading )

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:

Representation	Description	Example for JPY	Notes
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 decimal for the currency in TCURX table )

Transformation Mapping

Use the exact name and reference this section in the “Transformation rules” above

Mapping Table Name	Mapping Table Description
Company Code	Mapping of legacy company codes to target system value
GL Account	Mapping of legacy GL accounts to target system value
Profit Centre	Mapping of legacy Profit Center to target system value
Currency Key	Mapping of legacy currency keys to target system value

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. Mapping tables, have the correct values mapped and imported into tool.	Data team
2	GL Accounts are loaded with right open item management setting at the company code level and Post-Load Verification Completed	Data team
3	Profit Centres are loaded and Post-Load verification completed	Data team and Business

Pre-Load Validation

Project Team

The following pre-load validations will be performed by the Project Team.

Completeness

Task	Action
Generation of Pre-load reports	Mandatory field check. GL Accounts, Company code mapped Posting key mapped   2. Currency types mapped   3. Profit Centres mapped Check GL Accounts are extended to required company code Check if the GL Accounts extended to the company codes for the records by looking up SKB1.  Check signage of amount. Check whether source data (including DCT) has debit and credit entries in the same line. If sign is the same in all the three currency fields, then no action needed. If the sign in the document currency and company code currency field are different, then the document needs to be corrected in the source system or DCT. Ensure all transactions have values in Document Currency and Local Currency (i.e. no 0.00 allowed)
Reconciliation of total	Record Count Summary at GL Account and Company Code level.  Check Amount in Document Currency and Local Currency Check the sum of the amount in Document Currency and Local Currency in load file is the same as source. If any of the sum is different, flag the record as error.

Accuracy

Task	Action
Mandatory field mapping and transformation	Obtain a list of the fields to be populated with values from mapping files and ensure all these fields contain S/4HANA values.  Review the data report to ensure mapping value is not missing in tool. Capture errors in the Data Error report.

Business

The following pre-load validations will be performed by the business.

Completeness

Task	Action
Verify record count in Pre-load reports by region	In legacy system, execute report GL Open Items Display (t/code: FBL3n ) with selection parameters stated in section.  Group the output of the report by Company Code, GL Account and Profit Centre using subtotal function and compare the count in this GL Open line items report  count in the pre-load file. If any of the count is different, raise defect and flag the relevant record as error.

Accuracy

Task	Action
Conversion accuracy	Verify GL Open Lines are transformed accurately as per endorsed transformation/mapping rules. Review error reports in tool for any mismatch or missing transformed values. In legacy system, execute report FBL3N If any of the sum is different, raise defect and flag the relevant record as error.
Business partner balance on Company code and profit center level	Check the total open item amount on Business partner at Company Code and Profit center level, against the total in legacy by Document, Local and Group currency. Apply currency rules where applicable

Load

Loading will be done through migration cockpit and therefore, data from the transformation export view to be exported into the load file format. 

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

Item	Step description	Team responsible
1	Ensure the load tools are transported into the correct tool instance.	Data team
2	Ensure DCTs and all required mappings are submitted and complete	Data team
3	Ensure Pre-load sign-offs are obtained.	Data team
4	Execute tool Trial Balance Upload	Data team
5	Generate the post load reports in tool.	Data team
6	Log errors as defects, if any and address resolutions. Close defects.	Data team
7	Resolve defects by reupload and re-generate post load reports if necessary.	Data team
8	Business to validate the post load files as part of post-load validation, raise data defects or provide the post-load sign-off.	Business
9	Repeat steps 5 to 7 if necessary.	Data team

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
1.	Company code-related configuration (posting period variant).
2.	Finance posting (document types, document number ranges, special gl indicator)
3.	Currencies (currency keys, decimal places in currencies)
4.	Set Posting Date for the Company Codes in SM30 for the view: FINSV_MIG_CTRL_1

 Conversion Objects

Object #	Preceding Object Conversion Approach
1067	GL Account Operational CoA (incl. secondary CE)
1073	Profit center
1074	Cost Centre

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
Posting Period Error	Posting period is blocked for posting	Review project / cutover plan and ensure posting periods can be opened for postings
Profit Centre does not exist	Profit centre does not exist in company code	Ensure the profit centre mapping is correct and or create the profit centre if it is valid

Post-Load Validation

Project Team

The following post-load validations will be performed by the Project Team.

Completeness

Task

Action

Reconciliation of Record Count

Total number of records loaded for GL Open Items will be generated in the Post-load reports in tool based on the target table and fields mentioned in the field list section. The reconciliation needs to be executed on the total number of ‘valid’ records and currency amount per company code in the source compared to total number of records and currency amount in S/4HANA Record Count Check the sum of record count of the open items in the load file is the same as S/4HANA. The record count for GL Open items will need to be done. The fields in the group are consist of: Company Code, Vendor Account Check Amount in Document Currency and Local Currency Check on line item level that the sum of the amount in Document Currency and Local Currency in the load file is the same as posted in S/4HANA. If any of the sum is different, flag the record as error.

Accuracy

Task

Action

Check values in key fields for accuracy

Post-load reports will have the same structure as the load file and some additional columns as required to facilitate the post load validation. Leverage on tool to create a Post Load report that reports S/4HANA loaded records along with the legacy values side-by-side to allow for 100% check of all these fields in the shortest possible time. Any mismatch will be reported under the Post Load - Error report.

Business

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

Completeness

Task

Action

Record Count Check

Review the record count report from the Data Team and ensure it is correct by cross-checking with the record count confirmed during Pre-load Business Validations Business may also run transaction code FBL3N – GL Open Line Items Display or equivalent report in Fiori App "Display Line Items in General Ledger" (F2217) to display loaded GL Open Line Items in S/4HANA and compare results against the Pre-Load reports generated from tool.

Accuracy

Task	Action
Open items totals	Check business partner open item totals by Business partner, Company code, profit centre. Totals should be checked in Document, Local and Group currency.
Spot check	Business should choose some business partners and perform comprehensive check of open items, payment terms etc Such partners should have huge number of open items or be critical for payment runs in S4 or have certain complexity in conversion.

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.

Change log

Workflow history