Consultant Handbook for New GL

SAP AG Internal and Confidential

© 2005 SAP AG Neurottstr. 16 D-69190 Walldorf

Migration to New General Ledger Accounting in mySAP ERP 2005 � Guide for Consultants Version: Draft Date: 07/01/2005

Page 1 of 53

Version: Draft SAP AG

Release: ECC 6.0

Migration to New General Ledger Accounting in mySAP ERP 2005

Migration Guide for Consultants (Draft)

History

Version Date Title

Draft

July 2005

Draft Version for SAP Consultants

Migration to New General Ledger Accounting

in mySAP ERP 2005

Guide for Consultants

Release: ECC 6.0

Page 2 of 53 Migration to New General Ledger Accounting in mySAP ERP 2005 � Guide for Consultants Version: Draft Date: 07/01/2005

© 2005 SAP AGNeurottstr. 16

D-69190 Walldorf

Contents 1 Overview ..........................................................................................................................5 1.1 Preliminary Remark .....................................................................................................................5 1.2 The Object of This Guide ............................................................................................................5 1.3 What This Guide Has To Offer ....................................................................................................7 1.4 Migration is a project...................................................................................................................9 1.5 What This Guide Does Not Offer ................................................................................................9 1.6 Prerequisites..............................................................................................................................10 1.7 Phase Model for the Migration..................................................................................................11 2 Quick Migration for Basic Scenario ............................................................................12 2.1 Phase 0: Time Preceding Migration Date.................................................................................12 2.2 Phase 1: Time After Migration Date..........................................................................................14 2.3 Phase 2: Time After Activation Date ........................................................................................20 3 Migration in Detail .........................................................................................................21 3.1 What Migration Entails ..............................................................................................................21 3.2 The Steps of a Migration Project ..............................................................................................22 3.2.1 Analyzing the Initial Situation .......................................................................................................23 3.2.2 Analysis of Desired Target Scenario............................................................................................26 3.2.3 Customizing Required .................................................................................................................26 3.2.4 Validation of Document Splitting ..................................................................................................27 3.2.5 Performing the Migration .............................................................................................................27 3.3 Overview of Changes ................................................................................................................28 4 Migration Scenarios......................................................................................................30 4.1 Overview of a Migration Process..............................................................................................30 4.2 Overview of Scenarios ..............................................................................................................32 4.2.1 General Starting Point of All Scenarios........................................................................................32 4.2.2 Migration to an Environment Without Document Splitting ............................................................33 4.2.2.1 Description of Migration Steps .....................................................................................................33 4.2.2.2 Building Data in New General Ledger Accounting Without Document Splitting ...........................34 4.2.2.2.1 Transfer Open Items .........................................................................................................34 4.2.2.2.2 Transfer Balance Carryforward .........................................................................................34 4.2.2.2.3 Document Transfer of Current Fiscal Year ........................................................................36 4.2.2.3 Considering Integration Aspects ..................................................................................................36 4.2.2.3.1 Integration with Asset Accounting (FI-AA) .........................................................................36 4.2.2.3.2 Integration of Treasury and Risk Management..................................................................37 4.2.3 Migration to an Environment with Document Splitting..................................................................37 4.2.3.1 Description of Migration Steps .....................................................................................................37 4.2.3.2 Checking and Building Data in New General Ledger Accounting with Document Splitting...........39 4.2.3.2.1 Validation of Document Splitting........................................................................................40 4.2.3.2.2 Processing Open Items .....................................................................................................41 4.2.3.2.3 Document Splitting for Documents from Current Fiscal Year ............................................45 4.2.3.2.4 Transferring Documents from Current Fiscal Year ............................................................46 4.2.4 Migration with Parallel Accounting ...............................................................................................48

Release: ECC 6.0 Migration to New General Ledger Accounting in mySAP ERP 2005




Page 3 of 53

4.2.4.1 Retention of Accounts Approach in New General Ledger Accounting .........................................48 4.2.4.2 From Accounts Approach to Ledger Approach in New General Ledger Accounting ....................51 4.2.4.2.1 General Considerations for the Transition from Accounts Approach to Ledger Approach .51 4.2.4.2.2 Foreign Currency Valuation at End of Prior Fiscal Year with Reversal Posting .................53 4.2.4.2.3 Foreign Currency Valuation During Fiscal Year at Period End of Current Fiscal Year

(Phase 1) .....................................................................................................................................53 4.2.4.2.4 Integration with Asset Accounting (FI-AA) .........................................................................54 4.2.4.2.5 Integration of Treasury and Risk Management..................................................................56 4.2.4.2.6 Replacement of Parallel Accounts.....................................................................................56 4.2.4.2.7 Evaluating Ledger-Specific Postings in Phase 1 ...............................................................56 4.2.4.2.8 Depreciation Area Switch in FI-AA ....................................................................................57 4.2.5 Special Features in the Migration ................................................................................................57 4.2.5.1 Migration to Multiple Ledgers.......................................................................................................57 4.2.5.2 Migration When Using Segment in New General Ledger Accounting ..........................................58 4.2.5.3 Migration When Using Adjustments .............................................................................................59 4.2.5.4 Migration with Previous Use of Profit Center Accounting .............................................................62 4.2.5.5 Migration When Using the Reconciliation Ledger ........................................................................62 4.2.5.6 Migration with Customer Fields....................................................................................................62 4.2.5.7 Which Data Is Not Migrated? .......................................................................................................63 4.2.5.8 Subsequent or Retrospective Postings ........................................................................................64 4.2.5.9 Clearing / Payment of Open Items from Previous Year(s) ...........................................................64 4.2.5.10 Special Features with FBCB (Post Balance Carryforward for Ledger Group) ..............................64 4.2.5.11 Migration and Archiving ...............................................................................................................65 4.2.6 Special Scenarios ........................................................................................................................65 4.2.7 Activities After Successful Migration ............................................................................................65 4.2.8 What To Do If Migration Delivers Incorrect Results .....................................................................66 4.3 Changed Standard Processes (processes that ran differently previously) ..........................68 5 Additional Options ........................................................................................................70 5.1 Hints and Tips............................................................................................................................70 5.1.1 Performing Migration Programs in Parallel...................................................................................70 5.1.2 Multiple Migration Plans with Non-Calendar Fiscal Year..............................................................70 5.1.3 Custom Selections for Fields in New General Ledger Accounting ...............................................70 5.2 Contact .......................................................................................................................................69


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

1 Overview

1.1 Preliminary Remark

This consultant guide is a publication covered by the German Copyright and Related Intellectual Property Rights Act and all parts of the guide are copyrighted. Any exploitation of the material herein that is not expressly permitted by the copyright must first be agreed upon with SAP. This applies in particular to reproductions, translations, microfilming, and storing and processing in electronic systems.

Great care was taken when compiling the texts, links, and graphics, but we cannot completely rule out errors. Consequently, no responsibility can be assumed for the accuracy and completeness of the information in the following documentation, and the user alone bears responsibility for its verification. Furthermore, SAP cannot be held accountable for any explicitly or implicitly expressed guarantee of the document�s marketability or appropriateness for a given purpose. Moreover, SAP reserves the right to revise this document without prior notice and to make changes to the document�s contents without being obliged to inform any persons or organizations.

SAP cannot be held responsible for any damage resulting from application of this document, regardless of the legal justification. SAP also does not assume any responsibility for the contents and security of any third-party Websites referred to with links in this document.

1.2 The Object of This Guide

New General Ledger Accounting combines a variety of existing methods of representation and also delivers new methods. The totality of these options requires each customer wanting to use them to tackle two challenges:

• Which functions are required from the business view?

o Which ledgers are required besides the leading ledger?

o Is document splitting required?

o Should segment reporting be possible?

• Setting out from the customer�s current situation (such as classic General Ledger Accounting, accounts approach, no document splitting), what steps must the customer undertake in order to be in a position to use the new functions? This question has a business aspect, such as the implementation of account assignments that did not exist before, and a technical aspect � what needs to be migrated.

This guide assumes that you want to perform the transition from classic General Ledger Accounting (installed operationally with R/3 Enterprise or an earlier release or with mySAP ERP 2004) to New General Ledger Accounting in mySAP ERP 2005. If you have previously not used any active installation and you are in the evaluation or project stage, you need to decide � depending in your concrete situation � whether you first want to use classic General Ledger Accounting or whether you want to implement New General Ledger Accounting straight away and thereby avoid the need for any subsequent migration to New General Ledger Accounting. Making changes or enhancements to the range of functions available in an active installation of New General Ledger Accounting (such as the subsequent implementation of document splitting) does not fall under the type of migration scenario described in this guide. Instead, such changes or enhancements need to be conducted in a separate consulting project. The migration tools described in the following chapters have not been elaborated for this purpose.





Page 5 of 53

1.3 What This Guide Has To Offer

This guide starts by portraying the different situations that can apply to a customer site prior to the implementation of New General Ledger Accounting. It describes typical scenarios and takes you through a possible set of migration steps for each scenario. There are also tools available for identifying and assessing in detail the topics relevant for the migration. These tools can be used to analyze a productive system without making any changes. This guide provides the following information:

• Which migrations are possible

o As standard migrations that are supported by SAP

o As project-based migrations that require additional steps

• Which migration are currently not supported

• How migrations should be broken down into steps

• Which tools are available for the individual steps


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

The following matrix shows the possible scenarios. This is an overview of the frequently occurring migration scenarios and not an exhaustive list of all scenarios imaginable.

Initial Scenario Target Scenario

Initial Situation in General Ledger Accounting

Use of Other Ledgers

Use of an Accounts Approach

Use of Ledgers in New General Ledger Accounting

Use of Document Splitting

Migration Scenario

Classic G/L No No Only leading ledger No Simple solution

Classic G/L Profit Center Accounting (PCA)

No Only leading ledger Yes/No Scenario with/without document splitting

Classic G/L Profit Center Accounting (PCA)

Yes Only leading ledger

(other ledgers optional by replacing accounts approach with ledger approach)

Yes/No Scenario with/without document splitting

Scenario with parallel accounting

Classic G/L Special purpose ledgers

No Only leading ledger

(others optional)

Yes/No Scenario with/without document splitting

Classic G/L Cost of Sales Accounting (COS)

No Only leading ledger

(others optional)

No Scenario without document splitting

Classic G/L Cost of Sales Accounting (COS)

Yes Only leading ledger

(others optional)

No Scenario with parallel accounting

Classic G/L No Yes Only leading ledger

(retention of accounts approach)

No Scenario with parallel accounting

Classic G/L No Yes Multiple ledgers (switch to ledger approach)

No (Yes if segment reporting, for example)

Scenario with parallel accounting

Where applicable, scenario with document splitting

This matrix is intended to be used initially to enable you to identify your situation in the migration scenarios described in chapter 4. It is already clear from the outline in the matrix that there can be various combinations of scenarios.

For this reason, chapter 2 first enables you to gain a basic understanding of migration. It details the most important steps. In practice, the simplest solution generally cannot be applied. Chapter 4 provides an overview of the most frequent scenarios. This chapter starts with the more simple scenario and leads you into the more complex scenario. The topic Parallel Accounting is handled separately. Moreover, there are certain peculiarities that do not necessarily arise but could arise in connection with the migration. Such





Page 7 of 53

peculiarities are handled in separate chapters, such as Migration with Introduction of Segment or Migration When Using Adjustments.

1.4 Migration is a project

The migration scenarios described in this guide are more than just technical changes to a live system because these changes necessitate in many cases conceptional changes as well. The migration scenarios should always be perceived as a project with project phases, milestones, and the necessity to perform tests and conduct training sessions. The time required for a project can only be estimated by careful planning under consideration of the aspects dealt with in this guide. The complexity of the changeover, the extent of the new features in system handling, and the data volume affected should not be underestimated. This applies in particular if the migration is being used to implement new accounting principles. It is quite common for central aspects for the whole of Accounting to be changed as a result of such an implementation.

1.5 What This Guide Does Not Offer

This guide should not be considered the documentation of the business functions in New General Ledger Accounting. Nor should this guide be considered a set of instructions that describes how to conduct the migration for all possible situations. Instead, this guide only provides instructions on performing migration for those situations that are currently supported by SAP in any shape or form. However, the absence of a scenario in this guide does not necessarily mean that migration is not possible for such a scenario. Such scenarios possess their own individual complexity, which prevents their inclusion in a standard description for general application.

Moreover, this guide only describes migration to New General Ledger Accounting. It is wholly possible that the introduction of new functions in New General Ledger Accounting is accompanied by changes in other SAP accounting modules or indeed causes changes to be made (such as the introduction of segment reporting, document splitting, introduction of Grants Management, introduction of funds in Funds Management, and splitting by funds). The migration in the other modules is not described in this guide.

• In particular, this guide does not cover the following points:

• Introduction of parallel accounting

• Introduction of segment reporting

• Changeover of the leading valuation

• Simultaneous changeover of the leading depreciation area in FI-AA

o This has to be organized using an SLO service.

• Change of chart of accounts

o This has to be organized using an SLO service.

1.6 Prerequisites

This guide is not intended to impart knowledge on the functions of New General Ledger Accounting; instead, it deals specifically about matters relating to the migration. Prerequisite for using this guide is therefore attendance of training course AC210 or equivalent knowledge.

A general prerequisite for the migration from classic General Ledger Accounting to New General Ledger Accounting is the successful upgrade of your SAP system to mySAP ERP 2005.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

1.7 Phase Model for the Migration

Fundamental to the migration is the following phase model, which is essential to understanding the migration process as a whole.

The phase model consists of the following three phases:

In the three phases, you essentially perform the following activities:

• Phase 0

o Conception of New General Ledger Accounting

o Customizing of New General Ledger Accounting already possible in this phase

o Planning and conception of migration

o Analysis of the production system, in particular when document splitting is applied

o Where applicable, Customizing of document splitting

• Phase 1

o Closing the old fiscal year

o Customizing of New General Ledger Accounting

o Customizing of migration

o Use of validation to check document splitting

o At the end of phase 1, you perform the actual migration itself

• Phase 2

o After successfully performing the migration, you activate New General Ledger Accounting

As you can see from the phase model, there are two dates of particular significance:

• Migration date (start of the fiscal year for which the migration is performed).

• Activation date (date on which New General Ledger Accounting is activated).

Migration Date Activation Date

