If you want to implement and use SAP Accounting powered by SAP HANA, you have to migrate the existing user data from the General Ledger Accounting (FI-GL), Asset Accounting (FI-AA), Controlling (CO), and Material Ledger areas. Such a migration of data is necessary because SAP Accounting powered by SAP HANA rests on a uniform data model for all accounting areas. The universal data table ACDOCA contains all the line item documents from FI, FI-AA and CO. All postings of these applications are written to the new table after the installation and migration are complete. I describe the migration to SAP Simple Finance 1503 with the entire life cycle covering pre-migration, migration, and post-migration steps. I also shed light on real-life lessons learned during this migration. This will help companies planning to start the journey of migration to prepare and execute the process.

Pre-Checks Before an SAP Simple Finance Migration

The pre-check is a set of programs run to check the correctness and compatibility of the existing system. During all the test phases (e.g., sandbox, unit, and quality box) I would suggest you run the pre-check and migration on a dump of production. It is done before any kind of upgrade or installation. Furthermore, it is prudent to ensure consistency across modules. SAP proposes the use of some transaction codes that are covered in the Financials Expert article titled “Plan Your SAP S/4HANA Finance Migration with These Tips.” For a more comprehensive check, SAP provides some reports that can be installed via SAP Notes. Here are the details: Check prerequisites for New Asset Accounting: (SAP Note 1939592). Among other things, the report checks:

• If a depreciation area for each parallel currency exists
• If the periodic posting needs to be run
• If there is any component (e.g., classic real estate or joint venture accounting) that the new FI-AA does not support

Check customizing settings: (SAP Notes 2240666 and 2129306): Among other things, the report checks:

• If the currency settings are consistent and adaptable by SAP S/4HANA tables
• If the fiscal year variant of the company code and controlling area are consistent
• If the company code validation checkmark is set in the controlling area
• Are there any valuation scenarios (e.g., transfer prices) that are not compatible with SAP S/4HANA Finance?

Download report RFINDEX_NACC, which is a very comprehensive check report. I recommend you run it at least with the option Indexes vs. Documents for a start. The results will highlight any discrepancy between the table BSEG and index tables (BSXX). Any discrepancy found in the above check reports should be rectified before proceeding.

Configuration Steps

Several configuration steps for migration of the SAP General Ledger, CO, new FI-AA, and house banks are required, and I describe some of the important ones in this section. After the successful installation of the SAP Simple Finance 2.0 add-in, the SAP Project Reference Object (SPRO) screen menu has a new node as highlighted in Figure 1. The new node consists of sub-nodes with a logical sequence (Figure 2) to which you need to adhere. The first step is activation of business functions. The following business functions should be activated via transaction code SFW5:

• EA-FIN (Financials Extension)
• FIN_GL_CI_1 (New General Ledger Accounting)
• FIN_GL_CI_2 (New General Ledger Accounting 2)
• FIN_GL_CI_3 (New General Ledger Accounting 3)

The above business functions need to be selected and activated by clicking the active checkbox. Figure 3 lists important configuration steps required before you run the migration transactions. I discuss three of these steps:

• Preparations and Migration of Customizing for General Ledger
• Preparations and Migration of Customizing for Asset Accounting
• Preparations and Migration of Customizing for Controlling

Preparations and Migration of Customizing for General Ledger

To complete the Preparations and Migration of Customizing for General Ledger, you have to complete several steps. I describe the steps in this section.

Migrate General Ledger Customizing

To complete this step, click the execute icon beside the Migrate General Ledger Customizing node (Figure 4). The system updates the following tables after you click the execute icon (These tables are needed in the next step, which is Define Settings for Journal Entry Ledger):

• FINSC_LD_CMP: Comp Code-Dependent Settings for Unified Journal entry ledger
• FINSC_LD_CMP_AP: Ledger + Company Code + Accounting Principle
• FINSC_LEDGER: Universal Journal Entry Ledger

Define Settings for Journal Entry Ledger

