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.
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. |
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
8 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 |