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.
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 Finance Consistency Checks: 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 –
This is an excellent blog. It is helpful for consultants and customers alike. The new reports described are going to be very helpful in analyzing the errors and possibly fixing some of them automatically.
Excellent Blog!!!!!!
Excellent Blog..This is clearly differentiates on how the 1909 vs 1809
How can i upload the data from FDQ check in the ERP system into the Readiness check 2.0 application ? ==> SAP Readiness Check (ondemand.com)
I have activated the FDQ checkbox in this report " RC_COLLECT_ANALYSIS_DATA" but now data seem to arrive in RC 2.0 after the download of the result . All the relevant Batchjobs are executed successfully . The section in RC 2.0 is still empty
Thank you for your help
Hannes
Hi Hannes, please check note 2913617 - SAP Readiness Check 2.0
Once you have implemented this SAP Note, a checkbox will be available when executing the RC_COLLECT_ANALYSIS_DATA report. To include the Financial Data Quality check in the SAP Readiness Check analysis, select the checkbox. During the execution, the TMW_RC_FDQ_DATA_COLL job will be performed.
Please note, once implemented, the Financial Data Quality check will remain deselected by default. When selected to be in scope, the selection of the Schedule Analysis option will initiate a prerequisite note check of the system. Any missing notes for the conversion reconciliation process will then be provided. These notes must be implemented before SAP Readiness Check can be scheduled, with this check active.
There is the potential, depending on the volume of financial data, that this check could run longer than other checks. If necessary, it is possible to schedule the Financial Data Quality check in isolation from rest of the SAP Readiness Check data collectors. Once complete, the results of the Financial Data Quality check can then be appended (using the Upload function) to the analysis session created with the original ZIP archive.
This a new SAP Note for SAP Readiness Check for SAP S/4HANA.
Hi Monica Reyes,
I 've run RC_COLLECT_ANALYSIS_DATA but job TMW_RC_FDQ_DATA_COLL was cancelled. first, I'm applying note 2755360 but it show error as picture below,