To complete this step, click the execute icon beside Define Settings for Journal Entry Ledger as shown in Figure 5. With SAP S/4HANA Finance, the most important attributes of the company code now can be seen in a single dashboard. After you click the execute icon, the system displays the screen in Figure 6. In case you want to make another non-leading ledger, click the New Entries button highlighted in Figure 6.

Define Document Type Mapping Variants for CO Business Transactions

Another important configuration is to maintain the document type mapping variants. In SAP Simple Finance 1503, the accounting documents are generated even if there is a cost movement within CO. A document type for such scenarios is required, and the configuration provides flexibility for having separate document types for separate controlling business transactions. Click the execute icon beside Define Document Type Mapping Variants for CO Business Transactions (Figure 9) to display the screen shown in Figure 10. The document type variant buckets all standard CO business transactions. I suggest that you not use the standard 0000000100 variant, but rather create a new one (Z0000000100) by copying 0000000100 and selecting the check box in the Default Variant column to make it a default variant. After you create a new variant and make it a default variant, select the new variant and click the Mapping of CO Bus Transaction to Document Types folder. This action displays the screen shown in Figure 11 in which you provide the document type that the SAP system should use while posting FI documents for CO-initiated transactions. In the next configuration step, the document type mapping variant (created in an earlier step) is assigned to the company code (Figure 12). Here a default ledger group is also entered. A point worth mentioning in Figure 12 is the Default Ledger Group field. Any FI accounting document generated as a result of cost flows uses the ledger group mentioned in this configuration (unless specifically mentioned — for example, via transaction code KB11N). In some of the CO transactions (for example, transaction code KB11N), the SAP system provides the flexibility of quoting a document type and ledger group as shown in Figure 13. Any entry of a document type and ledger group at the transactional level supersedes the configuration settings.

Define Source Ledger for Migration of Balances

During migration, the system needs to know how line items and balances need to be filled in table ACDOCA (universal data table). This configuration decides which tables will be looked upon at the time of filling in table ACDOCA. For example, consider a scenario in which a customer has the specifications shown in Figure 14. In that situation, data for table ACDOCA is picked from table BSEG/GLT0 (for years 2008 to 2011) and FAGLFLEXA/FAGLFLEXT (from year 2012 onward).  

Preparations and Migration of Customizing for Asset Accounting

Before I explain this step, it is important to understand that FI-AA has undergone critical changes. One of the prominent changes is visible while comparing Figures 15 and 16. Before S/4HANA Finance (Figure 15), the target ledger group could be given manually for every depreciation area, but with S/4HANA Finance (Figure 16), the target ledger group is determined automatically via the accounting principles. The above transformation of populating account principles and target groups occurs by clicking the execute icon beside Migrate Charts of Depreciation (Figure 17). This step does the following:

• Assigns the accounting principle and ledger group
• Adjust the option of how to post to the SAP General Ledger
• Adjusts the transfer of Acquisition and Production Costs values
• Adjusts the transfer of depreciation terms

The next step is to continue with the new FI-AA configuration. Some of the important configuration steps include these three:

• Define Asset Balance Sheet Accounts of Parallel Valuation as Reconciliation Accounts: This step is required in case you are migrating from the classic General Ledger and there are multiple depreciation areas that post to the SAP General Ledger via different general ledger accounts per depreciation area.
• Specify Alternative Document Type for Accounting-Principle-Specific Documents: With the new two-step posting approach for asset acquisition, the new FI-AA functionality provides you with flexibility for specifying a specific document type for asset-relevant journal entries. If nothing is specified, the system uses the entry document type.
• Define Clearing Accounts for Non-Integrated Asset Acquisition: This step is an extension of the previous step. With the two-step approach, SAP requires a clearing account. You have the flexibility to choose separate clearing accounts per asset class should there be a business requirement.

Check Prerequisites for Activating Asset Accounting (New)