Phase 0 Phase 1 Phase 2

New Fiscal Year

New General LedgerClassic General Ledger

Old Fiscal Year

Classic General Ledger





Page 9 of 53

2 Quick Migration for Basic Scenario This chapter describes quick migration on the basis of a simple scenario. If you do not require parallel accounting or document splitting, the migration of existing SAP data in Financial Accounting does not demand a great amount of effort. However, we recommend in any case that the migration is performed within the framework of a project because such a project ensures sufficient confrontation with the various aspects of migration. In any case, you should first familiarize yourself with the procedure in a test system so that the affected areas (user department and consultants) obtain an estimation for the events involved.

Note the following activities:

• Set up Customizing of New General Ledger Accounting.

• Set up Customizing for the migration.

• Perform closing operations and close the old fiscal year incl. balance carryforward.

• Start of the migration

• Create worklists.

• Transfer open items with posting date falling before the current fiscal year. Build general ledger line items and set the balance total of these open items in period 0 (balance carryforward) of the current fiscal year in the new totals table.

• Transfer balance carryforward of G/L accounts not managed on an open item basis.

• Transfer of all documents (all G/L accounts) of current fiscal year and set balances in new tables according to their respective periods.

• Where applicable, perform manual reposting (splitting) of balance carryforward to desired dimensions not contained in GLT0 (such as profit center).

• Activate New General Ledger Accounting

• End the migration.

All steps can be called in the standard Implementation Guide.

Note: In the following chapters, the standard tables FAGLFLEXT and FAGLFLEXA are used to represent the new general ledger tables. For example, Public Sector customers use the industry-specific standard set of tables (FMGLFLEXT, FMGLFLEXA).

2.1 Phase 0: Time Preceding Migration Date

Customizing (transaction SPRO)

Step 1: Set up Customizing of New General Ledger Accounting.

> Financial Accounting (New)

Before the Customizing settings can be made for the migration, the Customizing settings for New General Ledger Accounting need to be made. For information on setting up New General Ledger Accounting, see the documentation in the Implementation Guide.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

Step 2: Define Migration Plan


> General Ledger Accounting (New)

> Preparation for Productive Start

> Migration of Existing SAP Data

> Define and Assign Migration Plan

The migration plan acts as a kind of organizational parenthesis around the data to be migrated. In the migration plan, you make fundamental specifications such as the migration date, the migration type (with or without document splitting), the target ledgers concerned, and the participating company codes. Company codes that share identical fiscal year limits can be migrated together. In the case of very large volumes of data, multiple migration plans may be necessary to conduct the migration company code by company code.

The status of the migration (whether it has started or finished) is entered in the migration plan.

Step 3 (optional): Maintain Migration Cockpit





> Migration Cockpit

The Migration Cockpit can be used to perform the migration steps and to gain a better overview of the migration steps. The Migration Cockpit has the same functions as the SAP Closing Cockpit and is used in the same way. In the Migration Cockpit, SAP delivers templates for different scenarios that can be copied and adjusted. A task list is created from a template. The task list contains the steps that are performed for a migration. Generally, the migration can also be performed without using the migration cockpit.

2.2 Phase 1: Time After Migration Date

You perform closing postings for the old fiscal year. At the same time, you can enter postings for the new fiscal year. These postings are made in classic General Ledger Accounting using the usual logic.

Step 4: Close Posting Periods in Old Fiscal Year


> Financial Accounting Global Settings (New)

> Ledgers

> Fiscal Year and Posting Periods

> Posting Periods

> Open and Close Posting Periods

When the old fiscal year is closed, the worklists can be created for the migration.





Page 11 of 53

Step 5: Create Worklists





>Migration Tools

> Determination of Migration Objects

> Create Worklists

Here, you enter the migration plan defined previously. The system determines the open items with a posting date preceding the migration date and the documents with posting date that is the same as or greater than the migration date and places them in worklists.

When the worklist is created, the status indicator in the migration plan is set to Started. In particular, this means that the old fiscal year is locked by default for the function Reset Cleared Items. Furthermore, no more changes can be made in the migration plan.

Step 6: Create General Ledger Line Items and Balance Carryforward





>Migration Tools

> Open Items from Prior Fiscal Years

> Create General Ledger Line Items and Balance Carryforward

In this step, the system builds the general ledger line items (FAGLFLEXA) from the open post for customers, vendors, and G/L accounts with posting date in the prior fiscal year. From the total of the open items, the system carries forward for each G/L managed on an open item basis the balance in period 0 of the current fiscal year to the new totals table (FAGLFLEXT). Customer and vendor items are carried forward as totals to the respective reconciliation accounts. Nothing happens to the customer and vendor accounts themselves.

Step 7: Transfer Balance Carryforward





>Migration Tools

> Balance Carryforward

> Transfer Balance Carryforward


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

Once the balances for the accounts managed on an open item basis have been carried forward, balance carryforward can now be performed for the accounts not managed on an open item basis. This relates to the transfer of balance carryforward values from an appropriate source ledger (such as GLT0, or COS ledger GLFUNCT) to the totals table in New General Ledger Accounting.

Step 8: Transfer Documents to New General Ledger Accounting





> Migration Tools

> Document Transfer

> Transfer Documents to New General Ledger Accounting

From the content of the worklist, the system builds new totals tables (FAGLFLEXT) and line item tables (FAGLFLEXA) from the documents of the current fiscal year for all G/L accounts and specific to each period. In the simple case, you just enter the migration plan. The migration plan contains the company codes to be migrated.

Step 9: Manual Reposting to Other Dimensions (Transaction FBCB)





> Migration Tools

> Balance Carryforward

> Repost Balance Carryforward Manually

If required, you can use this transaction to repost values in the balance carryforward between different dimensions for specific G/L accounts. In the simple case, this is usually not required.

Step 10: Analyze Migration





> Migration Tools

> Evaluation of Migration

In this step, you check whether the migration is complete and correct. In addition, you create reports to document the posting data.





Page 13 of 53

Step 11: Activate New General Ledger Accounting

> Financial Accounting

> Financial Accounting Global Settings

> Activate New General Ledger Accounting

Step 12: Complete Migration





> Complete Migration

2.3 Phase 2: Time After Activation Date

In this phase, you can continue to update data to GLT0 during a transition period, even though New General Ledger Accounting has been activated.

If no more updates are desired, you can deactivate the update.

Step 13: Deactivate GLT0 Update





> Deactivate Update of Classic General Ledger (GLT0)


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

3 Migration in Detail

3.1 What Migration Entails

The migration seeks to enable you to perform the transition within the SAP system as smoothly as possible from the General Ledger Accounting environment you have been using until now to the diverse range of functions offered by New General Ledger Accounting. It may be that you only want to implement the same representation requirements used previously, such as parallel accounting using the accounts approach. Or you may want to adjust your accounting representation to new circumstances and therefore switch to new accounting methods, for example by implementing a financial statement at the segment level. In any case, it should remain possible to document the financial statement on the base of line items just as before. It is therefore a matter of wanting to document the changeover for external auditing purposes, for example.

You may opt for the changeover due to one or more changes in how General Ledger Accounting is used, such as the introduction of document splitting, the switch from an accountsapproach to a ledger approach, or the discontinued use of particular ledgers. It may be that:

• You already find the necessary content for the information to be documented, if only partially, in accounting documents but that you have never evaluated (or been able to evaluate) this information for General Ledger Accounting. Strictly speaking, you do not actually need any new documents because you only need to record the new way of using the document information. An example for this would be the introduction of document splitting by profit centers when you have previously already worked with Profit Center Accounting as a separate function and now want to reflect this in New General Ledger Accounting

• You can derive the necessary content for the information to be documented from other information contained in the accounting documents. The information that is actually required is therefore not available in posted documents but you can create rules governing how you can derive this information systematically from information contained in documents. You then have to add the derived information to the affected documents before you can perform any other migration steps. An example of this would be the introduction of a segment invoice whereby you can derive the segments from existing profit center information

• You have to create for a document the necessary information to be documented using an existing reference or one that is yet to be created (such as the invoice reference or the clearing document number) to another document. As is the case with the derivation of information, you have to create such reference relationships before you perform any other migration steps. To split a partial payment, for example, you may want to use the reference to the relevant invoice.

• You find the necessary content for the information to be document distributed across a number of documents that you as the user know to be connected but that the system cannot identify as being connected. An example of this would be the logic of an accounts approach with accounts that, depending on which are used and how they are combined, can be used to produce different financial statements.

The approach applied in all of these cases is that you first document the relevant documents systematically. You achieve this with the migration worklist containing all migrated documents as well as their migration status.

Migration is therefore more than just a technical necessity for the SAP system. It reflects much more the difference in content between old and new reporting and enables you to clearly represent this changeover in the same way as the other documentation requirements for an accounting system.

However, from the technical standpoint, you may also change a range of functions, especially with the introduction of document splitting. Documents posted before the changeover may meet the new requirements partially or not at all. Documents posted after the changeover must meet the new





Page 15 of 53

requirements. However, business processes and consequently the accounting documents that represent them regularly extend across both periods and in this way connect these periods. Nevertheless, you want to ensure that the posting procedure continues as smoothly as possible and that users do not need to ask themselves in the case of each document whether the document was posted before or after the changeover. You certainly do not want check rules to need to be changed regularly between old and new in order to continue processing.

You therefore have to convert technically the documents that belong to business processes and that are still active at the time of the changeover so that, after the changeover, such documents do not come up against new technical requirements and check rules that they do not fulfill. The following is particularly necessary for this:

• The unique classification of all business processes. Coupled with this is the concrete assignment of processes to document types as well as the classification of the chart of accounts

• Correct and timely referencing of documents within a process by clearing or invoice reference to enable derived or inherited information to be forwarded

3.2 The Steps of a Migration Project

A migration entails some mandatory steps and some that are optional. Furthermore, whether a step is applicable depends on the initial situation and the desired target scenario.

The step sequence can be divided roughly into two main parts:

1. Preparing Migration

Preparation of migration should be guided by two objectives: to do everything necessary to ensure that the scope of the migration is kept to a minimum and to provide answers to as many questions as possible regarding data origin and procedure and that could arise during the actual migration. The preparation steps are optional and only influence the effort required for the migration and its duration. Although you might in some cases change or supplement data during these steps, you do not perform the migration itself.

2. Performing the Migration Project

When you actually perform the migration, you work through a series of steps that follow a logical sequence. For this reason, some of the steps are mandatory in every case.

3.2.1 Analyzing the Initial Situation

To be able to produce a concrete plan and overview of a migration project, you first have to gain a clear overview of the initial situation serving as the starting point for the migration as well as of the goals that you want to achieve by performing the changeover to New General Ledger Accounting. For this, there are several important aspects that need to be taken into consideration:

• Initial scenarios that influence the migration procedure

Gain an overview of the accounting scenarios that are currently in operation in your system and of how they are used. It is particularly important to recognize cases in the initial situation when data relevant to accounting is imported from sources other than classic General Ledger Accounting.

o Use of Profit Center Accounting Section 0 describes the special features of a migration in such cases.

o Use of Cost of Sales Accounting (COS) After the migration, you can keep the data from the COS ledger in a ledger in New General Ledger Accounting. The ledger that you choose to use may also be the leading ledger. Document splitting is not necessary for this.

o Use of Special Purpose Ledgers Special purposes ledgers can be used in a variety of ways. Establish the following:


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

! Which specific ledgers are used

! Whether these ledgers are used in your production system or only exist in your consolidation environment

! Whether they are updated online or are built by rollups

! Whether document splitting is already used.

! Depending on the concept for how the special purpose ledgers are used, a different type of migration may be necessary or advisable. For this, check all the variants specified in chapter 0.

• Implementation of Other mySAP ERP Systems or mySAP Business Suite Modules

Generally, the implementation of other modules does not affect the migration to New General Ledger Accounting. On the contrary, it is more a case of ensuring that the migration to New General Ledger Accounting does not have any undesired effects on other modules. For example, you might intend in future to make relevant for financial reporting account assignments that are used or even defined in other modules, and you might want to change or supplement references to documents, as shown in chapter 3.

Check also to what extent the other modules used offer an option - similar to the migration and activation date in New General Ledger Accounting - of separating different posting scenarios using time restrictions. If the scenario Distribution of Liabilities is activated in the Customizing settings for Payroll, for example, the system considers the activation date for the migration and delivers the postings in accordance with the migration requirements.

! Use of Industry Solutions (IS)

The use of Industry Solutions generally does not have any effect on the migration to New General Ledger Accounting. The same considerations apply as those for the use of other mySAP modules.

! Use of Interfaces to External Systems

If you have used interfaces for online or offline connections to external systems that post to General Ledger Accounting, you may need to make adjustments to these interfaces in order to continue to use them with New General Ledger Accounting.

You need to consider the following for the migration:

o The process logic of the interface can contribute considerably to the volume of data to be migrated. This applies to all the items open on the migration date as well as to the document volume within phase 1. You could also use the interface in a way that reduces the quantity structure.

o If the external application or the interface uses time restrictions for posting scenarios, you can use it to synchronize the posting scenarios. This applies to the posting logic (which may in some circumstances be converted during the migration) as well as to possible error messages that the interface needs to possess because step-by-step validation forms part of the migration (for more detailed information, see 0).

! Managing G/L Accounts on an Open Item Basis

This aspect only comes into play if you want to accompany the migration with the introduction of document splitting. The effort required for the migration is to a great extent relative to the number of documents to be processed in the migration. This number includes all open items (OIs) present on the migration date as well all documents posted in phase 1 (see section 1.6). The term open is used here to denote the absence of a clearing document number.

While you have to manage subledger accounts (that is, customer and vendors) on an OI basis in every case in order to be able to build business processes such as payment, you need to check early on whether it is necessary for G/L accounts to be managed on an OI basis. By reducing the amount of such accounts, you can reduce the amount of open documents, thereby reducing the amount of





Page 17 of 53

documents to be migrated that need to be processed for document splitting. Besides reducing the effort involved, you should also check whether or not clearing actually needs to be performed, since information is passed from one document to the follow-on documents during document splitting. It is possible that the existing link does not meet the requirements as a result of clearing, that is to say, the documents should not be split on the basis of this clearing.

You can use a Service Session as part of SAP Safeguarding for Upgrade to receive information about the number of G/L accounts managed on an OI basis and the number of OIs on these accounts. For more detailed information, see the SAP Service Marketplace.

