I discuss a project in which I was involved – that is, a merger of two separate independent entities (e.g., A, Inc. and B, Inc.) to form a single entity (C Combined, Inc.). This business consolidation involves the merger of the financial figures along with other data. I concentrate here on three important components of the trial balance: Accounts Receivable (AR), Accounts Payable (AP), and the General Ledger (GL) data.

This example project provides detailed functional and technical approaches to data migration. Although it is based on a classic GL environment, conceptually the same logic can be extended to an SAP General Ledger or New GL environments.

The functional part covers the solution approach that an FI functional team can follow. The technical part is a guide for ABAP developers and also the functional consultants to build the program logic.

The Functional Solution

Functional experts deal with migrating data from AR and AP, including one-time accounts (OTA), as well as from the GL. The GL includes open-item-managed GL and non-open-item-managed GL.

AP and AR Data

The first step is to ensure that you create the source customer, vendor, and GL master data of the merging companies in the resulting company. If there is some common AR, AP, and GL master data existing in both entities, you have to ensure that you follow a unique set of common master data that is in the resulting company’s GL, AP, and AR master. This situation could occur when both companies belong to the same group company, but operate separately, or if they have the same set of supplier or customer master data.

The next step is to identify the detailed data to be migrated (i.e., all the data fields that need to be migrated). This step is important because post merger, any missing data contents of the source document can lead to issues such as reporting problems or reconciliation difficulty.

For example, if you move an AR line item to the new company, but you don’t migrate the due date terms, the payment terms, payment method data, or discount base amount, then it is difficult to arrive at the true AR value or accounting of a receipt. The absence of the information from the source company’s AR line item causes a reporting problem.

During this step you jot down the important AR and AP fields. Give special consideration to one-time customer or vendor account records because they have specific details, such as address fields and bank details, that change for each transaction line item. This is because, unlike regular customer or vendor master records, for one-time customer or vendors the above field contents are dynamic and may change for each individual open line item. For ease of processing, follow an identical set of data fields for AR and AP. A set of such fields is listed in Table 1. This table also includes the business application programming interface (BAPI) fields, which I discuss later.   

Table 1

Customer or vendor data, SAP table field, and field in BAPI

While reviewing the data output from Table 1, you may find that many fields are blank in most of the line items and only a few line items have data in them. However, it is better to be prepared to ensure you don’t lose any information to be migrated. The most important point here is to receive approval of the information list (i.e., the document level source information that you intend to migrate) from business managers.

The GL

Now let’s check the GL items. Table 2 lists important data fields to be considered for GL data migration.

Table 2

GL Data, SAP table field, and field in BAPI BAPI_ACC_DOCUMENT_POST

The list in Table 2 is also an exhaustive list to ensure that nothing important is missed. One point to note, however, is vendor account (a/c) and customer a/c number details. These details are not of much use in this approach because they are indirectly covered by AP or AR data. However, I added these two fields (row numbers 19 and 20 in Table 2) in case there is a business request to add them for some specific reporting. If there is no such request, then you can ignore these two fields.

Now that you have finalized the fields to be considered for migration, the next step is to determine how to extract this data. I suggest you use standard SAP reports FBL1N for vendor balances, FBL3N (or FAGLL03 in the SAP GL environment) for GL balances, and FBL5N for customer balances downloading.

If you run these reports you may find that some fields listed in Table 2 are not available in the standard report even if you have checked all the fields in the Change Layout window (e.g., House bank). So how do you get them? The answer lies in the special fields that you can browse by following menu path Settings > Special Fields. You receive the following message: Caution: The table is cross-client. It’s a standard SAP message to draw attention that any changes here affect all the SAP systems in that client. After clicking Yes on the warning window, you reach a screen called the Line Layout Variant Special Fields overview (Figure 1).

Figure 1

The Line Layout Variant Special Fields screen

If you click the New Entries button, you are taken to a screen in which you have to choose the source table, such as BSEG Accounting Document Segment, Field Name, HBKID House Bank, or EMPFB for Payee (Figure 2). Once you have added the required fields, your data table format is ready. You have to transport these special fields to the production system from your development system. Even if you add them only in FBL5N or FBL3N, you can see them in all three standard reports: FBL1N (or FAGLL03), 3N, and 5N. All the above fields are either in the standard layout, or you can add them through the special fields approach.

Figure 2

The New Entries screen for Special Fields

