FI-GL and FI-AA Reconciliation Prior S/4 HANA Finance Data Migration

FINS_RECON 763: &1: reconciliation account & 2: total without asset assignment

Issue description: This is really a very generic error message usually pointing to mismatch between FI-GL and FI-AA entries, i.e. existing reconciliation issues in ECC are raised with this error message during data migration into S/4 HANA.

First step to address this error is to run ABST / ABST2 t-codes in your legacy SAP and, starting from there, proceed with correcting the mismatches G/Ls / Ledger wise.

There’s quite a number of SAP notes available on this topic, but I would recommend to start checking SAP note 69225, which will give understanding on the origin of differences and how to handle them.

Note that manual postings to asset reconciliation accounts, by unchecking reconciliation indicator via OAMK t-code, is acceptable and actually is recommended by SAP in above provided note.

Manual entries SHOULD NOT, as long as they reconcile FI-AA and FI-GL differences observed in ABST / ABST2 t-codes, cause any errors during data migration, especially FINS_RECON 763 one.

Root cause analysis & solution description: FI-GL and FI-AA reconciliation mismatch may be due to different reasons, mainly, these are due to bypassed Balance Carryforward run in non- leading Ledger in previous Fiscal Years. So, re-running these is a must to reconcile the differences in current Fiscal Year, but this needs to be verified from auditing perspective, as BCF re-run will ultimately alter the balances across non-leading Ledger for already closed Fiscal Years.

Manual validations of ending balances with beginning balances in a consecutive FY of affected G/Ls is a mandatory step to figure out which FY actually is having issues with BCF run. So validating FS10N / FAGLB03 with AR01, AR02 will have to be executed per each FY, per each Company Code, which may be very time consuming. But this is the only way to find out the real root cause of the differences.

Apart from BCF, differences between G/Ls and asset values needs to be validated case- by- case in order to proceed with the manual correction entries via ABF1 t-code (Ledger wise) or ABB1 t-code for adjustments in parallel currencies. Note that in ABF1 and ABB1 t-code, you will be debiting / crediting asset reconciliation accounts without asset specified as an account assignment object, which is OK and which is in line with SAP standard (refer to SAP note 69225).

So, the target is to reconcile FI-GL and FI-AA mismatches prior data migration in ABST2 and ABST, basically, if the report returns no data this means data is fully reconciled. Or you might still receive report output totaling differences to zero and when going back to the selection screen, MQ555 or MQ557 error will pop- up, which is fine, this just means that with following BCF run the differences will be reconciled (i.e. technically they occurred in current Fiscal Year and already reconciled).

Exception case: you MIGHT potentially encounter FINS_RECON 763 error message during S/4 HANA data migration, if the BCF run executed prior migration for the Company Code having alternative Fiscal Year Variant assigned (for example, FSV ‘V3’ assigned to Indian Company Codes). Basically, error will be raised due to non- representative Ledger, which is not supports Asset Accounting only partially. You will notice that postings through non- representative Ledger won’t have asset specified as account assignment object and BCF values carried forward accordingly. As a result, this will trigger the ‘false positive’ FINS_RECON 763 error message in data migration cockpit (FINS_MIG_STATUS t-code), as there’s no inconsistencies logged prior data migration in ABST2 or ABST. In this case, SAP suggests suppressing or change the status of the error message status to warning via OBA5 t-code. OR else proceed with implementing the SAP note:

SAP note 3753135

The note was actually released by SAP for addressing our absolutely unexpected FINS_RECON 763 case during data migration in PROD. How cool is that? :)

That’s about it!

Data Model of S/4 HANA Finance Data Migration

Case 1: Post S/4 HANA data migration some of your PBI, OneStream and etc. reports that were using ECC tables (FAGLFLEXA ,for example) as primary data source may start showing ‘incorrect’ values and you notice that ACDOCA- OSL, KSL, TSL, HSL, BSL are not balancing to 0 or totals are incorrect.