Having a very small amount of open and cleared items can indicate that management on an OI basis does not offer any decisive advantage and that it can be dispensed with. Having a clearing that combines all documents for a period can also imply that there is no direct connection between the individual documents. This does not apply to bank clearing accounts.

Generally, we recommend that you should keep the number of G/L accounts that are managed on an OI basis to a minimum. If during this analysis you find G/L accounts for which you want to deactivate management on an OI basis, there are a number of aspects that dictate whether this is possible. To find out information about the recommended procedure, consult the current SAP Notes relating to the topic FI-GL-GL and containing the keyword open items. You should perform this activity before starting the migration.

! Number of Documents in the Migration Period

This aspect is relevant for all functions in New General Ledger Accounting. You need to include in the migration all documents in phase 1 (see section 1.6), that is, all documents posted between the migration date and the activation date as well as all items from phase 0 that are open on the migration date.

If you want to introduce document splitting, whether or not the OIs are supplied with the relevant account assignment information (see section 0) has a decisive impact on the effort required. It is therefore advisable that you establish in as much detail as possible how many documents are involved and what form of processing is applied for the migration in order to estimate the time required to perform the migration.

! Open Items Posted Before Release R/3 4.5

This aspect is only relevant if you want to introduce document splitting. Problems arise in document splitting if there are documents that were still open on the migration date and that were posted before Release 4.5. The reason for this is that specific additional information that is required for document splitting was only stored in the system from Release 4.5. This information is therefore missing in documents originating in earlier releases. In this case, you need to retrospectively enter the missing information manually. For the exact procedure to use, please contact SAP.

! Number of Company Codes and Clearings Between Them

Generally, each company code can be migrated separately from the other company codes, provided there are no cross-company-code documents. However, in the case of company codes sharing the same fiscal year variant, we recommend migrating all of such company codes together. If there are cross-company-code documents that are relevant for the migration, and document splitting is to be introduced, these documents should be migrated together. The Service Session mentioned under Managing G/L Accounts on an Open Item Basis provides an overview of the relevant documents. If there are also cross-company-code documents relating to company codes with different fiscal year variants, such documents must be processed in separate migration plans.

! Using Different Fiscal Year Variants

If you use different fiscal year variants in different company codes, note that a minimum requirement is that it must be possible to derive the same fiscal year from the migration date for all company codes within a migration plan. You may be required to create multiple migration plans to meet this requirement.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

! Use of Additional Currencies in Special Purpose Ledgers

If you currently use special purpose ledgers that you will replace by migrating to New General Ledger Accounting and that you no longer want to use in FI-SL, you have to check the currencies used in these ledgers. If a currency is used that is not contained in the original posting document, you cannot migrate this data to New General Ledger accounting because the New General Ledger data only builds on the data in the accounting document. In this case, you have to keep the respective ledger.

! Parallel Valuation

There are special migration scenarios for the ledger approach as well as for the accounts approach using parallel valuation. For more detailed information, see 0.

3.2.2 Analysis of Desired Target Scenario

Chapter 0 demonstrated that many aspects depend on the initial scenarios that you start from. Some of these scenarios can be considered from the perspective of the target scenario, but they only get a short mention here:

! Portraying Parallel Valuation Using the Ledger Approach

New General Ledger Accounting favors the ledger approach for parallel valuations due to the functions it possesses. The transition from the accounts approach is described under 0. However, you can continue to use the accounts approach (see 0).

! Using Multiple Ledgers

For information about the special features relating to a migration in multiple ledgers, see section 4.2.5.

Furthermore, there are also aspects that only depend on the target scenario. This includes in particular:

! Introduction of Document Splitting

For document splitting to be introduced into a scenario thus far without document splitting, documents need to be posted using a clearer and more definite posting logic. For detailed information about the migration steps for this, see section 0.

3.2.3 Customizing Required

The Customizing settings that need to be made for a migration can be grouped by content into two main areas, and each area has a specific sequence in which the settings are made:

1. First, the Customizing settings relevant for the target scenario (that is, the Customizing settings for New General Ledger Accounting) need to be made. This involves achieving the overall concept of the new portrayal of accounting with ledgers and where appropriate document splitting and testing the functions, testing for completeness, and testing the interaction of all internal and external document sources used. You should first perform such tests without considering the existing posting data. These steps are identical with the new implementation of New General Ledger Accounting and are described in the Implementation Guide.

2. Once the target scenario has been clearly defined, you now have to specify the path of the existing documents that need to be migrated.

The framework for this is the migration plan, which combines all relevant activities. You find the migration plan in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data. You can monitor the current status of the migration under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Evaluation of Migration.

To avoid having to change for the migration the Customizing settings for document splitting in the target scenario, you find the option of alternative Customizing settings for the migration at specific





Page 19 of 53

locations in the node Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data.

3.2.4 Validation of Document Splitting

Validation is an important step for the migration if document splitting is introduced. Since the posting logic may in some cases change considerably, it can assist users in learning the new logic to perform the introduction in production operation. Using validation means that your users do not have to suddenly have full command of the new rules from one day to the next, but can learn them gradually. It offers the following options:

! Initially, to only log the posting activities

At the start of the validation, it may be the case that not all of the rules for document splitting have been set up in the system. Anything missing is entered in the log. While the user performing the postings remains unaware, the project team can analyze the documents posted and change over the Customizing settings correspondingly, or define tasks for a training session in cases where a document was posted in a way that it should not have been.

! Then additionally to issue a warning message

The user is now made aware each time a document he or she has posted contravenes the rules on document splitting. It is useful to apply this setting once the users have attended a training session and know how postings need to be performed.

! Finally, to issue an error message

Using this setting produces the situation that would occur after the migration: a document cannot be posted when an error is made (be it a user error or a Customizing error).

3.2.5 Performing the Migration

The migration itself is performed in the following steps. You find all points on this in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools.

! Determination of Migration Objects

In this step, a worklist is generated (either by means of a selection program or by supplementary manual definition), containing all documents to be migrated as part of a migration plan. This worklist forms the basis for all other activities, that is, other programs use this worklist to select the documents to be migrated.

! Preparations for Documents from Phase 0

As discussed above, any open items in phase 0 need to be migrated. Such items may require additional document splitting information, which is created in this step. The documents themselves are not transferred into New General Ledger Accounting because they were posted before the migration date.

! Preparations for Documents from Phase 1

Documents from phase 1 must be transferred completely into New General Ledger Accounting. Where applicable, any document splitting information from documents in phase 0 need to be used for this. During the transfer, all checks are run on these documents as if they were being posted to New General Ledger Accounting for the first time. The validation serves as preparation for these checks. It allows you to identify problem cases earlier on and to prepare the treatment for these cases in your own time. With the transfer, the balances are automatically written to New General Ledger Accounting.

! Balance Carryforward


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

In the case of G/L accounts that are not managed on an OI basis, balances are transferred in totals, not by document. If adjustments need to be made due to changes in the financial statement structure, these changes can be posted manually.

Once all migration steps have been performed productively, you finish the migration for this migration plan under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " End Migration. If you no longer require any comparison data for new posting periods, you can deactivate the update of balances from classic General Ledger Accounting.

3.3 Overview of Changes

What does the migration achieve from the perspective of the document data and balances?

! The migration does not change any of outset data in classic General Ledger Accounting in tables BKPF and BSEG, the secondary indexes, or in totals table GLT0. The migration also does not change any outset data in other ledger such as in Profit Center Accounting, the cost of sales ledger, the reconciliation ledger, or a special purpose ledger. The migration also does not change any outset data in other applications. Usually, a migration does not require activities to be performed in any other areas outside General Ledger Accounting. Moreover, the complete reporting functions are available for existing data.

! An exception to the above statement arises if original posting documents are supplemented for migration purposes or as a result of adjustments made not only in New General Ledger Accounting but in other applications as well. In this case, you need to ensure that, in the migration project, all affected applications are identified and where necessary migrated as well. This does not happen as part of the migration to New General Ledger Accounting! You also need to ensure that your reporting requirements are still fulfilled for legacy data.

! With the transfer to New General Ledger Accounting, the tables specific to New General Ledger Accounting (line items, document splitting information, GL totals) are updated for the first time.

! Standard functions in General Ledger Accounting such as document display, account balances, or financial statement recognize which periods were updated with which scenario. Consequently, you do not necessarily have to adjust these functions. However, as early as the test phase for the use of New General Ledger, you should ensure that all necessary reports and transactions are available for the new accounting method.





Page 21 of 53

4 Migration Scenarios

4.1 Overview of a Migration Process

Migration projects can differ greatly from one another due to the many possible initial situations and target scenarios and may also have greatly varying time requirements. For these reasons, the migration process described here can only take a standardized form, containing the central tasks.

The periods displayed are only to be considered examples that illustrate the exemplary sequence. Such periods are not target specifications, nor are they based on past experience:

Start of the Migration Project Like any other project, the migration project needs to have a concrete start. During the start process, aspects such as project organization, schedules, and procedures are determined. The start can occur before the upgrade to ERP2005.

Analysis of Initial Scenarios

The initial situation can be analyzed before the upgrade to ERP2005. Some of the aspects discussed in chapter �, such as interfaces to external systems or the consideration of the effects on the migration on other SAP modules, require a long lead time in case adjustments need to be made in the external systems or other SAP modules.

Upgrade to ERP2005

The upgrade to ERP2005 is the prerequisite for the use of the actual migration support provided by the system. The upgrade itself � with all its subtopics and test requirements � is a project in its own right. As part of the migration project, it should be made clear here that the overall time requirement for the migration can include and influence the upgrade. The points that can be dealt with before the upgrade can, of course, also be started once the upgrade has been performed successfully if you want to separate the two projects from each other.

Customizing Settings in New General Ledger Accounting

First, you should completely set up in New General Ledger Accounting the environment that you want to use in the future. This also forms the basis for subsequent validations.

Create Migration Plan

This is the system view of the actual start of the migration, which provides the framework for the following activities.

Customizing Settings for Migration


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

In contrast to the standard settings for New General Ledger Accounting, special migration Customizing settings can be made here for document splitting. Subsequently, this also influences the test migration and the subsequent update migration.

Test Migration

The test migration is performed in iterative steps. The data to be migrated is determined and selected, and then a migration trial run is started using the Customizing settings for New General Ledger Accounting, and the trial run is logged. Ideally, the migration trial run is performed in a test system and not in the production system. Analyzing the log tells you which data could not be migrated and why. The Customizing settings then need to be adjusted, exception rules created, or other measures taken. Once this has occurred, the test migration undergoes another trial run. This process is repeated as often as necessary until: No existing data causes problems or cannot be migrated As a result of using validation in the project, you are sufficiently certain that any new documents posted will not cause any problems. You then transport all the test settings to the production system.

Validation

You use validation to ensure in the production system that the current posting activities are also adapted step by step to your new posting logic. Performing validation is only useful if a new posting logic is introduced. However, at this point, it should already be clear from the migration project whether this is the case.

Actual Migration

In contrast to the test migration, you do not perform the actual migration iteratively. Instead, you perform it just once, and you do so in the production system. Beforehand, you copy from the test system to the production system all relevant specifications for the migration that you have obtained by performing the test migrations, and complete all other preparatory tasks.

End of the Migration Project

Once the actual migration has been performed successfully, the migration to New General Ledger Accounting is complete. You may be required to perform migration activities in other modules, be it before, after, or alongside the migration process.





Page 23 of 53

4.2 Overview of Scenarios

The migration process applied and its complexity depend considerably on which business model needs to be transferred from the existing General Ledger Accounting solution and on which target scenario is to be applied in New General Ledger Accounting. This is one of the reasons why the migration to New General Ledger Accounting should be performed in the form of a project. Based on the existing implementation, it is necessary to clarify in particular how the corresponding data is to be built in the new environment using the existing document and totals record information (transaction figures). This must be taken into consideration due to the large number of different forms of portrayal and application of the existing General Ledger Accounting. The following scenarios are intended as an aid and provide an overview of the possible procedures. These scenarios are particularly relevant if the Quick Migration for Basic Scenario solution described above is not sufficient.

4.2.1 General Starting Point of All Scenarios

It is generally assumed that the timing of the migration coincides with the end of the fiscal year, that is to say, the migration date marks the start of the new fiscal year and consequently of the migration. With the migration, the new tables for additional ledger-dependent documents (BSEG_ADD) and line items (FAGLFLEXA) � or, if document splitting is used, the document splitting information (FAGL_SPLINFO) as well as for the new totals table (FAGLFLEXT) � are filled using the existing totals tables and documents. The original documents (BKPF, BSEG) remain unchanged.

It is assumed for all migration scenarios that there is always a phase 1. However, the duration of this phase can vary depending on the closing process for the previous year. Nevertheless, as stated above, we recommend performing the migration soon after closing for the previous year to keep the volume of documents to be migrated in the current fiscal year to a minimum. Postings in phase 1 are only made in classic General Ledger Accounting (GLT0). In Phase 2, once New General Ledger Accounting has been activated, postings are then made in New General Ledger Accounting and, if desired, the same postings can still be made to GLT0 temporarily during the transition. For this, some consideration is necessary in order to decide how long the postings need to be made in parallel (such as to compare the values for monitoring purposes). It may be that you have developed your own reports for analyzing data from GLT0.

In all migration scenarios, it is assumed that the previous year is closed. Once the migration activities have started, no back postings can be made to the previous year and the clearing of documents in the previous year cannot be reversed (clearing document number <= last day of the previous year). The reason for this is that the migration needs to be made from a static, unchangeable dataset of open items and balances at the start of the current fiscal year. As for the reversal of clearing, it is not possible in the standard delivery to reverse clearing once the migration plan has received the Started status and the first selection program for worklist creation has run. If necessary, you have the option of customizing the related error message in the message control settings. In this case, refer to the section Subsequent or Retrospective Postings.

The migration is also based on the assumption that balance carryforward to the current fiscal year has been completely and correctly because this is the basis for balance carryforward to the new tables.

The following prerequisites apply:

! The source ledger (such as GLT0) contains all of the currencies used in the target ledger (such as FAGLFLEXT)

! The source ledger and target ledger have the same definitions for the start and end of the fiscal year

! There has been no local currency changeover in the follow-up posting period (phase 1).


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