Choose the maximum field width (i.e., line width) to ensure that when you transfer the source data you do not lose any information resulting from insufficient field width (Figure 3). This step is important in cases such as Assignment or Line Item Text.

Figure 3

The Change Layout window

Once these steps are complete, you are done with the data download format.

Data Migration or Merger

The next task is to determine what data needs to be downloaded and considered for migration or merger. It may not be necessary to transfer all the data from the source company. You can ignore intercompany balances from the open customer receivable or AP data because these balances need to be squared off if the companies in question are to be merged ultimately.

Similarly, in the case of GL balances, there are open-item-managed accounts and non-open-item-managed accounts. For open-item-managed GL accounts, the line items are either marked as clear or as open. Transfer the open items only. For open-item-managed accounts, you do not need to transfer the GRIR accounts as is and you need to clear the GRIR accounts first so that everything that matches comes to zero. This way, the total number of line items that needs to migrate is reduced significantly. You then transfer only the remaining open items.

The GLs that are not marked as open item managed are called non-open-item-managed GLs. In the case of non-open-item-managed accounts, because the line items are large in number, you need to transfer only balances as on the date of transfer. In these cases, you can choose to summarize them by currency and by business area to transfer the non-open-item-managed GLs in a more meaningful way.

Now that you know which data to migrate and which format to use for data transfer, you are ready to learn how to move the data. Now you enter the technical phase of this article.

Technical Solution

You have two options for data migration. The first one is to use Legacy System Migration Workbench (LSMW), and the second one is through BAPIs. To decide which to use, I considered the total number of line items to be migrated for AP, AR, and GL. I found that the number of line items exceeded 150,000. In this case, the advantage of the LSMW approach is that it involves minimal ABAP programming and is user controllable. However, the main disadvantage is the time it takes to post the data.

In my case, I calculated that because it follows a Batch Data Communication (BDC) approach, I might need from 24 to 36 hours of system downtime. This was too long a time to wait. So, I looked into the BAPI approach. The disadvantage here was that it involves a lot of ABAP involvement, but on the other hand, it takes far less time. I calculated that in my case, for the above amount of data, the task could be completed at the most in three to four hours. Therefore, I decided to go for the BAPI approach because the overall task completion time taken would be less, without compromising the quality of delivery.

The best BAPI method of data transfer is BAPI_ACC_DOCUMENT_POST. This is one of the BAPIs that contain all the fields I selected for the AL, AR, and GL data.

Now the task is to map these fields for your data source field. Similarly, for the header data and one-time customer or vendor data, you have to look into the import parameter window. The import parameter window is the header part of the BAPI BAPI_ACC_DOCUMENT_POST, which you can access through transaction code SE37.

The mapping information is included in Tables 1 and 2 as a guideline. H denotes header data, and L denotes line item data. From the data listed in Tables 1 and 2 you can understand that you have to provide the data for upload in an Excel format. However, for the SAP system to understand it, you have to convert it to .txt format before you submit it for data upload into an SAP system.

At this stage you have to do the necessary ABAP coding to read the data from the supporting files and then to load them into the SAP system using the BAPI BAPI_ACC_DOCUMENT_POST.

The ABAP coding needs to take care of the following:

Because the BAPI just fetches the data to create the posting, you have to add a commit statement to do the actual posting. In ABAP terms, commit means that when a program processes data to place it in a table or report, it keeps the data in buffer memory and places it in the table only once a commit statement is found in the program. It is better to create a commit after the program reads each line and sends an error message, if the posting is not possible for some reason.

Once the BAPI reads a line from the input file and finds that the line has all the details to create an SAP accounting document successfully, a set-off line item is created with all the contents of the source document. It includes the amount with the reverse sign and uses the set-off GL account. For example, if the source document is a customer line item with a debit amount of $100, then the program creates a set-off line item with all the line item details, but uses the credit value of $100 and the set-off GL account chosen. Thus, a complete balanced document is created. Note also that the logic of the program is to create a separate document for each line item without having to wait for the whole file to be balanced.  

However, while reading the input file, if the BAPI finds that one line item has some data that prevents it from creating an SAP accounting document, then it reports an error. The error reported should be detailed enough for the functional expert to understand. This is because the functional expert understands the issue if there is anything missing that is preventing the above BAPI (BAPI_ACC_DOCUMENT_POST) from creating an accounting document. A proper posting key needs to be identified by the program (by way of ABAP coding) to ensure that the positive and negative values are properly accounted for.