The reason for that is migrated document line items are now having COEP and COSP table entries merged into the same FI document in Universal Journal or ACDOCA table, which now becomes the only 'source of truth' in S/4 HANA environment.

From data migration model perspective, legacy FI entries are migrated with ACDOCA-MIG_SOURCE = G, F, M, A indicators (i.e. General Ledger, Material Ledger, Asset Accounting postings) while COEP and COSP table entries are merged with ACDOCA - MIG_SOURCE = 'C' indicator. Note that Controlling entries are not fully distinguished based on MIG_SOURCE = 'C', but rather by ACDOCA - CO_BELNR <> space. And in order not to duplicate the amounts so called ‘reversal’ or the correction line is also added into migrated document with MIG_SOURCE = 'R' indicator.

So, basically, FI data migration logic is as follows:

FI and CO documents merge into Universal Journal logic

And if you want to continue fetching FI data only in your PBI reports, OneStream and etc. it is required to add filtering by ACDOCA - MIG_SOURCE = ‘C’ and ‘R’ line items from the report output. Or just add filtering by ACDOCA - MIG_SOURCE = 'G', 'F', 'A', 'M' and that's it.

Same is approach is valid for FI-GL standard reporting tools reading data from ACDOCA, where applicable (FAGLB03, FAGLL03H and etc.) Exception is FBL3H t-code which is reading data from BSEG, so technically, in S/4 HANA your FBL3H will show 'inconsistent' data going forward and it is advised to stop using it / replace it with FAGLL03 or FAGLL03H (refer to SAP note 2886122 on that matter).

If any other filtering is required to get correct information based on migrated documents, it's always advisable to add filtering by BTTYP, for example. Assume, if you want to fetch BCF values only, proceed with adding ACDOCA - BTTYP = 'RFBC' and etc.

This is the standard design of FI data migration in S/4 HANA and details on how ACDOCA-MIG_SOURCE field needs to be adjusted throughout different reports is described also in attachment of SAP note 2408083.

Case 2: Assume, your PBI or OneSource report is using FAGLFLEXT as data primary and post S/4 HANA upgrade you notice the mismatch when validating OneSource amounts, that are actually built based on totals table) with line items of FAGLB03 ,FAGLL03 and etc. The reason for that is ,when drilling down into line items level, CO lines are excluded as per standard design, i.e. totals are never matching the line items values, which is happening because of line items reports are not fetching MIG_SOURCE = ‘C’ lines (migrated from COEP and COSP tables) into report output as per standard.

First and foremost solution here is to switch the OneStream data source to ACDOCA table. And if that's not feasible, then SAP is describing the solution alternative of adding FAGLB03_RESTRICT_MIG = ‘X’ and MIG_SOURCE_C_SIGN= ‘X’ parameters into FAGL_SETTINGS via SM30 t-code. Details on that approach are described in SAP note 2891129.

Finance Data Migration into S/4 HANA: FINS_RECON 119: &1/&2: Zer-Bal-Clrng account master data inconsistent

Main root cause of the error is zero balance clearing G/L account entries that exist in BSEG table, though automatically generated line items are never updated in BSEG. So existing BSEG entries, i.e. manual postings to zero- balance clearing G/L account are triggering the error message in GCC segment during data migration in FINS_MIG_STATUS t-code. Basically, system is checking if the balance of the G/L account is zero. 

Solution is to clear out existing balances of zero -balance G/L account manually in all Ledgers and activate ‘Post automatically only’ option via FS00 t-code (SKB1-XINTB = ‘X’).

By doing so, error message will be eliminated from the errors log during data migration.

Another important requirement listed in SAP note is that zero- balance G/L account needs to have ‘Only balances in local currency’ option activated (SKB1-XSALH = ‘X’).