4.2.2 Migration to an Environment Without Document Splitting

4.2.2.1 Description of Migration Steps

In its simplest form, a migration to an environment without document splitting corresponds to the Quick Migration for Basic Scenario solution described in chapter 2. Depending on which components and solutions you use, you need to consider certain integrative aspects. In the case of a scenario without document splitting, migration is based on the assumption that specific document information or additional account assignments such as business area, profit center, or cost center, may exist but these characteristics may not have relate to the financial statement. For example, when a profit and loss statement is created by business area or profit center and these additional account assignments are incomplete from the financial statement view or are used without a zero balance posting (such as receivables and payables not by business area or profit center). In this case, this information is transferred into New General Ledger Accounting in a migration, but no information is enriched or derived for subsequent document splitting.

The following activities are required for the migration to New General Ledger Accounting:

! Make migration Customizing settings, which entails:

o Creating the migration plan and assigning the company codes. For the migration type, choose the option WITHOUT Document Splitting.

! Create worklists for:

o Items still open on the key date that document the balance on the last day of the previous period

o Documents that are posted on or after the migration date and thereby fall in the current fiscal year.

! Transfer open items from previously created worklist. In this activity, the general ledger line items are built in the new tables and balance carryforward (period 0 of the current fiscal year) is performed. In this step, all G/L accounts managed on an OI basis as well as the reconciliation accounts for customers and vendors.

! Transfer documents for current fiscal year from worklist. This activity relates to a function with which the debit/credit totals of the G/L accounts are transferred by period and the entries are generated in the new line item table. This affects all documents in tables BKPF and BSEG that were posted with a posting date >= migration date.

! Create balance carryforward for all G/L accounts not managed on an OI basis, from the balance carryforward of these accounts in an appropriate source ledger. This consequently only concerns balance sheet accounts because all P&L accounts were carried forward to the retained earnings account at the end of the previous fiscal year.

! Evaluate migration status to establish whether all data has been migrated successfully.

! End migration, that is, set the status to Completed.

4.2.2.2 Building Data in New General Ledger Accounting Without Document Splitting

The starting point for this is the implementation of New General Ledger Accounting without document splitting. The section deals with questions relating to building data in such a migration scenario. First, the worklists are generated for the following steps.

Important: Once the worklist for open items has been created, no postings made be made with a posting date preceding the migration date and there may be no clearing with a clearing date preceding the migration date. On the other hand, any clearing with a clearing date falling on or after the migration date is uncritical.





Page 25 of 53

4.2.2.2.1 Transfer Open Items

Migration without document splitting is characterized by the fact that open items are also considered because they are required in order to build the opening balance correctly, that is, the totals of the account assignments are determined for each G/L account and written to the totals table by means of the balance carryforward. With each open item to be migrated successfully, the corresponding balance is cumulated in period 0 of the current fiscal year (balance carryforward). Since only the balance carryforward of the current fiscal year is built, it is irrelevant whether the open items originate from the fiscal year directly preceding the migration date or from earlier fiscal years. This procedure guarantees that, once the migration is completed, the balance of open items corresponds to the balance in the totals record, which, by definition, must always be the case for an account managed on an OI basis. With the transfer of open items, all open items with a posting date preceding the migration date are read from tables BSIS, BSIK, and BSID as well as all cleared items (in tables BSAS, BSAK, and BSAD) with a posting date preceding the migration date and a clearing date >= migration date. The open items are transferred to the standard table FAGLFLEXA.

4.2.2.2.2 Transfer Balance Carryforward

In contrast to the open items, all G/L accounts that are not managed on an OI basis (SKB1-XOPVW = blank), that do not represent reconciliation accounts for customers and vendors (SKB1-MITKZ <> �D� and SKB1-MITKZ <> = �K�), and that were chosen when the report is started, are selected by the balance carryforward program.

Your current SAP environment has the following:

! Balances in GLT0 (ledger 00), in some cases using business areas

! If you use profit centers (EC-PCA), the totals table GLPCT (ledger 8A) with corresponding totals at the profit center level

! If you deploy Cost of Sales Accounting, the totals table GLFUNCT (ledger 0F)

! If you use consolidation preparation, totals table GLT3

! One or more special purpose ledgers, possibly using customer fields.

Depending on the form of New General Ledger Accounting that you use, you have the new totals table FAGLFLEXT with either a leading ledger and where necessary other ledgers or a customer-specific totals table, because New General Ledger Accounting provides the option of having customer-specific totals tables alongside the standard totals table FAGLFLEXT. Migration is then performed in the same way as for the standard table. How the customer-specific totals table is designed and used extends beyond the scope of this guide. We recommend examining very carefully whether a customer-specific totals table is useful or necessary (see also SAP Note 820495).

As a general rule, therefore, the totals table in New General Ledger Accounting has to be built correctly in the form of the balance carryforward. In the simplest scenario, this occurs by migrating the values completely (in the case of G/L accounts not managed on an OI basis) from the current totals table (such as GLT0). With regard to the account assignments possible in New General Ledger Accounting, a distinction needs to be made between the following cases:

! The new account assignments already exist directly in the source ledger or the totals table (such as GLT0, GLFUNCT, GLPCT, or GLT3).

! The new account assignments do not exist directly in the source ledger or the totals table but can be derived directly from the totals records (such as Segment from the profit center).

! The new account assignments are not contained directly, nor can they be derived from the totals records. In this case, there are two options:

o Use of the designated BADI (FAGL_UPLOAD_CF) to supplement the account assignment information, whereby the question remains as to which rules can be used to find the account assignment.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

o Manually reposting the totals using the transaction designated for this purpose in New General Ledger Accounting, FBCB (Post Balance Carryforward for Ledger Group). This new transaction makes it possible to correct the values in the balance carryforward period specifically for reposting to balance sheet accounts (that are not managed on an OI basis). If you use transaction FBCB, see the section Special Features with Transaction FBCB (Post Balance Carryforward for Ledger Group).

If a totals table other than GLT0 is used as a source ledger, it is essential that this totals table from which the data is transferred be reconciled previously with GLT0 at the G/L account / company code level. For example, the migration could transfer data from GLFUNCT if you post all general ledger transactions in GLFUNCT so that complete financial statements can be created using GLFUNCT.

If data is to be transferred from different source ledgers, it would be feasible that totals values are not transferred completely from just one source ledger, but instead in the form of account intervals or from different ledgers for selected accounts. For this reason, the balance carryforward program allows G/L accounts to be selected as an additional restriction. If the program needs to be run multiple times for identical accounts (or account intervals), the values are totaled (the system first issues a warning message). In each case, it is necessary to ensure that the financial statement is transferred correctly by correctly applying the program, that is, the financial statement has a zero balance and agrees with the financial statement in classic General Ledger Accounting. The ledger comparison can also be used to support this.

4.2.2.2.3 Document Transfer of Current Fiscal Year

Besides the transfer of open items and of balance carryforward, the documents within the current fiscal year that were posted prior to the activation of New General Ledger Accounting need to be migrated. For this, the line item tables and the totals tables of the current fiscal year are built. The following requirements must be met:

! Customizing settings for New General Ledger Accounting are complete

! Customizing settings for the migration are correct

! Worklist for documents to be transferred is created

In the case of migration without document splitting, it is assumed that no new balancing unit is introduced in New General Ledger Accounting so that your current environment does not change in this respect. However, financial statement items or balance sheet accounts can exist in specific additional account assignments, such as business area, and it is correct for these to be transferred to New General Ledger Accounting.

With the implementation of New General Ledger Accounting, you may want to use the new entity Segment for additional reporting purposes. If you need the segment in the future for segment reporting as per IFRS/IAS or US GAAP, it is feasible that you use the segment to migrate the information or data that you can already assign to a segment (see the section Migration When Using Segment in New General Ledger Accounting). For this, you need to ensure that an opening balance sheet with a zero balance is first created on the balancing entity Segment. For more information, see the section Migration to an Environment with Document Splitting below.

4.2.2.3 Considering Integration Aspects

The changeover to New General Ledger Accounting raises the question whether the migration to New General Ledger Accounting also has effects on integrated system components such as FI-AA or Treasury. In many cases, customers are likely to have Asset Accounting integrated with General Ledger Accounting.

4.2.2.3.1 Integration with Asset Accounting (FI-AA)

As a general prerequisite, the previous year must also be completed from the perspective of Asset Accounting before the migration can start. Consequently, year-end closing needs to have been performed





Page 27 of 53

in Asset Accounting for all depreciation areas. As described above, it is not possible to reverse year-end closing or to perform backpostings to the previous year because this would change the balance carryforward values.

If you start with a scenario in which you do not use parallel accounting in the form of an accounts approach in classic General Ledger Accounting and, at least initially, you do not want to use parallel accounting after the migration to New General Ledger Accounting, there are no special considerations. In this case, you use depreciation area 01 in Asset Accounting integrated with the leading ledger, such as 0L, in New General Ledger Accounting. Optionally, there can be other depreciation areas that serve management accounting purposes or are used for financial statements for tax purposes and that you do not post in other ledgers of New General Ledger Accounting.

The asset documents that post data from valuation area 01 to General Ledger Accounting remain connected to FI after the migration. In other words, you can access the corresponding FI document from the asset document because BKPF and BSEG are not changed by the migration.

If you use another parallel depreciation area in Asset Accounting that you have assigned to another ledger, the depreciation in phase 1 is posted to New General Ledger Accounting. The prerequisite for this is that you have already set up the ledgers in New General Ledger and have assigned them to depreciation areas in FI-AA. This applies in particular to parallel accounting, which is the object of the scenario Migration with Parallel Accounting.

4.2.2.3.2 Integration of Treasury and Risk Management

When Treasury and Risk Management (formerly belonging to component CFM) is used, the effects from the point of view of migration depend mostly on whether you have implemented parallel accounting in your current environment. This is comparable with Asset Accounting. If you do not use parallel accounting and also only use the leading ledger in New General Ledger Accounting, no effects need to be considered. In this case, only depreciation area 001 is integrated with the leading ledger, such as 0L, in New General Ledger Accounting. If you use more than one ledger in New General Ledger Accounting (not for parallel accounting, but for different reporting perspectives, for example), you need to decide which valuation areas post to which ledgers in New General Ledger Accounting. You dictate this with the accounting principle. If you have not previously defined an accounting principle, this is necessary in the new environment if you want to post selectively to individual ledgers in New General Ledger Accounting.

4.2.3 Migration to an Environment with Document Splitting

4.2.3.1 Description of Migration Steps

Migration to an environment with document splitting is somewhat more complex than the scenario with document splitting discussed previously. The reason for this is that line items must be enriched with account assignment information in order to guarantee that the processing and results of subsequent processes are correct. You can use document splitting to divide the line items according to selected dimensions (such as Segment). During document splitting, information (account assignments) is projected in line items that do not initially contain this information. In addition, a zero balance setting can occur so that it is possible to create at any time a complete financial statement for these dimensions. For document splitting to work correctly, you need to have made the Customizing settings for document splitting. This applies to the posting of documents in New General Ledger Accounting as well as for the migration.

If you want to manage in the new General Ledger alternative balancing units (for example, segment, profit center, or fund), the opening balance sheet must in addition amount to zero for each value of these entities. (If more than one balancing entity is included in the financial statement, combinations of their values must also be taken into account).

The following activities are required for the migration to New General Ledger Accounting:

! Make migration Customizing settings, which entails:


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

o Creating the migration plan and assigning the company codes. For the migration type, choose the option WITH Document Splitting. Note in this connection that document splitting is used in all company codes that are assigned to the migration plan. If you do not want to use document splitting for specific individual company codes, you have to migrate these company codes in a separate migration plan. Note: In this scenario, it is not possible to have cross-company-code documents between company codes with and without document splitting.

o Defining the validation date for testing document splitting. By validating document splitting, you can simulate business processes modeled in New General Ledger Accounting under live system conditions (in the production system). For more information, see the section Validation of Document Splitting below). The prerequisites for this are as follows: New General Ledger Accounting has been set up, document splitting in particular has been completely defined and is active, and the leading ledger has also been set up. During validation, no data is updated to the general ledger tables or to the tables for document splitting. In this way, you can check whether the posting rules defined are adhered to and avoid the accumulation of documents containing errors that need to be posted subsequently.

o The Customizing settings for document splitting should show how the business transactions are generally modeled from the activation event. For the migration, it may be necessary to make special Customizing settings for document splitting that only have the purpose of preparing legacy documents to be subsequently posted. To make alternative Customizing settings, choose in the IMG structure Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Document Transfer from Current Fiscal Year " Alternative Customizing for Document Splitting during Document Transfer. The following intervention options are available for the migration:

! Alternative document splitting method for migration

! Alternative assignment of business transactions

! Alternative assignment of item category

! Alternative clearing relationship (currently delivered in the background)

! Intervention options using a BAdI

! Create worklists for:

o Items still open on the key date that document the balance on the last day of the previous period

o Documents that are posted on or after the migration date and thereby fall in the current fiscal year.

! If you want to use the new entity Segment in New General Ledger, see the information in the section Migration When Using Segment in New General Ledger Accounting below.

! A special feature of this migration scenario is that the open items need to be supplemented with account assignment information for document splitting in subsequent processes as described above.

! Transfer open items from previously created worklist. In this activity, the general ledger line items are built in the new tables and balance carryforward (period 0 of the current fiscal year) is performed. In this step, all G/L accounts managed on an OI basis as well as the reconciliation accounts for customers and vendors.

! Build document splitting information on the basis of the general Customizing settings as well as on the basis of migration-specific Customizing settings (optional).





Page 29 of 53

! Subsequently post documents for current fiscal year from worklist. This relates to a function for performing subsequent postings with which debit/credit totals of G/L accounts are posted by period. This affects all documents in tables BKPF and BSEG that were posted with a posting date >= migration date.

! Create balance carryforward for all G/L accounts not managed on an OI basis, from the balance carryforward of these accounts in an appropriate source ledger. This consequently only concerns balance sheet accounts because all P&L accounts were carried forward to the retained earnings account at the end of the previous fiscal year.

! Evaluate the migration status to establish whether the migration was successful.

! End migration, that is, set the status to Completed.

4.2.3.2 Checking and Building Data in New General Ledger Accounting with Document Splitting

Setting out from migration without document splitting, this section looks at the special features of migration with document splitting.

