FAQ - Data Model of S/4HANA Finance Data Migration
In what way are the records of BSEG (ANEP, COEP, FAGLFLEXA, etc) migrated into table ACDOCA?
The migration of data attempts to make a match of BSEG and COEP records although it is not likely to happen all the time. The records of NewG/L are always matched to the equivalent records of BSEG but matching FI-AA items cannot be done. The attachment contains a few example data constellations as well as resulting ACDOCA records.
What exactly is meant by ACDOCA fields MIG_SOURCE and BSTAT?
For migrated ACDOCA records, MIG_SOURCE is filled but it is empty for records that are newly created. It makes an indication of the location from which the ACDOCA records have been migrated from.
On the other hand, BSTAT = C makes an identification of balance carry forward items, along with items from balance migration.
Why does table COEP (ANEP, FAGLFLEXA, etc) appear empty in SE16 prior to migration?
A large number of tables are swapped with a compatibility view in S/4HANA finance. Certain statements that appear on these tables are then passed on to this compatibility view that makes a selection of the data from ACDOCA as well as other tables. It is therefore necessary for you to execute data migration to fill ACDOCA in order to populate the compatibility views. In case you wish to take a look at the data that is contained in the old tables, you can make use of the matching “ORI” view – for example, V_COEP_ORI or V_FAGLFLEXA_ORI, as is given in the list of Doc 1976487 for each table.
What are the ways in which ACDOCA records are revealed in the compatibility views for COEP, FAGLFLEXA etc?
The records of COEP that are of value type 04 are read from ACDOCA by the compatibility view V_COEP. The remaining value types, on the other hand, continue to be read from physical table COEP. There isn’t a filter on ACDOCA-MIG_SOURCE since the compatibility view is required to supply migrated line items along with those that are newly created. Rather, the selection of ACDOCA records is done by the fields of CO_BUZEI, ACCASTY and OBJNR.
The compatibility views of NewG/L, like FAGLFLEXA, reveal all records of ACDOCA apart from the correction records that were made by the migration of balances (BSTAT = C in periods > 0).
This is inclusive of items which migrated from COEP as well as correction items (MIG_SOURCE = R). As a result, it is possible to show more items in the compatibility view of FAGLFLEXA than in the old table (V_FAGLFLEXA_ORI).
What is the purpose for the migration of balances?
There is scope for disparity amid the aggregated line items and the old totals tables due to reasons such as data archiving of line items for example. It is necessary to correct these perceived differences which can be done by additional line items in ACDOCA in the step for the migration of balances.
Is it possible for me to verify the accuracy of data migration by making a comparison of the number of records that are contained in the compatibility views of COEP, FAGLFLEXA, etc. to that of the original tables?
Because of the complex nature of data model changes, it is not possible to perform simple cross checks such as counting the number of records in order to check the accuracy of the migration of data. In a number of data constellations, these numbers are likely to differ. You shall have to depend on the reconciliation checks R23 and R24 which are included in the data migration for checking its correctness.
How does data migration handle customer extensions such as CI_COBL, append structures, etc?
There is automatic inclusion of coding block extension fields in Include Structure CI_COBL in ACDOCA and these are then considered by data migration. If you have produced append structures for BSEG or COEP, look into Doc 2160045.
For what reasons are BSEG and COEP records merged/not merged into one ACDOCA record?
The merging of BSEG and COEP items into a single ACDOCA record takes place only if the following prerequisites are met:
- The FI and CO documents are required to be from the same original transaction, i.e. there has to be a match between AWTYP and AWKEY.
- There has to be a match between the company code, G/L account and cost element, business area, partner business area and assignment of accounts.
- There has to be a match between transaction currency codes and all amounts. There may also be a 1:n match BSEG:COEP if there is summarization in FI, in which case the aggregate amounts of the n COEP items have to be equal to the amounts of the BSEG item.
What is the process of filling ACDOCA fields if various source records are combined into a single ACDOCA record?
It is shown in Doc 2156822 which ACDOCA fields are found in BSEG and COEP, or in BSEG and NewG/L tables. In case a number of source tables are combined into a single ACDOCA record, it is necessary for us to perform an application priority rules for the fields that exist in numerous source tables as, in a number of cases, fields could also be initial in a few of the source tables. However, all the fields that are used to match the records of BSEG and COEP need to be identical. As for all the remaining fields, the following rules should be stuck to:
- For any field which exists in BSEG and COEP but not in NewG/L, COEP enjoys priority barring the exception of POPER, which is taken from FI at all times (this is relevant for the period of 13-16 only, if CO has a different fiscal year variant).
- If there are existing fields in NewG/L and COEP, NewG/L enjoys priority with the exception of the following fields in which CO has priority: RCNTR, SCNTR and the optional NewG/L fields ZZAUFNR, ZZHRKFT, ZZPRZNR, ZZPS_PSP_PNR, ZZWERKS, ZZKOSTL and ZZPKOSTL
- If there are existing fields in NewG/L and BSEG but the NewG/L scenario was inactive before, the value of the field will be taken from BSEG as all of the NewG/L scenarios are active and functioning in S/4HANA finance.