Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member244773
Discoverer
During S/4 Hana conversion questions often arise related to how to validate the conversion data and the line items that were posted into ACDOCA. This blog provides some background information about the postings made during conversion and references additional notes for more detailed information

 

When we convert to S/4 HANA we need to merge CO, ML and FI  data with GL data to build the ACDOCA table. Since we are coming from multiple sources into one table, when we don't have an exact match with respect to  document line items,   we may  need  multiple lines in ACDOCA.

 

Two fields have been added to ACDOCA to help identify conversion transactions MIG_SOURCE and BSTAT. The entries in these fields are used for reconciliation and to expose data in the various compatibility views

 

MIG_SOURCE will display the source of the migrated line

 











































MIG_SOURCE Source
F Migrated GL Line
G New GL (maybe CO)
C CO
M Material Ledger
A Fixed Assets
S Balance Level Correction
U Balance Level Correction
R Document Level Correction
Space Line created after conversion

 

BSTAT will display the status

 















BSTAT Status
L and Space Line item and Ledger specific lines
C Balance carry forward items or entries from balance migration. Balance correction item

 

 

The two fields used in combination will help identify the nature of the entry.

For Example: MIG_SOURCE = U and BSTAT = C => correction of GL balance to compensate for CO or AA Balance Items

 

 

Why do we need balancing entries?

There can be differences between the aggregated line items and the old totals tables, e.g. due to data archiving of line items. Published Financial statements in the past were based on totals reporting; therefore, these differences need to be corrected by additional line items in ACDOCA in the migration of balances step. Note 240803 provides more examples.



(Example from attachment in note 2408083)

 

 

Why do we have reversing entries?

In many cases, it is possible to match document lines in e.g. CO (COEP) with document lines in GL (BSEG, ACDOCA) on line item level. If this is not possible but we at least find the correct document, then we insert the CO line and the GL line into ACDOCA and reverse the double amount by inserting a correction line (MIG_SOURCE = 'R').

 

Why are there extra lines in ACDOCA related to Fixed Assets?

During the Fixed Asset Migration, additional ACDOCA line items may be generated instead of the record being merged as described in https://wiki.scn.sap.com/wiki/display/ERPFI/Additional+line+items+in+ACDOCA+table

The asset line items normally refer to a FI document, but – e.g. for settlement postings, retirements etc. – are not referenced to a single line of this FI document. Thus, we are not able to split an existing FI document line into N document lines with asset information (1: N). Instead we use the M: N migration schema in general for all FI-AA line items: All FI-AA line items will be added to the document with migration source type ‘A’ additionally to the FI-lines of migration source type ‘F’ or ‘G’. To correct the duplicate balance of the document, these lines will get reversal lines (migration source type ‘R’).

 

 

Compatibility views and data display

 

CDS views were created so that existing functions and applications (such as reporting, customer reports) that build on tables that are replaced in S/4 Hana continue to work. These are called compatibility views

 



Example of Compatibility view for table COEP

 

 

In some cases, the views themselves have been developed using filters that ensure the resulting display is comparable to the old table.  for example,  if user is displaying a document in FB03 it will be displaying the compatibility view  and not necessarily the data from the underlying table. There are some nuances in terms of which of the above MIG_STATUS entries are being selected by the compatibility views that should be taken into consideration.  Views where you can access the data without the redirect  are referenced with <view or view/table name> _ORI

 

Listed below are some examples of compatibility views and their nuances. reference note 1976487  for lists of other views.



 

 

For more information related to the Finance Data Migration may be found in these notes

2408083, 2185026 , 1976487 , 2292381 2156822 , 2159922, 2270333

 

[LD1]