With document splitting, a distinction is made between using a base account assignment to project account assignment information into line items, and using a zero balance setting for the corresponding account assignment characteristic in addition to the projection of account assignment information. You select one of these options when making the Customizing settings for document splitting in New General Ledger Accounting. When the zero balance setting is made, the system creates additional clearing lines so that the document splitting characteristic has a zero balance within a given document. This also needs to be considered for the migration. The aim here is to migrate the document and totals record data from the existing posting data in classic General Ledger Accounting for the characteristics (such as profit center or segment) that, alongside the company code, are to be used to created the financial statement in New General Ledger Accounting, and to perform the migration in such a way so as to create a correct opening balance sheet for the current fiscal year as well as a correct financial statement at the time of the migration. For this, it must be possible to reconcile the document information with totals records, and the document splitting information must be correct for the subsequent processes (such as payment, clearing, or invoice-related credit memo). This clearly demonstrates how much more complex the migration to such a scenario is, compared to the scenarios discussed above. We would like to emphasize at this point the importance SAP attaches to performing the migration as part of a migration project. Inclusion in a migration project means that such issues are granted sufficient consideration and that the foundation is laid for creating a verifiably correct migration path.

4.2.3.2.1 Validation of Document Splitting

If you want to introduce document splitting with the migration to New General Ledger Accounting, it is advisable in every case to activate the validation of document splitting because this enables you to identify and minimize any possible errors ahead of performing the migration. Another advantage of using validation is that postings are tested under the same conditions as in the production system.

You can decide on the form validation should take:

! No validation

! Log only

! Warning message and log

! Error message

You can either make the setting directly in the migration plan or in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Validation of Document Splitting in Production System " Define Validation.

To conduct the validation optimally, the following prerequisites need to be fulfilled:

! The migration plans and the leading ledger must be defined.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

! The document splitting method must be determined.

! The accounts used should be classified as much as possible.

! The document types used should be assigned to business transaction variants.

! The assignment of item categories to the business transaction variants should be checked and where necessary adjusted.

! The document splitting characteristics must be determined. It must be possible either to derive the account assignment characteristics used (from CO objects, segment from profit center, or via substitution), or to enter data directly in these characteristics during document entry.

! Document splitting must be active for the company codes to be validated.

Documents can be posted using external interfaces (such as ALE and Direct-Input). These interfaces must provide sufficient account assignment information so that it is possible to represent the general ledger document in a way reflecting the processes. If this is not the case at the time of the validation, these lines must be assigned subsequently. If the dimensions Profit Center or Segment are involved, refer to the section Migration When Using Segment in New General Ledger Accounting.

Where necessary, different levels of validation can also be set up for individual transactions down to the transaction level. You do this in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Validation of Document Splitting in Production System " Adjust Validation for Specific Processes. This becomes necessary when you cannot validate specific processes sufficiently yet or modeling has not yet been performed completely. If this is still not sufficient, you also have the option of using a BAdI to specify the level of validation in each case. For this, you can set the following fixed values in the modifiable parameters CD_VAL_MOD:

! Blank No validation

! 1 Log only

! 2 Warning messages and log

! 3 Error message

Document splitting is generally requires certain document splitting characteristics to be mandatory in line items. If account assignment information is not available or, depending on the project status, not yet available, you can use a BAdI to simulate the necessary base account assignments for document splitting and to activate the validation thereafter. You find the settings for the above-mentioned BAdIs in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Validation of Document Splitting in Production System " Implement Enhancement for Validation (BAdIs).

Let us suppose, for example, that you are currently using business areas in classic General Ledger Accounting. In the future, you want to introduce a complete financial statement using profit centers in New General Ledger Accounting. Assuming that the profit center structure is not yet complete, you can still derive a profit center from the business areas currently available. It is important that this only occurs as a simulation, which means that, after the simulation, the documents still have to be supplemented subsequently with the account assignments during the migration.

4.2.3.2.2 Processing Open Items

After you have generated the worklist for the open items, the document splitting information must be built for these open items so that the required information is available for follow-up clearing after the migration date. A program for this is delivered in the migration tools. You find this program in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Open Items from Prior Fiscal Years " Process Document Splitting Information for Open Items. This program ensures that all open items to be processed receive a correct account assignment, which is the basis for building the document splitting tables. You have to implement





Page 31 of 53

the logic for supplementing the account assignments in the form of a BAdI. This makes it possible for individual derivation rules to be considered in a standard migration process as well. Note that, from the perspective of the total document, an account assignment must be found for each individual open item.

Note the following on how BAdI FAGL_MIGR_SUBST works:

! The following information is transferred to the BAdI and enables you to implement the derivation.

o Complete document within which the open item is located (IT_BSEG)

o Open item that is currently being processed (IS_ACCIT)

o Document header (IS_ACCHD)

! Account assignments in structure CS_MIG_ASGMT can be changed.

! With the exception of the profit center, only initial fields can take an account assignment. Fields that are already filled cannot be changed, only a dummy profit center can be overwritten or deleted by another profit center. Note that a set profit center may be overwritten by the profit center in a CO account assignment if this assignment is set additionally.

! In structure CS_MIG_ASGMT, you can also set additional account assignments for CO that are applied later to post follow-up costs (such as cash discount, exchange rate differences, or penalty interests) once New General Ledger Accounting has been activated.

! The fields must be filled with the correct values, which means that the corresponding account assignments must exist.

! If a document contains more than one open item, each open item is processed individually.

The original items (BSEG, BSIS, BSID, and BSIK) are not changed, only the entries in the tables for document splitting are generated. The general ledger line items are transferred in a separate step. Before the general ledger line items are built, all open items must have the status Without Errors. Otherwise, the migration cannot be performed completely and correctly. In cases where no correct account assignment can be derived, it may be necessary to set a dummy account assignment. You need to ensure that all account assignments that you require for the document splitting are set in the open items. This is particularly important if you use several ledgers in New General Ledger Accounting with different update characteristics, such as segment or profit center in the leading ledger and cost center in another ledger.

The following BAdI is an example based on a simple case:

METHOD if_ex_fagl_migr_subst~subst_item.

types: begin of l_gsb,

gsber type bseg-gsber,

end of l_gsb.

data: lt_gsb type table of l_gsb.

data: ls_gsb type l_gsb.

data: ls_bseg type bseg.

�

if is_accit-bukrs = '0001'.

loop at it_bseg into ls_bseg where gsber <> space.

clear ls_gsb.

ls_gsb-gsber = ls_bseg-gsber.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

collect ls_gsb into lt_gsb.

endloop.

describe table lt_gsb lines sy-tfill.

if sy-tfill = 1.

read table lt_gsb index 1 into ls_gsb.

case ls_gsb-gsber.

when '0001'.

cs_mig_asgmt-prctr = '1100'.

when '3000'.


when '4000'.


when others.


endcase.

else.


endif.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING

INPUT = cs_mig_asgmt-prctr

IMPORTING

OUTPUT = cs_mig_asgmt-prctr

.

endif.

ENDMETHOD.

