Skip to Content
Personal Insights

S/4HANA_System Conversion_ Finance Data Consistency checks

A best practice for any S/4HANA conversion is to identify the consistency of all financial data prior to conversion into S/4HANA.

There is new functionality (available in late 2020) that facilitates deep consistency checks of all General Ledger data by executing the reports described in this blog post.  A key feature of this new functionality is not only the detection of inconsistencies,  but new functionality has been released that will also correct many of the issues.

 

FIN_CORR_RECONCILE & FIN_CORR_DISPLAY

These pair of reports were released for the S/4HANA 1909 and were created specifically for system transitions using a  System Conversion process (both Classic GL and New GL conversion scenarios are supported).  These reports check and analyze accounting data and verify that all preconditions for the conversion are met.

The FIN_CORR_RECONCILE report deeply analyzes financial data consistency and should be executed in the source ERP system prior to conversion.  Failure to identify these inconsistencies may results in errors when executing the main check reports executed after conversion to S/4HANA (Analyze Transaction Data and the Migration Monitor check routines).

FIN_CORR_RECONCILE focuses primarily on GL data inconsistencies.  Not all possible errors that may occur in the Migration Monitor will be captured by this report, but it is focused more on the possible errors in the migration step R21>Reconciliation of the Transactional Data

To execute the report run transaction code FIN_CORR_RECONCILE

And to display the results run transaction FIN_CORR_DISPLAY

To activate these reports in the ECC system follow

SAP Note 2755360 – Reconciliation prior to S/4HANA Conversion instructions

Tip! Be sure that the following notes are installed to have the latest version of FIN_CORR_RECONCILE:

  • 2887318 – Reconciliation, Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion
  • 2836444 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- User Interface
  • 2793849 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- Application Coding

 FIN_CORR_MONITOR

FIN_CORR_MONITOR analyzes database inconsistencies that were found in FIN_CORR_RECONCILE and allows corrections to be made to the discovered errors.  Details of the correction can be viewed in the FIN_CORR_MONITOR correction logs.

Below is the list of correctable errors and information on the correction strategy used by FIN_CORR_MONITOR to correct them**

Error Message Number
Description
Problem/Root Cause
Assumptions
Correction
FIN_FB_RECON 070, 071
No entry in BSEG/BSEG_ADD for this line item of FAGLFLEXA
One or more lines of document is missing in the Entry view.
Data in document header (BKPF), index and tax tables are considered correct.
Consistency of document status (BSTAT) in the GL view is first checked and corrected. The entry view is created using the data in BKPF, index and tax tables if the zero balance check is successful.
FIN_FB_RECON 220, 221, 223, 224, 225, 226, 227, 228, 229
Values in certain fields of index table and BSEG/BSEG_ADD do not match
There is a mismatch between any of the fields BKPF-BUDAT (posting date), BKPF-BLDAT (document date), BSEG-HKONT (GL account), BSEG-DMBTR (local currency amount), BSEG-ZUONR (assignment number) and the corresponding fields in the index tables.
BSEG/BSEG_ADD entries are considered to be correct. You get a popup during correction to confirm this.
Index fields are updated from BKPF and BSEG/BSEG_ADD accordingly.
FIN_FB_RECON 334, 335, 336, 337, 338
Open item in BSEG/BSEG_ADD, missing in BSI*/FAGLBSIS but available in BSA*/FAGLBSAS
Missing clearing information in BSEG/BSEG_ADD
Clearing information in the index table is considered correct.
The clearing information is updated in BSEG/BSEG_ADD from the secondary index if it is available. However if either one of AUGBL or AUGDT is already filled in BSEG/BSEG_ADD, then the case is excluded as a concrete decision cannot be made on the correct clearing information.
FIN_FB_RECON 339, 340, 341, 342, 343
Missing index table entries
Index table records are missing
Data in document header (BKPF), document (BSEG/BSEG_ADD) and indexes are considered correct.
New index records are created using BKPF, BSEG/BSEG_ADD and indexes.
FIN_FB_RECON 354, 355, 356, 357, 358, 359, 360, 361
Duplicate index table entries
There are duplicate index records created for a particular line item in the index tables.
BSEG/BSEG_ADD entries are considered to be correct.
The dupicate index entries are moved to a dummy client (ZZZ). The index records are created from BSEG/BSEG_ADD accordingly.
FIN_FB_RECON 372, 373, 374, 375, 376, 377, 378, 379
Missing archival flag in index table entry
The field XARCH should be populated with ‘X’ in the secondary index tables when the documents are archived. Due to some issue the field is populated with space.
If the document is not present in the header table (BKPF), BSEG/BSEG_ADD and new GL item table (FAGLFLEXA), it is considered to be archived
The flag XARCH is updated to ‘X’ for the entry in the corresponding index table.
FIN_FB_RECON 391, 392, 393, 394, 395
Shifted BUZEI issue
The incorrect line item numbers (BUZEI) in reversal documents is caused by the issue mentioned in the note 1988463. Other cases of incorrect BUZEI is due to some other issue.
If the document is a reversal document, the issue is with incorrect BUZEI in BSEG (Note 1988463). For all other cases BUZEI in BSEG is considered to be correct
For reversal documents the BUZEI is corrected in the entry view (BSEG) if only BUZEI mismatch is seen between entry view and GL view and all other information (i.e, account and amounts – TSL, HSL, KSL, OSL and GL update currency- RTCUR) is the same. If the document is not a reversal document and only BUZEI mismatch is seen between entry view and GL view lines while all other information (i.e, account and amounts – TSL, HSL, KSL, OSL and GL update currency- RTCUR) is the same, then the BUZEI is corrected in the GL view.
FIN_FB_RECON 577, 578
Open item flag mismatch between account master and document
There is a mismatch in the open item management flag (BSEG/BSEG_ADD-XOPVW) between the account master data and the document. This could be due to subsequent changes done to the account master data.
The master data table(SKB1) of the account is considered to be correct.
The value of field XOPVW is set in the document as per the value in the master data table SKB1.
FIN_FB_RECON 584, 585
Ledger specific clearing field (XLGCLR) in BSEG/BSEG_ADD has a junk character
The field BSEG/BSEG_ADD-XLGCLR or SKB1-XLGCLR in some G/L accounts had received a junk value ( ‘/’ or ‘\’ ) due to multiple bugs in the past. The root causes have been fixed in the latest SPs and through notes.
The value of field XLGCLR is set ‘ ‘ wherever it is equal to ‘/’ or ‘\’.  This correction is done once per company code. It is checked irrespective of any error messages proactively.
FIN_FB_RECON 592, 593, 594, 595
Clearing specific to ledger groups differs between master data and BSEG/BSEG_ADD
There is a mismatch in the ledger specific clearing flag (BSEG/BSEG_ADD-XLGCLR) between the account master data and the document. This could be due to the junk values in SKB1 being corrected or pure account master data change done subsequently.
The master data table(SKB1) of the account is considered to be correct.
The value of field XLGCLR is set in the document as per the value in the master data table SKB1.