In case of existing historical balances in foreign currencies, consider utilizing program FINS_SWITCH_XSALH for converting historical balances into local currency (refer to SAP note 3393227 for more details on how to enable the program for your release). This program is valid both for ECC (SAP_FIN 720 and higher and in S4CORE 102 and higher). 

In brief, FINS_SWITCH_XSALH program does the following:

(a) It runs conversion of historical entries in BSEG, ACDOCA and FAGL_SPLINFO tables from foreign currencies to local currency (Company Code currency)

(b)   As a result, you will see that ACDOCA – TSL amounts in foreign currencies converge to zero

(c)  SKB1 – XSALH indicator activated automatically, i.e. no manual activation via FS00 t-code needed. Note that user performing the FINS_SWITCH_XSALH program will be shown in G/L account master data change log for auditing purposes

Conversion of historical entries into local currencies is irreversible, hence required to be thoroughly tested in QA before proceeding with the conversion in Production. I’d suggest verifying all the financial reports to be verified before and after the FINS_SWITCH_XSALH program run. 

According to SAP note 9611937 requirements, zero- balance G/L account should be excluded from Foreign Currency Valuation program, so once SKB1- XSALH indicator activated, G/L will no longer be suitable for FAGL_FCV t-code.  

So, in your FINS_MIG_STATUS cockpit during S/4 HANA data migration, in case of existing balances in foreign currencies, you might still encounter FINS_RECON 119 but as a warning message.

Recommendation is to clear out foreign currency balances before data migration, or else accept the warning messages and proceed with correcting G/L account set- up post data migration. 

SAP CDS View 'Analytical Query'

Any custom report or a query can be easily generated via SQVI t-code as shown in the example below:

Suppose custom report needs to contain join of ANLA (Asset Master Record Segment), ANLZ (Time- Dependent Asset Allocations), T499S (Location) and ADRC(Addresses) tables. 

This can be achieved through creating table join via SQVI t-code:

Query output can be generated in ALV grid, classical view, Excel file and etc.:

Easy as that.

Now let's try utilizing CDS view called 'Analytical Query' in S/4 HANA for creating required query / or custom report. 

Step 1: Custom analytical query creation:

Go to 'Reporting' --> 'Query Design' option of the menu:

Select 'Custom Analytical Queries' tile:

Step 2: Create new query:

Step 3: Specify query name:

Step 4: Select query data source:

Step 5: Specify query output fields in 'Field Selection' tab of the view:

Step 6: Add filters and maintain fields status in 'User Input Values' tab of below view:

Step 7: Publish new query by pressing 'Publish' option:

Step 8: Go to Analysis for Office and select new query as data source:

Step 9: Maintain 'Asset Location Report' prompts: 

Step 10: Custom analytical query output validation:

Now in order to add T499S and ADRC table columns into the report, custom CDS view needs to be generated. 

Step 11: Custom CDS view generation: Go to 'Extensibility' --> 'Custom CDS Views' tile:

Press 'Create' option:

Step 12: Maintain primary and associated data sources:

Step 13: Select fields for custom CDS view output. Go to 'Fields selection' tab --> maintain fields in 'Selected Fields and Associations' tab of the below view:

Step 14: Publish custom CDS view:

Step 15: Creating a new query based on ZZ1_ASSET_LOCATION_03 view

Specify query name and select custom CDS view as data source:

Select fields for query output:

Maintain filters for Prompts screen of the report:

Save and publish new query:

Step 16: Go to ‘Query design’ tab and select ‘View browser’ app:

Step 17: Restrict view search by ‘Application component’ and by release status:

Step 18: Search results:

Step 19: Select ZZ1_FA_LOCATION query for fields validation:

Step 20: Show content of ZZ1_FA_LOCATION query:

Step 21: Adding dimensions into the view output:

Query output is correct as per below verifications:

Step 22: Save query as a tile:

Add new query into ‘My home’ tab of Fiori Launchpad:

Et voilà! :)