The penultimate step in the new FI-AA is to run the check report Check Prerequisites for Activating Asset Accounting (New) as highlighted in blue in Figure 18 to make sure new FI-AA can be activated. To run this report, click the execute icon beside Check Prerequisites for Activating Asset Accounting (New). After the check report gives you a favorable result, click the execute icon beside Check Prerequisites for Activating Asset Accounting (New) as shown in Figure 18 to activate new FI-AA . In the screen that appears (Figure 19), select the Actv. option to activate the new FI_AA and save your settings.

Preparations and Migration of Customizing for Controlling

If you are using CO-PA, then the next step is to adapt settings for profitability segment characteristics (Figure 20). This step deletes the segment-level characteristics that were earlier defined via transaction code KEQ3. This is done for all operating concerns that have account-based CO-PA. Before SAP S/4HANA Finance, it was hard for the system to query huge line item tables (CE1XXXX) due to performance issues. Therefore, the configuration for segmental tables (CE3XXXX and CE4XXXX) made sense as they would hold the segmental characteristic information that was relatively lesser and faster to query upon. However, with the introduction of SAP S/4HANA Finance, performance is not an issue at all, which also means you do not need to select only some characteristics as segmental, and that’s why this step deletes the segmental level characteristics. The next step is to activate the operating concern in the following sequence:

1. Run program FCO_ADD_COPA_FIELD_TO_ACDOCA (via transaction code SE38) to add new CO-PA characteristics to ACDOCA.
2. After running the program, use transaction code KEA0 to activate the operating concern.

Preparations for Migration of House Bank Accounts

There are some technical steps (Figure 21) that need to be done to use the new bank account management (BAM) functionality. BAM replaces the bank accounting function. The first two steps pertain to number ranges. The last step, Define Settings for Bank Account Master Data, assigns the number range IDs in the system as shown in Figure 22. You can also define account types, which is a new attribute in SAP S/4HANA for bank accounts. There are other important features that can be defined in this configuration step, but they are available with Cash Management powered by SAP HANA, which requires a separate license.

Migration Steps

Migration, as can be seen in Figure 23, is a set of sequential steps that involves migration or population of a new structure or enrichment of existing tables. Regenerate Core Data Services (CDS) Views and Field Mapping: This step generates compatibility views for general ledger, controlling, banks, assets, cash, and management. It redirects read access from tables to views (e.g., redirect from table BSID to view BSID). It also regenerates the mapping of customer-specific fields. The output of the program should be carefully audited to see if there are any errors in generation. Migration of Cost Elements: This step checks if there are any inconsistencies in the cost element (e.g., some primary cost elements exist without a corresponding general ledger master data account).The expected results of check passed and zero errors highlighted in red (Figure 24) should be ensured before proceeding further; expected results can be viewed in Figure 24.

Steps for a Technical Check of Transactional Data

The steps shown in Figure 25 are to check and reconcile the consistency of data. Analyze Transactional Data: This step checks the general ledger account open items and open items for accounts receivable and accounts payable. Among other things, it compares the data from BSEG and index tables (BSI* and BSA*). Any inconsistency found needs to be resolved. This is a repeatable step and can be run as many times as required (before the migration check is set). Reconcile Transactional Data: This step reconciles the transactional data in CO, FI-AA, the Material Ledger, and the general ledger It goes a step further and also audits general ledger account tables and reconciles them with BSEG. Some of the prominent checks follow (but are not restricted to these):

• Compare table BKPF with BSEG
• Compare table COBK with COEP
• Compare FAGL tables with BSEG
• Compare database views with the backup tables.
• Compare Asset master data tables with asset configuration tables.

This is a repeatable step.

Steps During Migration for Enrichment of Data

The steps shown in Figure 26 enrich the existing tables. Enrich Transactional Data: In the earlier version without SAP S/4HANA, the line item tables did not store any reference (e.g., table COEP did not store any reference of its relevant financial document), but this has changed for a speedier query result. In SAP S/4HANA, the line item tables COEP and BSEG store a reference transaction (AWTYP) and reference key (AWKEY) for a quick reference to each other. This is a great help when the system builds ACDOCA. Briefly, this step enriches tables by filling:

