Cons Handbook On Migration To New GL

SAP AG
Internal and Confidential
Version: Draft
SAP AG
Release: ECC 6.0
Migration to New General

Ledger Accounting in
mySAP ERP 2005
Migration Guide for Consultants (Draft)

History
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Version
Date
Title
Draft
July 2005
Draft Version for SAP Consultants
Migration to New General Ledger Accounting in mySAP ERP 2005

Guide for Consultants
Version: Draft
Date: 07/01/2005
Page 1 of 53
Migration to New General Ledger Accounting

in mySAP ERP 2005
Release: ECC 6.0
Contents
1
Overview ..........................................................................................................................5
1.1
1.2
Preliminary Remark .....................................................................................................................5

The Object of This Guide ............................................................................................................5
1.3
1.4
1.5
1.6
1.7
What This Guide Has To Offer ....................................................................................................7

Migration is a project...................................................................................................................9
What This Guide Does Not Offer ................................................................................................9
Prerequisites..............................................................................................................................10
Phase Model for the Migration..................................................................................................11
Quick Migration for Basic Scenario ............................................................................12
2.1
2.2
2.3
Phase 0: Time Preceding Migration Date.................................................................................12

Phase 1: Time After Migration Date..........................................................................................14
Phase 2: Time After Activation Date ........................................................................................20
Migration in Detail .........................................................................................................21
3.1
3.2
What Migration Entails ..............................................................................................................21

The Steps of a Migration Project ..............................................................................................22
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
Analyzing the Initial Situation .......................................................................................................23

Analysis of Desired Target Scenario............................................................................................26
Customizing Required .................................................................................................................26
Validation of Document Splitting ..................................................................................................27
Performing the Migration .............................................................................................................27
3.3
Overview of Changes ................................................................................................................28
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
Page 2 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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
4.2.7
4.2.8
4.3
Special Scenarios ........................................................................................................................65

Activities After Successful Migration ............................................................................................65
What To Do If Migration Delivers Incorrect Results .....................................................................66
Changed Standard Processes (processes that ran differently previously) ..........................68
Additional Options ........................................................................................................70
5.1
5.1.1
5.1.2
5.1.3
5.2
Hints and Tips ............................................................................................................................70

Performing Migration Programs in Parallel...................................................................................70
Multiple Migration Plans with Non-Calendar Fiscal Year..............................................................70
Custom Selections for Fields in New General Ledger Accounting ...............................................70
Contact .......................................................................................................................................69
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 3 of 53

in mySAP ERP 2005
Release: ECC 6.0
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
documents 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 documents 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?
Is document splitting required?
Should segment reporting be possible?
Setting out from the customers 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 4 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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
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
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 5 of 53

in mySAP ERP 2005
Release: ECC 6.0

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
Yes/No
Scenario
with/without
document splitting
Special
purpose
ledgers
No
Cost of
Sales
Accounting
(COS)
No
Cost of
Sales
Accounting
(COS)
Yes
No
Yes
Classic G/L
Classic G/L
Classic G/L
Classic G/L
(other ledgers optional by

replacing accounts
approach with ledger
approach)
Only leading ledger
Scenario with
parallel
accounting
Yes/No
Scenario
with/without
document splitting
No
Scenario without
document splitting
No
Scenario with
parallel
accounting
No
Scenario with
parallel
accounting
No (Yes if
segment
reporting, for
example)
Scenario with
parallel
accounting
(others optional)
Only leading ledger

(others optional)
Only leading ledger
(others optional)
Only leading ledger
(retention of accounts
approach)
Classic G/L
No
Yes
Multiple ledgers (switch to

ledger approach)
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 6 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

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
Change of chart of accounts

o
1.6
This has to be organized using an SLO service.

This has to be organized using an SLO service.
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 7 of 53

in mySAP ERP 2005
Release: ECC 6.0
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:
Migration Date
Activation Date
Old Fiscal Year
New Fiscal Year
Classic General Ledger
Classic General Ledger
Phase 0
New General Ledger
Phase 1
Phase 2
In the three phases, you essentially perform the following activities:
Phase 0
o
Conception of New General Ledger Accounting
Customizing of New General Ledger Accounting already possible in this phase
Planning and conception of migration
Analysis of the production system, in particular when document splitting is applied
Where applicable, Customizing of document splitting
Phase 1
o
Closing the old fiscal year
Customizing of New General Ledger Accounting
Customizing of migration
Use of validation to check document splitting
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).
Page 8 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 9 of 53

in mySAP ERP 2005
Release: ECC 6.0

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 10 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

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
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 11 of 53

in mySAP ERP 2005
Release: ECC 6.0

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 12 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

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)
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 13 of 53

in mySAP ERP 2005
Release: ECC 6.0
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 14 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

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.
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.
Use of Special Purpose Ledgers

Special purposes ledgers can be used in a variety of ways. Establish the following:
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 15 of 53

in mySAP ERP 2005
Release: ECC 6.0
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:
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.
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 16 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 17 of 53

in mySAP ERP 2005
Release: ECC 6.0

!
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 18 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

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
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 19 of 53

in mySAP ERP 2005
Release: ECC 6.0

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 20 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0
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
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 21 of 53

in mySAP ERP 2005
Release: ECC 6.0

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 22 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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).
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 23 of 53

in mySAP ERP 2005
Release: ECC 6.0
4.2.2
4.2.2.1
Migration to an Environment Without Document Splitting

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
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 24 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
Transfer Open Items
4.2.2.2.1
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.
Transfer Balance Carryforward
4.2.2.2.2
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 25 of 53