The querying of the company code is only used as an example; it may generally be the case that the same derivation logic can apply independently of the company code, but it is also imaginable that the logic differs from company code to company code. Conducting the implementation on the basis of tables is also feasible, that is to say, the account assignments are not set as fixed, but instead are defined and read in customer-specific tables. If you use the segment and derive it from the profit center, it is not necessary to fill the segment because it is filled using standard derivation, which is performed after processing the BAdI. For this, segment derivation must be activated in Customizing (under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Additional Activities " Make Settings for Segment and Segment Derivation). You can use method GET_SPLITFIELDS (class CL_FAGL_SPLIT_SERVICES) to determine which active document splitting fields can be changed. Open items in customer/vendor accounts and G/L accounts managed on an OI basis do not usually have a profit center account assignment at the item level. An exception to this could be down payments or other special sales/purchases. These could indeed have a profit center, which could then produce a message when this profit center is overwritten by another profit center as a result of the BAdI. If necessary, you can use the BAdI FAGL_DERIVE_SEGMENT to store an alternative logic for segment derivation that differs from the standard logic.

Within this BAdI, you can perform any checks and have any error messages issued in structure ES_MESSAGE. The error messages then appear in the log. Note that the current open item is not processed further, regardless of the type of message involved (warning message or error message).





Page 33 of 53

The account assignment is supplemented in the form of a singular account assignment, which means that an open item can take one value for each account assignment object and it cannot itself be split. If, for example, you introduce a new account assignment (such as a profit center or segment) and are able to assign the open item uniquely to specific account assignment information using the BAdI intended for this purpose, then this is not critical. If you have business areas, for example, active in classic General Ledger Accounting or if you use Profit Center Accounting, this can lead to the following specific problem. The open items in the customer/vendor accounts as well as any G/L accounts managed on an OI basis (such as cash discount clearing or bank clearing) do not have any account assignment in the profit center or, under certain circumstances, in the business areas. This is particularly the case if you post documents containing multiple business areas, which consequently means that no unique business area can be transferred to the customer or vendor line item.

In this case, the following solutions could be applied:

! Writing off the affected open items (still using classic General Ledger Accounting) and where applicable reposting in form of multiple items to which a business area can be assigned uniquely. The disadvantage of this approach is that the open items receive new documents numbers, which can have an effect on subsequent processes such as correspondence, bank statement, or payment processing if you process incoming payments using an electronic bank statement. Moreover, this solution can only be considered in connection with the business area topic and in cases involving a small volume of documents. In the case of the profit center, no manual profit center accounting assignment can be specified in the transaction at the level of the customer/vendor line item.

! The document splitting information for the open customer/vendor items as well as for cash discount clearing (in the case of the vendor net procedure) can be determined using financial statement adjustment (SAPF180A), provided you do not use the adjustment otherwise. Taking tables BFOD_A, BFOK_A, and BFIT_A as the basis, the split items can then be migrated to table FAGL_SPLINFO in New General Ledger Accounting using a separate program. This solution can be considered for business area and profit center. The prerequisites for using this procedure are the corresponding knowledge about the procedure and the assessment of the effects.

! In general, you could write off the affected items and then use the BAdI to post them again item by item with regard to their subsequent assignment. For this, it must be possible to derive the account assignment using a specific logic, or, where applicable, the account assignment must be entered in the assignment or in the item text and then transferred in the BAdI to the actual account assignment. This solution would be possible for profit centers, for example.

! In some cases, it may suffice to use a dummy account assignment from the start, with an imprecise portrayal of the old processes.

It generally needs to be taken into account, however, that the line items are also split into customer/vendor accounts in the subledger, which is not the case for documents from the current fiscal year. You therefore have to check to what extent this affects your subsequent processes.

You may already be using document splitting in FI-SL. In this case, the corresponding line item tables in FI-SL could also form the starting point for the migration. However, this is not supported by the standard migration and should therefore always be performed as part of a project solution.

4.2.3.2.3 Document Splitting for Documents from Current Fiscal Year

Besides the open items from the previous year(s), the document splitting information for the documents must be built in the current year. This can occur after you have created the worklist for the documents and after the open items have been supplemented with the necessary account assignments. Included in the migration tools is a program for building the document splitting information before the actual document transfer. You find this program in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Document Transfer from Current Fiscal Year " Build Document Splitting Information.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

In contrast to the open items represented above, the documents from the current year must fulfill the criteria for document splitting in New General Ledger Accounting. If necessary, you can store alternative Customizing settings exclusively for migration purposes. For this reason, Customizing must be completed for document splitting before taking this step.

We recommend performing the following checks:

! Check G/L accounts for document splitting in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Document Transfer from Current Fiscal Year " Check Customizing Settings for Document Splitting " Check G/L Accounts for Document Splitting. Using the setting made in the G/L account master record as well as a given G/L account in Customizing, the program determines an assignment proposal for the item category that is to be used to classify that particular G/L account.

! Check document types for document splitting in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Document Transfer from Current Fiscal Year " Check Customizing Settings for Document Splitting " Check Document Types for Document Splitting. In the case of document types that have documents after the migration date, the system checks whether a business transaction and a business transaction variant are assigned in the classification of document types for document splitting.

! Check business transaction assignment for migration documents in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Document Transfer from Current Fiscal Year " Check Customizing Settings for Document Splitting " Check Business Transaction Assignment for Migration Documents. The program checks for the selected document types whether the documents posted since the migration date fulfill the definition of the assigned business transaction variant. You can use the Save Docs Containing Errors program parameter to include the documents containing errors with the business transaction variant derived from the document type in the table for alternative business transaction assignments. Here, you can assign to such documents the individual correct business transaction variant that is only used in the migration.

In the above-mentioned checks, the system checks the consistency of the Customizing settings for document splitting with regard to the existing data. Independently of these checks, the system simulates during the above-mentioned validation document splitting for the individual document at the time of posting, which goes beyond the checks described here.

Note that document splitting must be built in the correct chronological order of all documents because clearings and postings with invoice reference produce document chains that are decisive for document splitting. You can restrict the program to specific document intervals for test purposes. However, it is not recommended to use restrictions for an update run.

Existing documents that you would like to post to New General Ledger Accounting with migration may in some cases be split during document splitting in a way that makes little business sense. For this purpose, you can use a BAdI enhancement to intervene in the standard process and impose an alternative distribution result in document splitting. You can choose one of the following options for this:

! Line items are split on the basis of the lines to be specified in the BAdI.

! Line items are split on the basis of a distribution relationship defined in the BAdI.

You can implement the BAdI in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Implement Additional Enhancements (BAdIs) " Change Document Splitting Information of Documents To Be Transferred. For more detailed information, see the IMG documentation for this activity.

If you want to use the new dimension Segment for the migration to New General Ledger Accounting or if you also want to introduce profit centers, see the section Migration When Using Segment in New General Ledger Accounting below. If you want to perform document splitting using other characteristics, these





Page 35 of 53

characteristics must exist in the form of account assignments in the base items. For example, if the cost center is an internal structure element in your system and in future you also want to assign financial statement items or stocks to cost centers. Other SAP account assignment characteristics are also possible, though. If you want to create a complete financial statement with a zero balance for this characteristic, note that balance carryforward using this characteristic must be built up correctly.

If you use customer fields in New General Ledger Accounting, see the section Migration with Customer Fields.

4.2.3.2.4 Transferring Documents from Current Fiscal Year

When you have built up document splitting for the document to be transferred from the current fiscal year, the next step to subsequently post the documents in New General Ledger Accounting. For this, you should be aware of the following prerequisites:

! Customizing settings for New General Ledger Accounting are complete

! Customizing settings for the migration are correct

! Worklist for documents to be transferred is created

! The document splitting information has been built

Subsequently posting the documents also builds the totals records within the current fiscal year. For this, postings are always made to all ledgers that are assigned to the migration plan.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

4.2.4 Migration with Parallel Accounting

The following sections set out from the assumption that you use several accounting principles in General Ledger Accounting for the purpose of external reporting and that you are migrating to New General Ledger Accounting from a scenario with parallel accounting. In New General Ledger Accounting, there are two ways of portraying parallel accounting (accounts approach or ledger approach). For more information, see also SAP Note 779251. An important prerequisite in this connection is that you devise the portrayal of parallel accounting in accordance with your requirements.

What is not supported for the migration in the standard delivery?

! New implementation of parallel valuation

! New implementation of segment reporting

! Migration of a company code approach

o This needs to be managed as part of a project solution.

! Migration of a special purpose ledger approach

o This needs to be managed as part of a project solution.

! Change to chart of accounts or conversion of chart of accounts

o There is a service for this within the System Landscape Optimization (SLO).

! Simultaneous changeover of the leading depreciation area in Asset Accounting (FI-AA)

o There is a service for this within the System Landscape Optimization (SLO).

Migration with parallel accounting is often coupled with the question relating to migration to a scenario with document splitting. This special topic dealing with an environment with document splitting was already described in detail above. This section is therefore focused on parallel accounting.

4.2.4.1 Retention of Accounts Approach in New General Ledger Accounting

This migration scenario sets out from the assumption that you have used the accounts approach to implement parallel accounting in classic General Ledger Accounting and that you would like to keep this approach in New General Ledger Accounting, at least initially.

Depending on the individual initial situation at hand, there may be reasons for wanting to keep the accounts approach in New General Ledger Accounting in New General Ledger Accounting, at least initially. You may then want to switch to the ledger approach at a later stage. This may be the case if you in future want to portray more than two accounting principles at the same time and this would make the accounts approach more complex.

The accounts approach means that you have set up in General Ledger Accounting specific accounts to which you perform postings from the perspective of a particular accounting principle. This generally relates to a clearly defined set of accounts that can mostly be identified by the account number. Parallel valuation approaches from Asset Accounting are posted to these separate accounts, but also a number of manual adjustment postings and postings from foreign currency valuation. It is assumed in this scenario that you define in New General Ledger Accounting a leading ledger in which all valuations are managed in parallel accounts. The valuation or adjustment postings to parallel accounts in phase 1 are posted subsequently to New General Ledger Accounting by means of document transfer, as is the case for all other documents. For details about supplementing account assignments or document splitting, see the scenarios described previously in this document. Provided you do not change how accounts are used and the portrayal in the form of absolute postings and/or delta postings, you migrate the valuation documents (including any reversal documents) and adjustment documents to New General Ledger Accounting using the method described.





Page 37 of 53

With regard to foreign currency valuation (SAPF100), you need to consider that you may need to perform a BDIFF update to the BSEG to take into account the valuation differences in the adjustment as well. A BDIFF update in this form is no longer used in New General Ledger Accounting. In its place, valuation areas have to be used, and updates take place using tables FAGL_BSBW_HISTRY and FAGL_BSBW_HST_BL.

Using the BDIFF update prevents the use of parallel valuation because the original open items are updated and no parallel valuation is performed by valuation area. For this reason, we recommend already using the valuation area functionality in classic General Ledger Accounting in place of the BDIFF update. Depending on the accounting principle applied, it may be necessary for the valuation difference in the BDIFF to be considered during the changeover to valuation areas. This is necessary in the case of the strict lowest value principle if a large number of open items need to be valuated automatically.

If the BDIFF update was previously conducted using the strict lowest value principle, the following scenarios are feasible:

! Changeover to valuation areas in classic General Ledger Accounting at a fixed point in time.

o Transfer of the valuation difference in the BDIFF to table BSBW using a customer-owned program. Since updates to table BSBW are made according to valuation area, you need to decide which valuation area takes the valuation difference.

o Resetting the valuation using SAPF100. With the reset, the BDIFF is set to zero and an inverse posting for the same amount is made. The posting is made on the key date, and not by period.

o New valuation using the valuation areas in classic General Ledger Accounting.

o Transfer of the BSBW entries to the new tables FAGL_BSBW_HISTRY and FAGL_BSBW_HST_BL. In this way, the new valuation is based on this information in New General Ledger Accounting.

! Changeover to valuation areas in New General Ledger Accounting

o Transfer of BDIFF directly to new tables FAGL_BSBW_HISTRY and FAGL_BSBW_HST_BL using a customer-owned program. As before, you need to decide to which valuation area the update is made.

o Resetting the valuation in classic General Ledger Accounting using SAPF100, as previously.

o New valuation at the time of the first close in New General Ledger Accounting

If a BDIFF update is used in connection with the year-end valuation, clearing resets the adjustment accounts in all ledgers during subsequent posting in the new fiscal year. These accounts have to be written off retrospectively and manually in each of the undesired ledgers.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

4.2.4.2 From Accounts Approach to Ledger Approach in New General Ledger Accounting

4.2.4.2.1 General Considerations for the Transition from Accounts Approach to Ledger Approach

This migration scenario sets out from the assumption that you have implemented parallel accounting using the accounts approach and that, after the migration, you would like to portray parallel accounting using a ledger approach. In general, you need to take into account that an accounts approach can be portrayed in individual ways. This relates to the following topics: absolute and/or delta posting, type and scope of adjustment postings, use of valuation areas, integration of Asset Accounting, the periodicity of parallel closing, and so forth.

There are two methods that can be considered for replacing the accounts approach with a ledger approach in New General Ledger Accounting:

! One-step method: Migration to a ledger approach

! Two-step method: First, migration to just one (leading) ledger and changeover from accounts approach to a ledger approach at a later stage, typically at the next fiscal year change.

This section will now deal with the special aspects of parallel accounting using the one-step method for the migration to New General Ledger Accounting.

Fundamental to the accounts approach is the principle of three types of posting. Firstly, there is the posting of documents to common accounts so that the documents are correct for all valuations. Then there are automatic or manual postings that are made to just one area of the accounts and that are only relevant for one valuation. In some circumstances, there are also mixed postings that may result from incorrect postings or represent intended adjustment postings. In the rest of this section, we assume that only �non-mixed� postings (that is, relating to the same valuation) are involved. The ledger approach in New General Ledger Accounting operates on the basis that common postings are made to all ledgers. Postings from just one valuation view are only made to the specific ledger for this purpose. This can either be a posting to just the leading ledger if the posting is only relevant for the leading valuation, or indeed a posting to just one of the other ledgers if the posting is only relevant for the other (non-leading) valuation.

A migration scenario incorporating the changeover from the accounts approach to the ledger approach must therefore fulfill the following conditions:

! It must be possible to perform closing using the accounts approach during the current fiscal year (phase 1).

! The migration at document level to all ledgers or only to individual ledgers is not supported and would definitely require too much effort because, if in doubt, individual document numbers would have to be assigned to the target ledgers.

For this reason, the migration scenario is based on the fundamental principle that postings are made to all common accounts as before. In classic General Ledger Accounting, the valuation postings or adjustment postings are already posted to the subsequent target ledger using the special transaction for New General Ledger Accounting FB01L and by specifying a ledger group. The document is already posted in classic General Ledger Accounting in the same way as in New General Ledger Accounting later to be activated and is only assigned to one ledger (or ledger group) in the document header. At the same time, an entry is already included in the BSEG_ADD as well. Automatic valuation postings from Asset Accounting (FI-AA) and from foreign currency valuation are also posted to the other ledgers. In this way, there is no need for the time-consuming assignment of documents to target ledgers. This does not yet entail updating to FAGLFLEXT, but still to GLT0 instead. You need to take into account that, in New General Ledger Accounting, no ledger-specific postings are possible via FB01L to G/L accounts managed on an OI basis. It may therefore be necessary to convert such G/L accounts beforehand. Since the parallel accounts are not usually used for operational purposes, this case should represent the exception.





Page 39 of 53

For the transfer of open items and balance carryforward, you need to note the following:

! Open items can only be managed in common accounts because the transfer of open items always applies to all ledgers and is not ledger-specific

! Balance carryforward must be transferred to specific ledgers, which means

o Common accounts to all ledgers

o Valuation-specific (parallel) accounts to the respective ledgers, that is, you perform balance carryforward repeatedly for different account selections.

It now becomes clear that a zero balance must exist within a valuation-specific account area because otherwise the accounting data would be incorrect. Note also that each retained earnings account needs to be carried forward to the respective ledger appropriate to that account.

The next section uses examples to provide solutions to frequently occurring issues.

4.2.4.2.2 Foreign Currency Valuation at End of Prior Fiscal Year with Reversal Posting

A potentially common scenario could be that the SAPF100 valuates the open items in the foreign currency as well as the balance sheet accounts managed in the foreign currency, and that these adjustment postings are then reversed on the first day of the current fiscal year. Generally, the data is posted in summarized form. In other words, there is no direct individual posting per open item. An individual booking can be selected optionally. If we initially leave aside any issues relating to document splitting, these adjustment postings are part of GLT0 and will be transferred with the balance carryforward into New General Ledger Accounting to specific ledgers.

To perform ledger-specific postings for SAPF100, you need to set the migration plan to Started. You can does this manually in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Activate Migration Plan Manually. Since in this case a clearing with a clearing date before the migration date cannot be reset, there is the option of deactivating the standard error message issued when a clearing is reset, if desired, or of changing it into a warning message or a hint.

4.2.4.2.3 Foreign Currency Valuation During Fiscal Year at Period End of Current Fiscal Year (Phase 1)

For closing during the fiscal year, you perform foreign currency valuation on parallel accounts, as before. With regard to later performing correct subsequent postings of the valuation documents and reversal documents, we recommend using the valuation areas and the accounts specific to those valuation areas, because this is the only way of performing fully automated foreign currency valuation cleanly with parallel accounts. In Customizing for New General Ledger Accounting, you use the set of accounting principles to assign the valuation areas to a target ledger. This Customizing setting needs to be made before the first mid-fiscal year valuation is performed. If no valuation area is found in SAPF100, it is assumed that the posting needs to be made to the leading ledger.

If you do not yet use valuation areas or you still perform the BDIFF update, we recommend already converting to valuation areas in the previous year. For details on the procedure regarding the BDIFF update changeover, see the earlier section Retention of Accounts Approach in New General Ledger Accounting.

4.2.4.2.4 Integration with Asset Accounting (FI-AA)

In general, you should note that no values in FI-AA need to be migrated, only the areas in New General Ledger Accounting that represent Asset Accounting. It may be necessary for the depreciation areas in Asset Accounting to be switched so that the leading valuations agree. See also the section Depreciation Area Switch in FI-AA.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

A distinction needs to be made between APC values and depreciation. In New General Ledger Accounting, differing APC values are posted using a delta depreciation area in FI-AA. You can already define this delta depreciation area in phase 0. Since this is a purely derived depreciation area, no other activities are involved. It may be that you currently post APC values in the form of delta postings anyway. The following section assumes that absolute postings are made from two depreciation areas.

4.2.4.2.4.1 APC Values

The balance sheet accounts in Asset Accounting are transferred by means of balance carryforward to specific ledgers. For this, note that you transfer the offsetting account from the periodic APC values postings to the correct ledger. The periodic APC values postings in phase 1 are posted with the subsequent target ledger. The prerequisite for this is that you assign in Customizing the relevant depreciation area to one of the other (non-leading) ledgers. With the migration, the documents are posted subsequently to FAGLFLEXT to specific ledgers.

Example:

Area FI-AA Ledger APC Values to Accounts Resulting from �

01 (US GAAP or IAS) 0L (leading) Subsequent posting (" document transfer, current fiscal year)

30 German Commercial Code

L1 (non-leading) Periodic APC values posting

60 Delta (initially only inactive)

L1 (non-leading) Periodic APC values posting (absolute from 30) and due to subsequent posting

" This leads to duplicate balances on the accounts (of the leading valuation) in ledger L1

After document transfer (subsequent posting), the periodic APC values posting to parallel asset balance sheet accounts must be canceled again by a reversal of periodic APC values posting. This can occur either in the current period or in the relevant period if you want to subsequently perform mid-fiscal year closing and reporting in phase 1 using the new ledger approach. Any closed periods may need to be opened again briefly. We recommend performing the periodic APC values postings using one of the document types defined for this purpose. In this way, these documents can easily be delimited for mass reversal.

After reversing the duplicate values, you use a special program to reset the posting status of the periodic APC values posting (reset is performed once). You do this in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Additional Activities " Reset Posting Status of Periodic Inventory Postings. Once you have activated the delta area in FI-AA for the APC values postings, you can perform the APC values posting again as a delta posting. Note that you also have to change the posting status of the absolute depreciation area for the periodic APC values posting (in the example, area 30) to Only Post Depreciation.

4.2.4.2.4.2 Depreciation

The depreciation run posts the depreciation in phase 1 to specific ledgers. This means that the depreciation in area 01 is only posted to the leading ledger and the depreciation from the other area is posted to the non-leading ledger. With the migration, the documents are then posted subsequently to specific ledgers so that no duplicate postings occur as is initially the case for APC values.

Example:





Page 41 of 53

Area FI-AA Ledger Depreciation Values to Accounts Resulting from �

01 (US GAAP or IAS) 0L (leading) Depreciation posting run with ledger group 0L " posting only in ledger 0L

30 German Commercial Code

L1 (non-leading) Depreciation posting run with ledger group 0L " posting only in ledger L1

4.2.4.2.5 Integration of Treasury and Risk Management

When using Treasury and Risk Management (formerly component CFM), it is necessary to consider that the accounting principle must be used to assign the valuation areas to the target ledger. A posting is always made absolutely in the assigned ledger. If you have not previously defined an accounting principle, this is necessary in the new environment if you want to post selectively to individual ledgers in New General Ledger Accounting. Changes to account determination are necessary so that the old accounts that are no longer used are eliminated and the target accounts are assigned.

4.2.4.2.6 Replacement of Parallel Accounts

After the migration, the �old� parallel accounts become obsolete. You can make a transfer posting of the obsolete accounts to the target accounts, specific to the ledgers and for each balance transfer posting, on the desired key date. It is necessary to ensure that the old accounts are written off before you perform the periodic APC postings and depreciation postings in New General Ledger Accounting. The transfer posting can also be made separately by balance carryforward (using the special transaction for this purpose, FBCB; see the following section on this) and by balance, current year.

With the replacement of parallel accounts, you have to change the Customizing settings for account determination accordingly.

4.2.4.2.7 Evaluating Ledger-Specific Postings in Phase 1

The ledger-specific postings in phase 1 are already updated to the BSEG_ADD before New General Ledger Accounting is activated. In the transition period, before New General Ledger Accounting is activated, these postings need to be evaluated together with the normal documents (BSEG). Moreover, the ledger-specific documents in the document evaluation reports, which select data using the logical database BRF, can be read together with the ledger-specific postings. For this, the corresponding ledger must be entered in this report in the selection screen.

Note that, for the reconciliation of transaction figures and documents in phase 1, you have to use the new report in New General Ledger Accounting because this report reads the BSEG_ADD documents and reconciles the BSEG documents with the GLT0. The new program TFC_COMPARE_VZ can be started directly if the corresponding menu entries in New General Ledger Accounting have not yet been generated. If New General Ledger Accounting has not been activated, you can execute the report with the selection criterion Ledger. The system then always compares the documents in the entry view (BSEG) against the totals table (GLT0).

4.2.4.2.8 Depreciation Area Switch in FI-AA

As was mentioned at the start of this guide, SAP provides the option of performing a depreciation area switch in Asset Accounting using a service delivered by SLO. In this section, we refer to that SLO service. In connection with the migration, this is an interest option if, in New General Ledger Accounting, you opt for group valuation as the leading valuation or leading ledger while using depreciation area 01 in Asset Accounting for local valuation. For a description of the service for performing the depreciation area switch, see SAP Service Marketplace at http://service.sap.com/slo under SAP Conversion Services " Detailed Information.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

4.2.5 Special Features in the Migration

4.2.5.1 Migration to Multiple Ledgers

The guide has already described a migration to multiple ledgers from the point of view of parallel accounting. However, there can also be other cases in which the migration is performed to an environment with multiple ledgers. The migration may also be performed to a customer-specific totals table other than the standard table FAGLFLEXT. For example, you might have customer fields that you only use in the customer-specific totals table (see also the section Migration with Customer Fields).

You generally need to note the following:

! Open items cannot be migrated to specific ledgers. This means that a balance carryforward from G/L accounts managed on an OI basis and reconciliation accounts (customers/vendors) are always built for all ledgers. Furthermore, if multiple ledgers are used with different update characteristics, you should note that all account assignment characteristics must be set in the open items using a BAdI.

! In the case of non-calendar fiscal years, multiple migration plans have to be used (for one company code). In this case, the worklists must be created for all migration plans at the same time.

! When multiple migration plans are used for a company code, the migration plan with the earliest migration date must be executed first. At this point in time, the document splitting information is built in the FAGL_SPLINFO. If an item is involved in another migration plan, the BAdI is not run again; instead, existing information is read from the FAGL_SPLINFO and only the totals record for the new ledger is built.

! If multiple migration plans are used for a company code, the status is updated in the worklist as soon as the first migration plan is executed because the status is updated in this case independently of which migration plan is selected.

! All migration plans to which a company code is assigned must have the same migration type.

Note that you have to perform the balance carryforward to all ledgers. Depending on which information you have in the ledgers, different sources may apply (such as GLT0 for the leading ledger, FI-SL ledgers for other ledgers). If your current environment already uses multiple ledgers, such as GLT0, GLT3, GLFUNCT, and GLPCT, you need to check which ledgers you might be able to combine into one ledger in New General Ledger Accounting. For this reason, it is not necessarily recommendable to migrate the current totals tables to different ledgers 1:1, because this would tend to detract from the advantage offered by New General Ledger Accounting of storing general ledger data centrally and uniformly. Although such a 1:1 migration would reduce the effort required for the migration, it would be coupled with the considerable disadvantage that reconciliation would still require effort and you would need a different data basis for your closing and internal reporting.

4.2.5.2 Migration When Using Segment in New General Ledger Accounting

New General Ledger Accounting introduces a new entity, the segment. The segment is intended in particular for segment reporting as required by IAS/IFRS and US GAAP (see also SAP Note 756146). However, with the implementation of New General Ledger Accounting, the segment does not necessarily have to replace the business area (see SAP Note 321190). If, however, you want to use the segment when you implement New General Ledger Accounting, you need to decide on how the documents for the current fiscal year that have already been posted then obtain the information subsequently via the segment.

A special feature of the migration is that the FI documents between the migration date and the activation date must be supplemented with data required for the segment. A program can be used to supplement the FI documents on the basis of the following scenarios:

! Scenario 1:





Page 43 of 53

You already use Profit Center Accounting. The segment/partner segment can be rederived from the profit center/partner profit center.

! Scenario 2:

You do not yet use Profit Center Accounting. In this case, you have the option of storing the profit center in the master data of the CO objects and of deriving the profit center on the basis of the CO objects and/or the fixed values of the report, whereby the fixed value is only set if no account assignment is found by account assignment derivation.

The program changes the account assignment in the BSEG as well as the index tables BSIS, BSAS, BSID, BSAD, BSIK, and BSAK. Change documents are also created. The program only considers FI documents that have actually been posted, which means that parked documents, recurring entry original documents, and sample documents remain unaffected.

For supplementary account assignment, the following steps are necessary:

! Create worklist for supplementing FI documents (in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Additional Activities " Create Worklist for Supplementing FI Documents). This program writes the processed documents to table FAGL_MIG_FICHA1.

! Create worklist for supplementing FI documents (in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Additional Activities " Run Worklist for Supplementing FI Documents). This program reads data from table FAGL_MIG_FICHA1 and performs the document change (whereby the document changes are also documents by change documents).

It is essential that the account assignments are supplemented before the document transfer. In other words, the account assignment information contained in the documents to be posted subsequently in the current fiscal year must be complete and correct because this information is used for the updates to the corresponding totals records. This ensures that the document information in New General Ledger Accounting agrees with the totals records and there are no data inconsistencies. However, it must be taken into account that, if the profit center in FI documents is changed, for example, follow-on documents and totals records in Profit Center Accounting must also be rebuilt.

Note In order that the balance carryforward of G/L accounts managed on an OI basis be built correctly for customer and vendor reconciliation accounts, the account assignment information segment and/or profit center must be complete and correct in the items to be transferred. This is ensured by the open item transfer described above and by the related build of the balance carryforward for each account assignment. If you create segment financial statements in future, the remaining balance sheet accounts must also contain the correct balance carryforward for segments at the beginning of the fiscal year. Moreover, the balances carried forward must � as described above � either be set to segment with the balance carryforward program using a BAdI or, after the migration of the total balance of an account, transferred to the segment or segments (transaction FBCB). Note that you need to ensure that a zero balance has to exist at segment level.

However, to simplify this issue considerably, we recommend that you activate the settings for segment and segment derivation as soon as the change to the new fiscal year occurs, provided this is possible for your project circumstances and provided you have performed the technical upgrade to mySAP ERP 2005). This can occur separately from the actual activation of New General Ledger Accounting. This could be used to ensure that profit center / segment information is already contained in the complete document volume of the current fiscal year to be migrated. You can activate segment derivation in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Additional Activities " Make Settings for Segment and Segment Derivation).


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

4.2.5.3 Migration When Using Adjustments

If you use business areas and also use adjustments for the creation of business area financial statements, there are a number of special features that apply to the migration to New General Ledger Accounting. Adjustments are no longer used in New General Ledger Accounting because their function is replaced by the standard process document splitting. The previous sections of this guide covered in detail all that you need to consider for the migration of data relating to business areas, depending on whether you still want to use business areas or whether you want to adopt use of the segment, for example, in New General Ledger Accounting. If you continue to use the business area as a financial statement characteristic, then you need to perform document splitting by business area.

This section deals specifically with cases where you use adjustments. Adjustments are performed for financial statements. Summary postings are made to subsequently assign any items not yet assigned to a business area and to enable the creation of a complete financial statement with a zero balance at the business area level. As a general rule, you perform the adjustment for closing during the fiscal year at the same time as the migration (that is, in phase 1). In this way, it can be assumed at the time of the migration that there are adjustment documents that are also included in the migration with document splitting. Here is a simple example to illustrating the migration in this case.

You have previously posted a vendor invoice as follows:

Account Business Area Amount

Expense 0001 500

Expense 0002 500

Tax Blank 160

Vendor Blank 1160-

The adjustment creates the following adjustment posting:


Tax adjustment 0001 80

Tax adjustment Blank 80-



Adjustment posted Blank 580

Adjustment posted 0001 580-



After the migration (with document splitting), the following situation applies:

a) Original document


Payables 0001 580-

Payables 0002 580-

Expense 0001 500

Expense 0002 500

Tax 0001 80





Page 45 of 53

Tax 0002 80

b) Adjustment document










Clearing account 0001 580

Clearing account Blank 580-

Clearing account 0002 580

Clearing account Blank 580-

Clearing account Blank 80

Clearing account 0001 80-

Clearing account Blank 80

Clearing account 0002 80-

The clearing account is the zero balance clearing account from the Customizing for document splitting.

Since document splitting treats the adjustment documents in the way illustrated above, the financial statement would reflect all business areas, whereas considering just one business area produces an incorrect representation in the line items.

Financial Statement for Business Area 0001

Business Area Amount

Payables 0001 1160-

Clearing 0001 580

Expense 0001 500

Tax 0001 160

Clearing 0001 80-

We therefore recommend using a mass reversal to reverse those documents from the financial statement adjustment (SAPF180) that were posted in phase 1.

The P&L adjustment generates transfer postings to the accounts used for posting the original documents. In this process, the original account assigned is reversed (that is to say, posted with reversed debit/credit sign) and instead repostings are made using the account assignment(s) of the offsetting line(s). The transfer postings relate to clearing transactions that occurred in the considered period. In relation to the migration, the adjustment therefore has to have last been performed before the migration. No clearing may be performed after the last time SAPF181 is executed and before the migration.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

SAPF181 can also adjust cash discounts to assets. The posting arising here contains where applicable the business area of the asset on the assets side and no business area on the cash discount side if no unique business area can be derived from the cleared documents. In this case, SAPF181 posts a business area clearing that is not split again in document splitting because there is already a zero balance at the business area level.

4.2.5.4 Migration with Previous Use of Profit Center Accounting

This section deals with the changes relating to Profit Center Accounting and New General Ledger Accounting. We recommend portraying Profit Center Accounting in New General Ledger Accounting. The profit center exists as a fixed characteristic in the new totals table FAGLFLEXT and document splitting also enables complete financial statements to be created for profit centers. This renders obsolete the reconciliation tasks that were previously necessary between Profit Center Accounting and classic General Ledger Accounting. If you convert Profit Center Accounting to New General Ledger Accounting, you can still run classic Profit Center Accounting in parallel during an interim phase. Nevertheless, we would advise against using this parallel setup in the long term due to the effort required for reconciliation and the parallel volume of data.

With the migration, you can also transfer the balance carryforward from the totals table GLPCT. This can be useful for the P&L statement, for example, but also for any financial statement items. However, you need to consider that, in general, the information in New General Ledger Accounting is not to be built exclusively from GLPCT, but also from GLT0 or GLFUNCT. In this case, you need to ensure after the migration that the totals records in New General Ledger Accounting are correct in terms of the balance carryforward. A ledger comparison is also possible because you can restrict the data at the account level. Where necessary, you can also include other dimensions in the ledger comparison, such as the business area or function area.

If, however, particular circumstances cause you to continue to use classic Profit Center Accounting as the leading application, you should note that we do not recommend doing this in conjunction with document splitting because the specific functions in classic General Ledger Accounting that are used by Profit Center Accounting (such as adjustments) are no longer available once document splitting has been activated. For more information, see SAP Note 826357.

4.2.5.5 Migration When Using the Reconciliation Ledger

In mySAP ERP 2005, SAP delivers a new solution for the functions previously provided by the reconciliation ledger with the reconciliation postings CO"FI; in New General Ledger Accounting, these functions are replaced by real-time integration with CO. For information on how real-time integration works, see the relevant documentation.

Independently of New General Ledger Accounting, you can activate real-time integration with CO at the company code level. This means that, at the point in time when the migration occurs, documents may already exist in classic General Ledger Accounting as a result of the real-time integration with CO. The documents present in the current fiscal year are then also included in the migration to New General Ledger Accounting. You need to check whether these documents have any undesired effects in the case of migration with document splitting.

4.2.5.6 Migration with Customer Fields

With New General Ledger Accounting, you can now define customer fields that you had previously defined in FI-SL directly in New General Ledger Accounting. This makes it possible to extend your reporting data with any customer-specific dimensions without necessarily requiring several tables to be generated for data retention. With New General Ledger Accounting, it is possible to include customer fields directly in the SAP totals table FAGLFLEXT if you want to write transaction figures using these customer fields. You also have the option of including a field in the chart of accounts in order to supplement document information without including the field in a totals table. Note also that you can include SAP standard fields from the document as additional fields in the FAGLFELXT.





Page 47 of 53

For this reason, it is not always necessary to create a customer-specific totals table for customer fields. Previously, this was also necessary if totals data was required at the level of these fields. In New General Ledger, this is not the case; you can achieve this just by using FAGLFLEXT. In each case, you need to consider that customer fields also have an effect on the data volume and consequently on performance for reports and so forth. Consequently, before you define any fields � be it one field or several fields, you should first estimate the expected number of totals records. This depends especially on the amount of possible values. The data volume of a totals table in New General Ledger Accounting should not exceed approx. 5-6 million entries for all ledgers. If this is the case, then we recommend using a separate totals table for additional ledgers. In any case, you should use the standard table FAGLFLEXT for the leading ledger. If you use your own totals tables, however, you need to take into account that the reports delivered by SAP as standard and that are based on the drilldown tool or on the Report Writer/Painter, cannot be used for all ledgers updated in this table. It is particularly important to question the use of a customer-specific totals table if customer fields that would increase the data volume significantly are only required for some of the company codes and only within additional ledgers (non-leading view) � see also SAP Note 820495.

When using customer fields, you need to consider the following:

! You must fill the customer fields for the transfer of open items, especially if you use the fields for document splitting

! You must consider the fields when building balance carryforward

! You must add the customer fields to the documents of the current fiscal year.

If you introduce the customer fields with the migration to New General Ledger Accounting and these fields previously did not contain any data in FI-SL, you can use transaction FBCB to repost to the new dimensions the carried forward balances for accounts that are not managed on an OI basis. If you already have an FI-SL table with this information, it would also be feasible to migrate from the FI-SL table the balances carried forward. For accounts managed on an OI basis or reconciliation accounts for customers and vendors, the balance carryforward is built from the open items and is achieved by filling the open items.

4.2.5.7 Which Data Is Not Migrated?

There are certain types of data or documents that are not migrated or that are not affected by the migration because they are not associated with real postings relevant for General Ledger Accounting:

! Down payment request and other statistical noted items

! Payment requests

! Reference documents

o Recurring entry original document

o Sample document

! Parked documents

4.2.5.8 Subsequent or Retrospective Postings

There may be situations in which postings have been made subsequently or retrospectively in the prior fiscal year after the worklist for open items has been created. It is important to note at this point that the worklist creation program can be repeated. In this case, the entire dataset is read again and any additional open items that have arisen since the last worklist was created are included in the new worklist. If you have performed clearing subsequently, you should use the appropriate switch to reconcile the worklist to ensure the correctness of balance carryforward. We strongly recommend closing the periods before creating the worklists.

As for the documents of the current fiscal year, you can choose between determining all documents again and determining just the new documents to have been additionally posted. It is also feasible that, having performed one migration, you then migrate subsequently migrate the new documents that were posted


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

afterwards. In any case, we recommend performing the migration using a complete worklist so that the documents are migrated in one complete set in phase 1.

4.2.5.9 Clearing / Payment of Open Items from Previous Year(s)

When New General Ledger Accounting is active, a potential cash discount received or paid is assigned during clearing (or payment) to the account assignment(s) of the cleared invoice(s), according to cause. In the case of clearing in phase 2 (New General Ledger Accounting is active), no information on the original account assignments is available in the open items from phase 0, and consequently cause-related account assignment is not applied. Instead, the cash discount can only be posted using a default account assignment. The system takes as default account assignment the account assignment stored in CO in OKB9 with respect to the account assignment in the cost element.

If an individual payment is involved, you could alternatively use the BAdI to communicate the account assignment in the open item in the form of a singular account assignment. For information on this, see the section Processing Open Items above in the document splitting scenario.

4.2.5.10 Special Features with FBCB (Post Balance Carryforward for Ledger Group)

When performing the migration, you can expect to frequently encounter situations in which you have to perform subsequent postings manually to correct the opening balance sheet after transferring the balance carryforward from classic General Ledger Accounting. This depends on the dimensions that you want to use in future alongside the company code for your financial statements in New General Ledger Accounting. The special transaction FBCB has been created for this purpose: it allows postings to be made to the balance carryforward of the current fiscal year (period 0). Note the following:

! Postings can be performed even before New General Ledger Accounting is active

! Postings can only be made to accounts that are not managed on an OI basis. Furthermore, postings cannot be made to reconciliation accounts (customers/vendors) either.

! In the posting, the amounts must be specified explicitly in all currencies. There is no automatic translation of the transaction currency into the local currency. This makes it possible to post explicit currency amounts as with the foreign currency posting (F-05).

! Besides FAGLFLEXT, GLT0 is also updated in period 0. This means that the ledger comparison is also correct.

! If FBCB documents are present, it is no longer possible to reset the migration (FAGL_MIG_RESTORE_ALL). If it is essential to reset the migration, all FBCB documents must be reversed.

We recommend waiting until the line items and documents have been successfully migrated before performing the transfer postings using FBCB.

4.2.5.11 Migration and Archiving

As outlined in the above migration process, a migration transfers essentially the following data:

! Open items from previous fiscal years (phase 0)

! FI documents from the current fiscal year (phase 1)

! Totals records from classic General Ledger Accounting and/or from special purpose ledgers, if applicable

For the migration, this means that the documents from the current fiscal year must not yet be archived because they are required for subsequent posting by period. Open items are not affected in this respect because they cannot be archived all the while they are open. The totals records from the previous year and with that balance carryforward in period 0 in the current year are also available. Where necessary, you





Page 49 of 53

need to ensure that totals records prior to the previous fiscal year exist if you want to include these records in the migration for comparison purposes.

4.2.6 Special Scenarios

This guide does not describe all migration scenarios explicitly for the following reasons:

! SAP is not familiar with all initial scenarios and their specific use at the customer site (such as special purpose ledgers)

! Some migration scenarios are seldom used (such as special purpose ledgers for portraying parallel accounting)

! Some migration scenarios are not supported by SAP in mySAP ERP 2005 (company code approach for portraying parallel accounting)

This does not mean that migration cannot be performed in such scenarios. It is instead a case of other activities or adjustments beyond the steps described here being necessary and having to be performed as part of a project solution.

4.2.7 Activities After Successful Migration

Once all migration steps have been performed completely, you then need to establish whether the migration is free of errors and whether the desired result has been achieved. We recommend performing the required reconciliations beforehand in classic General Ledger Accounting. This applies in particular to the reconciliation of the subledgers with General Ledger Accounting.

You can check the correctness and completeness of the migration by analyzing the migration status. You find this activity in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Evaluation of Migration " Analyze Migration Status. You can use additional functions delivered especially for document splitting in the same path under " Tools for Document Splitting.

Using the report FAGL_MIG_SUM_STATUS, you can determine the origin of the balances in the balance carryforward in the totals table in New General Ledger Accounting. A balance carryforward can result from the transfer of open items or from the transfer of the balance carryforward from one or more source ledgers.

The correctness of the entire migration is checked and documented by comparing classic General Ledger Accounting against New General Ledger Accounting. The ledger comparison can also be used; it checks whether the values in specified source and comparison ledgers agree. Since there is the option of transferring data selectively from multiple source ledgers (as described above), this needs to be taken into account during the ledger comparison. You find the ledger comparison in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " Evaluation of Migration " Ledger Comparison. Besides the ledger comparison, known reports are also available, such as RFBILA00 or RFFSLD00. We recommend using a financial statement to document the posting data in classic General Ledger Accounting. You can do this using the classic reports before activating New General Ledger Accounting, or after activation, as required. With the standard settings, running the reports after activation reads the data from New General Ledger Accounting; consequently, you have to change the data source to GLT0 in Customizing. You make this setting under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Migration Tools " End Migration " Deactivate Update of Classic General Ledger Accounting (GLT0).

For a period of transition, you can still write documents to GLT0 after having activated New General Ledger Accounting. This is useful when you have your own reports that you can only convert to the new totals table over time. Another reason might be that you want to use a transition phase to ensure that New General Ledger Accounting delivers the same results. GLT0 can be deactivated at the desired time in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

Productive Start " Migration of Existing SAP Data " Migration Tools " End Migration " Deactivate Update of Classic General Ledger Accounting (GLT0).

After the migration, it is still useful to perform a reconciliation of General Ledger Accounting with the subledgers so as to document in this way the correctness of the data from the accounting view at the outset.

In general, we recommend involving external auditors in the entire migration process as early as possible and to as great an extent as possible.

4.2.8 What To Do If Migration Delivers Incorrect Results

In cases where incorrect data is written during the migration due to incorrect or missing account assignment derivations or Customizing settings, there are tools allowing you to reset the data. In spite of this option for resetting the migration, we recommend performing in all cases a system backup (offline backup) before starting the migration.

There are three ways of resetting the migration:

! Complete reset (transaction FAGL_MIG_RESTORE_ALL): With this function, all data is reset (open items, balance carryforward, documents in current fiscal year, as well as the worklist (optional))

! Reset open items selectively (transaction FAGL_MIG_RESTORE_OP)

! Selectively reset document transfer for current fiscal year (transaction FAGL_MIG_RESTORE_RP)

When you execute the above programs, you can decide whether the worklist is also deleted or whether the status in the worklist should only be reset to Not Processed. Resetting is only ever possible before New General Ledger Accounting has been activated. If the migration leads to errors, the recommended procedure is to reset the migration completely. You find the program for this in Customizing under Financial Accounting (New) " General Ledger Accounting (New) " Preparation for Productive Start " Migration of Existing SAP Data " Additional Activities " Reset Migration. See also the relevant IMG documentation on this activity. Although it can in some individual cases be useful to only partially reset the migration, you nevertheless have to check whether doing so guarantees the overall correctness of the data.

Cases can occur, for example, in which postings have been made using FBCB for the creation of the opening balance sheet, or in which ledger-dependent postings already exist due to parallel valuation. When a complete reset is performed, a check is run to determine whether there are any FBCB documents. If some are found, it can be assumed that you have already created the opening balance sheet. In that case, complete deletion is no longer possible. If the reason for the deletion is an error in the document transfer, you can restrict the selection to just the documents in the current fiscal year. The FBCB documents do not form part of the worklist. Since the program FAGL_MIG_RESTORE_RP only deletes documents that are in the worklist, the FBCB are consequently not deleted.

We therefore recommend checking the correctness of each step before performing the next step.

If you discover an error in the standard programs for the migration, please create a customer message under component FI-GL-MIG.





Page 51 of 53

4.3 Changed Standard Processes (processes that ran differently previously)

As an appendix to the actual migration topics, this section briefly discusses which standard processes are changed by the changeover from classic General Ledger Accounting to New General Ledger Accounting.

The main processes to be affected are as follows:

a) Reconciliation Ledger