The program should provide for both desktop upload and upload from a server and through background mode. Large volumes of data may cause the system to time out during foreground processing. The program should also provide for a test upload mode to show error messages, if any, to allow you to do the necessary fix.

The program should create a single BDC session for all the errors for each run. It also should be capable of understanding non-English characters such as Japanese or Chinese. Another important point is that the program should provide for maximum field length in each data field to ensure that no source data is missed or cramped while uploading the data from the source. The document type to be used for posting the transfer documents should be a unique one for easy identification of those sets of documents. For ease of cross-referencing the source document to the resulting document in the new company code, the program should include the source company document number in one of the header fields of the resulting document (e.g., Document Header text field).

Accounting Aspect of the Migration Logic

Now that you have decided which GL, AP, and AR data needs to be moved to the new company code, you are ready to learn about the accounting postings for compliance with the double-entry bookkeeping concept.

First, decide on setting off the GL account each for the GL, AP, AR and fixed assets. Let me explain here why you need a set-off GL for GL, AP and AR separately. When you want to migrate a GL item with a debit balance, it needs a second line item in line with the double-entry bookkeeping principle. Therefore, you need a line with a credit balance.

To create this line, use all the details of the above GL line item, replace the debit balance with a credit balance (and vice versa), and use the set-off GL. Similar to the case of AR and AP balances, you use different set-off GL accounts. Taking separate GLs for AP, AR, and GL is a good practice for better control over each of their balances. Because you are transferring the entire trial balance or balance sheet to the new company, the net balance of the set-off GLs is also zero as is the source trial balance. You have to ensure that you take unique set-off GLs without any balance in them from the start.

Let me explain the posting logic in detail through this example. Suppose you have to migrate this trial balance to a new company code. Table 3 includes an example.

Table 3

An example of a trial balance

The resulting postings (I am taking just 1 GL 999999 to keep the discussion short) in the new division are:

Cr Capital & Reserves                        100

Dr 999999                               100

Cr Loans                                             200     

Dr 999999                               200

Cr AP & Other Liability                                 300

Dr 999999                               300

Dr FA                                      150

Cr 999999                                           150

Dr Other Asset                        250

Cr 999999                                           250

Dr AR                                     200

Cr 999999                                           200

Thus, the net balance in your set-off GL accounts is zero.

The Data Migration Tool

Using the above logic and the BAPI BAPI_ACC_DOCUMENT_POST, you develop the data migration program. I call it the data migration tool. The input fields provided in the data migration tool give the option to choose the file to be uploaded either from the desktop in foreground mode or from a server through background processing.

The company code in this case is the resulting company code. There is a unique set-off GL for each AP, AR, or GL. When you choose AP, the set-off GL automatically pops up. If the user chooses GL, then the set-off account for GL appears. This check ensures that the user doesn’t use an incorrect GL. It is always advisable to use different set-off GL accounts for AP, AR, GL, and fixed assets. This check helps you reconcile data from the source company and resulting data in the new company code. I used a unique document type for easy identification of data migration related postings. I recommend that you provide for a test run to check everything before running the update mode run. An error message should pop up if the user tries to input a company code or document type that differs from what the project intends.

Validation and Reconciliation of Source Data to That in Resulting Data

Once you are ready with your data migration tool, download the AP, GL, and AR data on a particular cut-off date using transaction codes (FBL1N, FBL3N/ FAGLL03, and FBL5N) in the format I discussed earlier. Once you download the data and verify it for accuracy parameters, provide the source data you are going to migrate to the business and receive its sign-off. Once sign-off is received, load the data to the resulting company through the utility you created.

Once you upload the data and fix any errors, download the AP, GL and AR data from the resulting company and submit the data to business for data validation and reconciliation. This is the final validation from business to give the sign-off that the final resulting data matches with the source data. The reconciliation is done by comparing not only the download total against that in the upload file and source file but also the reconciliation accounts. In the case of AP and AR, there may be more than one reconciliation account. You need to add all the reconciliation GL account balances with the totals of the AP and AR balances.

The data validation involves checking if all the data fields in the resulting document have been updated in line with what is in the source file (e.g., one-time account details or non-English characters such as Japanese and Chinese). Once the reconciliation and validation are complete, the data migration task is completed.