in mySAP ERP 2005
Release: ECC 6.0

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.
Document Transfer of Current Fiscal Year
4.2.2.2.3
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 26 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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
4.2.3.1
Migration to an Environment with Document Splitting

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:
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 27 of 53

in mySAP ERP 2005
Release: ECC 6.0
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.
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.
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
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 28 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

!
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.

Checking and Building Data in New General Ledger Accounting with Document Splitting
4.2.3.2
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 invoicerelated 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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 29 of 53

in mySAP ERP 2005
Release: ECC 6.0

!
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
Log only
Warning messages and log
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
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 30 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

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)
Open item that is currently being processed (IS_ACCIT)
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 31 of 53

in mySAP ERP 2005
Release: ECC 6.0

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 32 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 33 of 53

in mySAP ERP 2005
Release: ECC 6.0

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 34 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 35 of 53

in mySAP ERP 2005
Release: ECC 6.0
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
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
This needs to be managed as part of a project solution.
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 36 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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.
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.
New valuation using the valuation areas in classic General Ledger Accounting.
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.
Resetting the valuation in classic General Ledger Accounting using SAPF100, as

previously.
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 37 of 53

in mySAP ERP 2005
Release: ECC 6.0
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 nonmixed 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 38 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 39 of 53

in mySAP ERP 2005
Release: ECC 6.0

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.
APC Values
4.2.4.2.4.1
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 40 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 41 of 53

in mySAP ERP 2005
Release: ECC 6.0
4.2.5
4.2.5.1
Special Features in the Migration

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 42 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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).
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 43 of 53

in mySAP ERP 2005
Release: ECC 6.0

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:

Account
Business Area
Amount
Tax adjustment
0001
80
Tax adjustment
Blank
80-
Tax adjustment
0002
80
Tax adjustment
Blank
80-
Adjustment posted
Blank
580
Adjustment posted
0001
580-
Adjustment posted
Blank
580
Adjustment posted
0002
580-
After the migration (with document splitting), the following situation applies:
a) Original document
Account
Business Area
Amount
Payables
0001
580-
Payables
0002
580-
Expense
0001
500
Expense
0002
500
Tax
0001
80
Page 44 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

Tax
0002
80
Account
Business Area
Amount
Adjustment posted
Blank
580
Adjustment posted
0001
580-
Adjustment posted
Blank
500
Adjustment posted
0002
580-
Tax adjustment
0001
80
Tax adjustment
Blank
80-
Tax adjustment
0002
80
Tax adjustment
Blank
80-
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-
b) Adjustment document
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 45 of 53

in mySAP ERP 2005
Release: ECC 6.0

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 46 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0

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 customerspecific 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
!
4.2.5.8
Recurring entry original document
Sample document
Parked documents
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
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 47 of 53

in mySAP ERP 2005
Release: ECC 6.0

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.
Clearing / Payment of Open Items from Previous Year(s)
4.2.5.9
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 48 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf
Release: ECC 6.0

in mySAP ERP 2005
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
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 49 of 53

in mySAP ERP 2005
Release: ECC 6.0

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
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 50 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0
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.
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 51 of 53

in mySAP ERP 2005
Release: ECC 6.0
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 52 of 53

Version: Draft
Date: 07/01/2005
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

in mySAP ERP 2005
Release: ECC 6.0
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: holger.reichardt@sap.com
2005 SAP AG
Neurottstr. 16
D-69190 Walldorf

Version: Draft
Date: 07/01/2005
Page 53 of 53

Cons Handbook On Migration To New GL

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cons Handbook On Migration To New GL

Uploaded by

Copyright:

Available Formats

SAP AG

Internal and Confidential

Migration to New General

Migration Guide for Consultants (Draft)

Draft Version for SAP Consultants

Migration to New General Ledger Accounting in mySAP ERP 2005

Migration to New General Ledger Accounting

Release: ECC 6.0

Guide for Consultants

Preliminary Remark .....................................................................................................................5

What This Guide Has To Offer ....................................................................................................7

Quick Migration for Basic Scenario ............................................................................12

Phase 0: Time Preceding Migration Date.................................................................................12

Migration in Detail .........................................................................................................21

What Migration Entails ..............................................................................................................21

Analyzing the Initial Situation .......................................................................................................23

Overview of Changes ................................................................................................................28

Migration with Parallel Accounting ...............................................................................................48

Migration to New General Ledger Accounting in mySAP ERP 2005

Release: ECC 6.0

Migration to New General Ledger Accounting

4.2.4.1 Retention of Accounts Approach in New General Ledger Accounting .........................................48

Special Scenarios ........................................................................................................................65

Additional Options ........................................................................................................70

Hints and Tips ............................................................................................................................70

Migration to New General Ledger Accounting in mySAP ERP 2005

Migration to New General Ledger Accounting

Release: ECC 6.0

Guide for Consultants

The Object of This Guide

Which functions are required from the business view?

Which ledgers are required besides the leading ledger?

Is document splitting required?

Should segment reporting be possible?

Migration to New General Ledger Accounting in mySAP ERP 2005

Release: ECC 6.0

Migration to New General Ledger Accounting

What This Guide Has To Offer

Which migrations are possible

As standard migrations that are supported by SAP

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

Migration to New General Ledger Accounting in mySAP ERP 2005

Migration to New General Ledger Accounting

Release: ECC 6.0

Guide for Consultants

Use of Ledgers in New

Only leading ledger

Only leading ledger

Only leading ledger

(other ledgers optional by

Only leading ledger

Only leading ledger

Multiple ledgers (switch to

Migration to New General Ledger Accounting in mySAP ERP 2005

Migration to New General Ledger Accounting

Release: ECC 6.0

Guide for Consultants

What This Guide Does Not Offer

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

Introduction of parallel accounting