** Reference  Note 2956096 – FIN_CORR_MONITOR: Information on correctable errors for more details

To execute the report run transaction code FIN_CORR_MONITOR to display and correct the data.  Please refer to my  future blog post FIN_CORR_MONITOR for more details on this transaction

To activate FIN_CORR_MONITOR , implement in the following order the below notes and follow the instructions in the notes:

2887318 – Reconciliation, Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion

2793849 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- Application Coding

2836444 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- User Interface

Be aware that note 2755360 is a prerequisite before all above notes can be installed

Tips! Be sure that the following notes are also installed to correct some known errors

  • 2896016 – FIN_CORR_MONITOR: Additional corrections
  • 2937335 – Correction prior to S/4HANA Conversion using tool FIN_CORR_MONITOR: Error message FIN_FB_RECON 334,335,336,337,338 given in reconciliation check FIN_CORR_RECONCILE

RFINDEX_NACC

Warning:  Use of RFINDEX_NACC tool may cause significant damage to your data if you execute in change mode without proper training.   This tool is an expert level tool and therefore should only be used by trained expert resources advised by SAP Support.

RFINDEX_NACC should not generally be used by customer’s as an analysis tool as the selections are quite complex and the output can be difficult to understand. The following is for informational purpose only and please check with SAP support for further assistance.

This report is an analysis tool for SAP support in a pre-converted ERP source system. This report can be used in classic GL and some of the checks are also valid for new GL postings.  The RFINDEX_NACC is not to be used on a post-converted S/4HANA system. RFINDEX_NACC contains a lot of check options which allows SAP Support to identify deep inconsistency issues.

The disadvantage of the RFINDEX_NACC is that it very often lists inconsistencies which do not have any impact on a System Conversion.  That means that not all errors reported may need to be corrected and could possibly co-exist during the conversion process.  This is the main reason for RFINDEX_NACC is considered as SAP Support tool.

In some cases, this report can be executed in a System Conversion (more often after your first Sandbox iteration) to resolve issues for specific documents.  Be aware that running the report in update mode can lead to new inconsistencies if it is run in the wrong way, and only SAP Support should use the update mode.

You can find some blogs or community questions explaining how to run RFINDEX_NACC in update mode but that approach is not recommended for customers to do it on their own.  If needed, please create an incident to request SAP Support help on this matter.

 Tips!

Only use RFINDEX_NACC – FI Consistency Check with the option, Indexes vs. Documents (below).  All other checks of this program are not relevant for a System Conversion.

In summary,  the accounting data needs to be identified, analyzed and corrected in ECC system to fulfill the pre-conditions for a System Conversion to S/4HANA.  In this blog post you can learn about the reports that will help with those activities and guide you during the process.

Hopefully this is helpful, please add in the comment section any other topics you think are valuable to have included in this blog post.

– Brought to you by the S/4HANA RIG –

 

2 Comments
You must be Logged on to comment or reply to a post.