• BSEG-fields from BKPF
• COEP from COBK and OBJNR
• Profit Center fields into CO line items
• Company code data into old CO line items
• Company code data into old CO totals
• BSEG_ADD from FAGLBSIS/AS
• COSP_BAK-BUKRS and COSS_BAK-BUKRS

This is a repeatable step. Check of Migrated Documents: This is a follow-up check step after the transactional data has been enriched in the earlier step. It checks the BSEG/BKPF fields and also verifies that the BSEG balance is zero. From a CO perspective, it checks if the field BUKRS (company code) is filled up properly. It also checks that the fields ACCASTY (object type), AWTYP, and AWKEY are updated in table COEP.

Migration of Line Items into a New Data Structure

This is one of the most important steps in the migration tree (Figure 27). It builds up ACDOCA from the line items. Migrate Accounting Documents to Universal Journal Entry Structure: This step populates table ACDOCA. The document entry in table ACODCA is also called the Universal Journal Entry (UJE) as it combines all relevant sub-modules into a single data string. In the case of CO-PA, UJE also encompasses all the CO-PA characteristics. This step is not repeatable. There is a reset process. If you need to repeat this step, you must reset the tables. This reset process is discussed later. Check Migration of Accounting Documents to Universal Journal Entry: In this step, the UJE (table ACDOCA) is checked in terms of granularity and amounts. This step is necessary to ensure that ACDOCA holds the correct characteristics and values. While the system performs the check, the following tables or former tables are considered:

• General ledger tables (BSEG/BKPF)
• CO tables (COEP/COBK)
• External and internal total tables for CO (COSP, COSS)
• SAP General Ledger line item tables, including industry and customer tables
• Document header (ANEK) and line items (ANEP) for new FI-AA

This step also compares the compatibility views with the original values. This step is also a repeatable step. Migrate General Ledger Allocations: The SAP General Ledger allocation before SAP S/4HANA Finance read the data from table FAGLFLEXT (in the SAP General Ledger) or GLT0 (in the classic General Ledger). With the introduction of SAP S/4HANA Finance, however, there is not any totals table, and therefore, the program code needs to be redirected to a view ACDOCT (Figure 28). This step does the redirection. It processes the entries of table T811*.  

Migration of Balances