In classic General Ledger Accounting, the reconciliation ledger could be used to meet the following requirements:

! Reconciliation postings CO " FI

! Reporting at cost element level

With mySAP ERP 2005, the reconciliation postings CO " FI are replaced by the real-time integration with CO. You can deactivate the reconciliation ledger as part of the migration to New General Ledger Accounting, but you do not have to deactivate it if you want to continue to run cost element reports on the basis of the reconciliation ledger. However, once the real-time integration with CO is active, no more reconciliation postings may be made because they would produce duplicate postings. Independently of the migration, you have to conduct the changeover from reconciliation postings to real-time integration in such a way so that no duplicate postings occur and no postings are missing. Ideally, the changeover should occur at period end.

b) Financial Statement Adjustment

The financial statement adjustments are replaced by document splitting.

c) Preparation for Consolidation

Since there is no information about the company in classic General Ledger Accounting (GLT0), it may be necessary to write company information to a separate table (GLT3 in the standard system). After the migration, this is no longer necessary because New General Ledger Accounting uses the standard totals table FAGLFLEXT for company information.

d) Cost of Sales Accounting

In mySAP ERP 2005, it is not necessary to have a special ledger in New General Ledger Accounting for the depiction of cost of sales accounting. Table GLFUNCT is replaced by totals table FAGLFLEXT. The activation of New General Ledger Accounting also changes functional area derivation. When New General Ledger Accounting is active, functional area derivation is performed in the entry screen as opposed to during document posting (as is the case in classic General Ledger Accounting). The new event 0006 replaces the previously used event 0005 for substituting the functional area. For more information, see SAP Note 740519.