Not everything can be populated from line items—for example, balances from carry forward or archived historic line items. The amount for such line items is calculated by comparing the sum of the line items with the old totals. The steps under Migration of Balances, as shown in Figure 29, populate the balances in table ACDOCA. Migrate Balances: This step populates ACDOCA again, but unlike the earlier step of line item migration, this step migrates only balances. Such balances can erupt from a mismatch of line item tables versus totals tables. Any genuine mismatch is inserted in ACDOCA. This ensures that the totals in various components are the same as before. The step covers FI-AA, CO, the SAP General Ledger, the Material Ledger, customer balances, and vendor balances. If you need to repeat this step you have to reset the tables. Check Migration of Balances: After table ACDOCA has been updated with totals (in the previous step), the system tries to match the results. This step compares the totals table (*_BAK/*_BCK) with table ACDOCA. Table 1 lists some of the backup tables and views that are used during processes for this step.

Process	Table or view
Asset management	ANLC, ANEP, ANLP
CO	COSS, COSP
Customer or vendor balances	KNC*, LFC*
Material valuation	MBEW

Calculation of Depreciation and Totals Values During Migration

These steps shown in Figure 30 calculate depreciation and compare it with the earlier depreciation amount. Calculate Initial Depreciation Values: This step calls the program FAA_DEPRECIATION_CALCULATE and re-calculates the depreciation. Furthermore, it populates the new table FAAT_PLAN_VALUES. Check Initial Depreciation and Total Values: This step checks the earlier depreciation and the new one. Any change appears as an error. The list of such assets with errors can be obtained by running program FINS_MIG_AA_CHECK_RC45. This program is helpful in both checking the initial depreciation and checking the migration of balances as shown in Figure 31.

Migrate House Bank Accounts

With the introduction of SAP S/4HANA Finance, bank accounting has changed. The new solution is called Bank Account Management (BAM). From a bank accounting perspective, the bank account master data in BAM has far more details in its master data and can be configured via Webdynpro. In the new world the house banks are not customizing objects, and the data from former table T012K is copied into a new table: FCLM_BAM_ACLINK2 which has some more attributes. New attributes (e.g., saving or current or other account type) can be assigned to bank accounts. All these activities can be done via the Migrate House Bank Accounts step as shown in Figure 32.

Complete the Migration

It is important to understand that this step cannot be undone, so the first check should be to run the reports again and compare them with the reports taken before SAP S/4HANA Finance. After the business confirms the accuracy of the reports, the next step is to mark the system for migration complete (Figure 33). To do this step, click the execute icon beside Set Migration to Completed.

Post-Migration Steps

Figure 34 shows the post-migration steps. These steps ensure that the due dates and offsetting account are filled in in table BSEG.

Tips

Here is a list of tips for you to review:

1. Make sure to regenerate all the reports in the relevant library for cost center, vendors, and customers after the migration is completed. Use transaction codes GR55, FDIM, and FKIM for the purpose.
2. Make sure that the general ledger technical clearing account for the integrated asset acquisition is made before releasing the system to the business.
3. Update the financial statement versions to include all the general ledger accounts (secondary cost elements and asset technical clearing account).
4. Make sure that the new document type CO is configured for document splitting properly.
5. The transaction code FINS_MIG_STATUS provides a bird’s-eye view of the migration steps and their status (Figure 35). You can go directly to the relevant migration step by clicking it. Other details can be found under the tabs Control and Tables.

At times the errors for a single migration step can run in the thousands, divided under several packages. In such cases an Excel dump to analyze all errors can be of great help. However, such an Excel dump functionality of all errors in all packages is not available. A workaround is to query the following tables in transaction code SE16n. These tables provide all the errors in a single screen and taking an Excel dump of all of them now becomes possible.

• FINS_MASSPACKAGE: Package details on the basis of the step run
• FINST_RECERR_ACD: Reconciliation error ACDOCA
• FINST_RECERR_CT: Reconciliation error GL (customer tables)
• FINST_RECERR_CTG: Reconciliation generic error GL (customer
• FINST_RECERR_FI: Reconciliation error AP/AR/GL
• FINST_RECERR_GEN: Reconciliation error (generic)

Table 2 shows how various migration steps can be reset and re-run.

Activity	Description	Re-run?	Reset
R20	Analysis of transactional data	Yes	FINS_MASS_DATA_RESET Set ID > R20
R21	Reconciliation of transactional data	Yes	FINS_MASS_DATA_RESET Set ID > R21
ENR	Enrich transactional data	Yes	FCO_MIGRATION_RESET FINS_MASS_DATA_RESET Set ID > ENR
R22	Check enrichment of transactional data	NA	FINS_MASS_DATA_RESET Set ID > R22
MUJ	Data migration into unified journal: line items	No	FINS_MIGRATION_UJ_RESET FINS_MASS_DATA_RESET Set ID > MUJ
R23	Check migration of journal entry	NA	FINS_MASS_DATA_RESET Set ID > R23
DLT	Data migration into unified journal: aggregate deltas	No	FINS_MIGRATION_DLT_RESET FINS_MASS_DATA_RESET Set ID > DLT
R24	Check migration of balances	NA	FINS_MASS_DATA_RESET Set ID > R24
AFA	Initial depreciation calculation	Yes	FINS_MASS_DATA_RESET Set ID > AFA
R25	Check initial depreciation calculation	NA	FINS_MASS_DATA_RESET Set ID > R25