e) Closing Process

For the closing operation, some of the programs used previously have been replaced by new programs, such as reconciliation in FI, reconciliation of FI-AA with FI, foreign currency valuation, or balance carryforward. Most notably, parallel closing is now possible, as well as performing closing using additional dimensions besides the company code, based on a uniform data basis. In this way, previous effort-intensive closing operations (such as adjustments) and reconciliation tasks become obsolete. For more extensive information regarding closing operations in New General Ledger Accounting, see the documentation on mySAP ERP 2005.


in mySAP ERP 2005


Release: ECC 6.0



D-69190 Walldorf

5 Additional Options

5.1 Hints and Tips

5.1.1 Performing Migration Programs in Parallel

The migration programs give you the option of parallel processing, which generally enhances performance. The prerequisite for this is that sufficient system resources be available. When parallel processing is used, a number of dialog work processes are used on one or more application servers for executing the programs, independently of whether job execution is started by a dialog program or by a background job. This means that there must also be corresponding processes available. For example, you might have marked job execution for postprocessing, but the number of dialog processes for postprocessing is reduced. The default value for the package size is 1000, but this is only a guideline and can be changed. You should note the following: The smaller the package size, the smaller the dataset sent via the network, thereby generally reducing the workload volume on the network. However, an RFC has to be set up for each package, which also uses up network resources. If the default value causes excessively long runtimes, you should reduce the package size in agreement with the network administrator and test the workload on the network.

Note that, after a BAdI has been changed, it can take a while before the change reaches all application servers. For this reason, you should wait until the change to the BAdI has reached all servers before executing the program using parallel processing.

5.1.2 Multiple Migration Plans with Non-Calendar Fiscal Year

When you perform a migration to multiple ledgers in New General Ledger Accounting, you need to use multiple migration plans for a company code if different fiscal years are defined in the ledgers. In this case, you need to ensure that the worklist for open items is built independently of the ledgers. When using document splitting, you need to ensure that the migration plan with the earlier migration date is performed first.

For example:

MP1 Migrations date 01/01/2005

MP2 Migrations date 04/01/05

An open item in the period 01/01/2005 to 03/31/2005 occurs once in the MP1 worklist for document transfer for the current fiscal year and once in the MP2 worklist. The reason for this is that the document splitting information in FAGL_SPLINFO needs to be built from the entire document as part of migration plan MP1 and not as part of the open item transfer.

5.1.3 Custom Selections for Fields in New General Ledger Accounting

If you want to use custom selections for reporting fields in New General Ledger Accounting, see SAP Note 832997.





Page 53 of 53

5.2 Contact

This guide is intended to provide an overview of issues that frequently arise in connection with the migration and to illustrate some fundamental migration scenarios.

If you have any questions concerning the migration to New General Ledger Accounting in mySAP ERP 2005, you can address them to the following contact person:

Mr Holger Reichardt Consulting Director for the Area Financials SAP Deutschland AG & Co. KG Dietmar-Hopp-Allee 15a D-69190 Walldorf Germany Telephone: +49-6227-7-42525 Fax: +49-6227-7-43280 Email: [email protected]