Architecture NewGL En

The Basic Architecture of New General Ledger Accounting in mySAP ERP. January 2006

The Basic Architecture of New General Ledger Accounting in mySAP ERP.

Page 2

Table of Contents:

1 Foreword .........................................................................................................................3

2 Architecture of New General Ledger Accounting........................................................4

3 The Ledger Concept.......................................................................................................5

4 The New Tables FAGLFLEXT, FAGLFLEXA, and BSEG-ADD ....................................6

5 Document Splitting.........................................................................................................7

6 Improved Integration......................................................................................................9

7 Fast Close .....................................................................................................................11

8 Migration from Classic General Ledger Accounting to New General Ledger Accounting....................................................................................................................12

9 Summary .......................................................................................................................15


Page 3

1 Foreword The increased demands on general ledger accounting require new architecture concepts for today's business software. The following list contains some of the aspects determining the range of functions required of modern, forward-looking general ledger accounting:

• Standardization of international accounting principles

• Necessity of quicker period-end closing

• Simultaneous implementation of company-specific and industry-specific reporting requirements

• Cost reduction

• Increased data transparency

• Greater convergence between financial and managerial accounting

SAP set out to meet these requirements, and New General Ledger Accounting in mySAP ERP is the result incorporating all of the above points. New General Ledger Accounting enables you to:

• Considerably accelerate your period-end closing

• Perform your reporting flexibly on the basis of data reconciled in real time

• Portray financial reporting efficiently for local and international accounting principles

This document explains how the new requirements are incorporated technically in New General Ledger Accounting.

It also contains a general outline of the transition (or "migration") from classic General Ledger Accounting to New General Ledger Accounting.


Page 4

2 Architecture of New General Ledger Accounting In SAP Releases up to and including R/3 and Enterprise, companies would portray General Ledger Accounting partly using different SAP applications. Depending on company-specific or industry-specific requirements or the application of local accounting principles, companies had to implement application components or functions that sometimes had their own user interface. For example, a number of application components were implemented in the following cases:

The application component Special Purpose Ledger (FI-SL) was used for reporting purposes whenever the rigid structure of classic General Ledger Accounting with table GLT0 could not meet the reporting requirements (such as having totals in additional fields not contained in table GLT0, as was the case with customer-specific fields, for example).

The application component Profit Center Accounting (EC-PCA) was also portrayed in a separate application. Both FI-SL and EC-PCA partly offered special functions that were not automatically reconciled with classic General Ledger Accounting. Consequently, closing activities involved additional reconciliation effort.

One of the most important advantages of New General Ledger Accounting is that one single application component now covers all of these different functions and requirements. However, the well-established accounting interface - with its variety of services, such as currency translation - has been retained and continues to provide functions that support postings. Upstream application components, such as Sales and Distribution (SD) and Materials Management (MM), work with New General Ledger Accounting in exactly the same way as with classic General Ledger Accounting. This means that the tried and tested document tables (BSEG, BSIS, and BSAS) have been retained in New General Ledger Accounting because they form the data basis for many standard reports as well as customer-specific reports.

The functions combined in New General Ledger Accounting have the advantage that users familiar with SAP R/3 barely need to adjust themselves to the new functions in terms of user interface and system handling. The user interfaces known to users of classic General Ledger Accounting have been retained. New functions in General Ledger Accounting such as allocation or statistical key figures (from mySAP ERP2005) share the same interface design as the functions in Controlling.

From the technical standpoint, New General Ledger Accounting offers the following advantages over classic General Ledger Accounting:

• The introduction and portrayal of the business model now occurs in just one application component. This means that there is no further need for the cost of sales ledger, the special purpose ledgers in FI-SL, the reconciliation ledger, and the profit center ledger.

• Users only have to be familiar with the interface and functions of one component. Users already familiar with the R/3 System require very little training, if any.

• The data is only stored once in the system (in just one totals table), thereby eliminating data redundancy.

• No need for additional reconciliation activities during closing.

• Easier to make adjustments to business-specific requirements (such as the inclusion of customer fields as part of flexible reporting).


Page 5

3 The Ledger Concept New General Ledger Accounting uses the ledgers known from the application component FI-SL to save totals values. Use and implementation has been made easier because many tables are already preconfigured upon delivery. Although FI-SL is retained, it now has more the character of the toolbox that it was originally designed to be. In New General Ledger Accounting, a ledger or ledger group can portray one or more valuation views. For each client, there is a "leading ledger" to which all company codes are assigned. This ledger should contain the group valuation view. It is possible to add additional ledgers for each company code. By having different characteristic values and fiscal year definitions, these additional ledgers can be used for different purposes, such as parallel accounting or management reporting.

Since the innovations in New General Ledger Accounting concern for the most part how data is updated and not changes to the interface, you can now perform directly in New General Ledger Accounting postings that you previously had to perform in different components. This also applies for transfer postings between profit centers or other characteristics (such as segments) that were previously stored in FI-SL. In New General Ledger Accounting, this is portrayed by a G/L account posting with the specification of the corresponding profit center. Since the data is stored in the same table, the profit centers and General Ledger Accounting are always reconciled instantaneously. Document numbers are issued in the same way as in classic General Ledger Accounting, on the basis of the document type from the number range object RF_BELEG. In cases involving a posting to a ledger with a fiscal year definition differing from that of the leading ledger, document numbers are issued from a different number range object (FAGL_DOCNR).

Neighboring components are always updated using the leading ledger. In the standard system, SAP delivers the leading ledger 0L.

You can portray parallel accounting using the ledger approach in New General Ledger Accounting as an alternative to the account approach. To portray different valuation views for period-end closing, you can perform automatic postings using the valuation programs (such as foreign currency valuation) as well as manual postings to a specific ledger (ledger-specific postings). Normally, for postings relating to daily operations, all ledgers assigned to the company code are always updated. For this, the leading ledger exists in all company codes (across all clients), and you can define for each company code additional ledgers, possibly with different fiscal year variants. An incoming invoice, such as a payment on account, always updates all ledgers of the respective company code. The period check is always performed for the leading or representative ledger. If a ledger group does not contain the leading ledger, one of the ledgers in the group is taken as the representative ledger. This means that postings are only made if the period of the leading or representative ledger allows. Any other fiscal year definitions existing in other ledgers of the ledger group are not validated. These other ledgers are updated in every case and do not prevent the complete posting from being made.

Note:

Postings specific to ledgers or to ledger groups cannot be made to accounts managed on an open item basis.

You enter, display, and change documents in exactly the same way as in the SAP R/3 Releases. Standard users work with the (regular) entry view. When displaying documents in the entry view in New General Ledger Accounting, you have the option of switching to the general ledger view. The general ledger view is always specific to a ledger. Depending on the system setting, you can display one or more general ledger views. In certain views (ledgers), it may be useful to derive specific characteristics or to set a zero balance for all segments involved, for example, in each document.


Page 6

4 The New Tables FAGLFLEXT, FAGLFLEXA, and BSEG-ADD There are three new tables in New General Ledger Accounting:

FAGLFLEXT

SAP delivers the totals table FAGLFLEXT in the standard system. It replaces table GLT0. You can also define your own table, using table FAGLFLEXT as a template. This could be necessary if you have a very large data volume or very different characteristic values. For more information, see SAP Note 820495. Before creating new totals tables, we recommend checking whether it would not be sufficient to use the standard table. This is because new totals tables are not valuated automatically by the Report Writer or by drilldown reports.

The standard table FAGLFLEXT already contains the standard additional fields delivered by SAP and for which totals can be stored. With this standard table, many scenarios can be portrayed, you just need to activate them. These scenarios are activated very easily in Customizing. In mySAP ERP 2005, SAP delivers the following scenarios (or fields that support the following methods):

• Segment Reporting

• Profit Center Update

• Cost of Sales Accounting

• Cost Center Update

• Preparation for Consolidation

• Business Area Update

Furthermore, New General Ledger Accounting enables you to add other fields that are already supported in the standard system, such as Plant from the application component Materials Management (MM). You can include such fields in the totals table with minimum effort. You can also define your own fields (customer fields).

Whether you add fields that are already supported or define customer fields, you have to activate the fields as a customer enhancement for each ledger. The new totals table FAGLFLEXT can contain several ledgers that store period totals for a combination of characteristics. These totals can consist of fields known from classic General Ledger Accounting (G/L Account, Company Code, Fiscal Year) and, where required, of new characteristics such as Profit Center, Segment, and their partner fields.

FAGLFLEXA

The new table FAGLFLEXA (and FAGLFLEXP) is used to store the general-ledger-oriented or ledger-specific line items (actual and plan items). It contains additional information that is used in the entry view (BSEG). It is possible for different characteristics and document splitting information (provided document splitting is activated), different period shifts, and different currencies to be updated to specific ledgers for each document. This enables you to perform reporting for specific dimensions at the line item level and to select data from fields that are not found in the usual indexes BSIS and BSAS (for example, segment-specific line item reporting for G/L accounts).

BSEG-ADD

The table BSEG-ADD contains the documents that are posted in connection with valuations for year-end closing in selected parallel ledgers. BSEG-ADD documents are used in particular in connection with the ledger approach to portray parallel accounting. If you do not portray parallel accounting or if you use the account approach to portray parallel accounting, BSEG-ADD documents are not applicable.


Page 7

5 Document Splitting The document splitting function is available in General Ledger Accounting from Release mySAP ERP 2004. For each document, document splitting applies account assignment information to nonassigned accounts on the basis of rules and according to cause. Let us take the example of a vendor invoice: the assignment of profit centers to the expense accounts can be made manually, derived automatically, or performed using substitution. Document splitting places the same profit centers in the payables accounts of the document. Document splitting is an appropriate tool for determining missing account assignments according to cause in the most common accounting processes in the SAP components (such as invoices, payments, or clearing). Furthermore, this function helps you create balance sheets for entities that extend beyond the scope of the company code. Typical examples of such balance sheets are balance sheets at the segment or profit center level or balance sheets based on company-specific or industry-specific entities.

There are also processes (or mechanisms) whereby all account assignments are already determined outside of document splitting (that is, in the delivering component itself), such as postings from the SAP components Human Capital Management (HCM) or Materials Management (MM) (in the case of goods movements, for example).

The document splitting function is based on the following model: Accounting documents contain accounts that carry account assignments (such as revenues or expenses). Such accounts serve as the basis for providing dependent accounts (Accounts Payables, Receivables, Tax, for example) with account assignments according to the context (such as invoice or payment). Furthermore, the model is process-oriented. This means that account assignments from original processes are "projected" into the subsequent processes, thereby enabling account assignments according to cause in those subsequent processes.

In document splitting, there are two technical events at which document splitting information is built: • Event "Document Creation" (before the accounting interface) • Event "Accounting Interface"

Document Splitting at the Event "Document Creation"

A typical instance for this is the clearing transaction. In this event, cash discount and realized exchange rate differences are split according to source, that is, according to the proportions of the account assignments in the expense or revenue lines of the original document (such as invoice). What is special about this is the specific reference to the original transaction or line item. The component CO is updated accordingly and is thereby reconciled with New General Ledger Accounting.

Another example for item-related document splitting is the function foreign currency valuation of open items. This function transfers to CO the exchange rate differences determined.

Note

The balance valuation function does not have any reference to items or transactions. Here, the dimension-specific balance of the account (such as the balance for each segment) is used as the basic value.

Document Splitting at the Event "Accounting Interface"

The system limits itself just to splitting general ledger account assignments. This does not involve any transfer to CO.

From the technical standpoint, the event can be divided into two variants. Firstly, there is the account assignment projection. It is the result of the settings made in Customizing. Account assignments are projected from the base rows to the target rows. To minimize the effort required for the implementation, SAP delivers a number of preconfigured methods. You can only activate one


Page 8

method per client. With method 12, SAP delivers settings that support most standard processes (such as invoice, payment, or payment on account).

The second technical variant is the inheritance by the subsequent processes of business transactions, such as the clearing of vendor and customer invoices. With this variant, the original account assignments in the original invoice are transferred to the clearing lines. This is a fixed feature in the program and it cannot be altered. After the clearing transaction, the original item (such as the payables or receivables line) and the clearing item for the respective account assignment balance to zero.


Page 9

6 Improved Integration New General Ledger Accounting offers far-reaching improvements concerning the integration of neighboring components:

Integration with Controlling (CO)

The integration with the SAP component CO offers clear advantages because cross-entity postings in CO are now transferred in real time to New General Ledger Accounting. In this way, cost elements and expense accounts are always reconciled. Since this removes the need for subsequent reconciliation runs, period-end closing is accelerated considerably. In particular, this becomes evident when we take the example of Profit Center Accounting: cross-cost center transactions in CO that involve different profit centers are posted to New General Ledger Accounting in real time. This ensures a high level of transparency and quality for your data at all times.

Furthermore, New General Ledger Accounting contains the function Allocation (assessment and distribution).

Note

Allocation in General Ledger Accounting does not update the component Controlling. Its main purpose is to allocate G/L accounts (such as bank accounts) that are not cost elements, such as allocations for profit centers or segments.

Integration with Asset Accounting (FI-AA)

The integration with Asset Accounting is characterized by two types of postings: APC values postings (asset transactions) and depreciation postings.

Asset transactions that update in real time posting depreciation areas first update all ledgers in New General Ledger Accounting. If required, you can make manual postings to individual depreciation areas in Asset Accounting. In Customizing, you assign to each real parallel depreciation area (including the parallel currency areas) a delta depreciation area representing the difference between the leading valuation of fixed assets and parallel valuation. The parallel depreciation area and the relevant delta area must be assigned to the same ledger group, and this ledger group must not contain the leading ledger. If valuation differences between the leading and non-leading views arise during the posting of APC values, they are posted to the corresponding ledger group using the delta depreciation area. You can choose whether the valuation differences are posted periodically or directly (comparable with postings in real time).

Depreciation postings, on the other hand, are made as a complete posting for specific depreciation areas to the corresponding ledger group.

Integration with Consolidation (SEM-BCS)

The financial data in New General Ledger Accounting can be transferred in an integrated data transfer to SEM-BCS together with all the additional account assignments necessary for Consolidation. This is possible because, in the standard delivery, the structure of New General Ledger Accounting contains all the fields required for company consolidation or profit center consolidation. These are the fields Partner Company, Partner Profit Center, and Consolidation Transaction Type. Using an integrated data transfer (extractor), you can extract the data from New General Ledger Accounting to SAP Business Information Warehouse (BW). The data is then imported into SEM-BCS.

Some settings in Customizing for Preparation for Consolidation relating to company consolidation enable all the fields that are relevant for Consolidation to be updated correctly into New General Ledger Accounting.


Page 10

For information on the settings for preparing profit center consolidation, see SAP Note 852971, which is entitled "SEM-BCS: Integration with New General Ledger Accounting". For more detailed information on the derivation of the partner profit center, see SAP Note 826357, which is entitled "Profit Center Accounting and New General Ledger Accounting in mySAP ERP".

Data flow from New General Ledger Accounting to SEM-BCS:

As before, the integrated transfer of transaction data to SEM-BCS uses an upstream "staging" Info- provider that is filled from the source system by means of extraction. You can use a remote cube as the staging Info-provider to enable SEM-BCS to request a data transfer from the source system on an "on demand" basis.

To extract data from New General Ledger Accounting to SAP BW, you can use data source 0FI_GL_10 that is available in BI Business Content. By building the downstream data flow in BI Business Content, you can, however, only update some of the transferred fields. This is due to the technical restrictions related to performing updates to an ODS object. For information on how you can set up a data transfer on the basis of the Business Content for the areas New General Ledger Accounting and SEM-BCS, see SAP Note 852971, which is entitled "SEM-BCS: Integration with New General Ledger Accounting".

Integration with EC-CS

Corresponding to the scenario in use, it is possible to update EC-CS directly from New General Ledger Accounting. For information on the special features, see SAP Note 826357, entitled "Profit Center Accounting and New General Ledger Accounting in mySAP ERP".

It is not possible to use report RFBILA00 to set up periodic data extraction from New General Ledger Accounting to Consolidation. To make it possible to convert processes step-by-step as part of the introduction of New General Ledger Accounting, you have the option of updating the consolidation preparation ledger alongside New General Ledger Accounting during an interim phase and to use report RFBILA00 to transfer the data from there to Consolidation. Note, however, that this is an interim solution because the extract can only be created using the format of the standard totals table GLT3.

In principle, you can perform a rollup from the new totals table FAGLFLEXT to the receiver table ECMCT using transfer rules and exits. You can also perform a rollup from New General Ledger Accounting using the standard exits for the conversion of the data from Profit Center Accounting to EC-CS, provided you use for the relevant fields in New General Ledger Accounting the same data elements as in the profit center totals table GLPCT.


Page 11

7 Fast Close New General Ledger Accounting offers significant advantages for period-end closing. With document splitting, the data in New General Ledger Accounting already meets the reporting requirements from the time of posting. In Customizing, you can make a zero balance setting for the corresponding characteristics (segment, profit center, customer fields) in each document. In this way, you can create a (non-consolidated) balance sheet at the level of these characteristics at any time. There is no longer any need for additional program runs to split the characteristics. This also applies to the reconciliation between CO and New General Ledger Accounting: In the case of cross-entity postings in CO (such as transfer postings for costs from one cost center or profit center to another, be it manual or via allocations), the values are updated to New General Ledger Accounting in real time. In this way, both components are synchronized for these transactions. There is no longer any need for additional reconciliation activities or for the use of the reconciliation ledger. The system provides data on the origin of such documents. If you have to distribute values for specific general ledger characteristics, such as for a customer field, using a specific scheme, you can perform allocations in New General Ledger Accounting. The allocations are always made for specific ledgers and operate in the same way as allocations in CO.

Note

You cannot allocate reconciliation accounts and G/L accounts managed on an open item basis because open items cannot be stored by ledger.

Furthermore, the system provides the option of using transaction FB50L to make ledger-specific G/L account postings. These postings are particularly relevant for closing or correction postings relating to particular accounting principles.

Note

Ledger-specific postings are not supported for document splitting because SAP assumes that such postings become actual documents in the sense of an invoice or payment. Instead, ledger-specific postings are G/L account postings or adjustment postings in connection with period-end closing when multiple ledgers are used to portray parallel accounting.

The above points show that period-end closing has not only been simplified greatly but also made considerably faster.


Page 12

8 Migration from Classic General Ledger Accounting to New General Ledger Accounting

The transition from classic to New General Ledger Accounting is supported in mySAP ERP 2005 in the standard delivery. However, the migration involves more than just activating New General Ledger Accounting. It is more a case of migrating the data from one environment to another. Migration is only possible as part of a migration project. A range of migration tools in Customizing assist you in performing the necessary steps in an intelligent sequence. Customers using mySAP ERP2004 obtain the migration tools with Support Package 10. It is important that you read SAP Note 812919 on this topic and that you follow the procedure described there.

Note

You have to perform the migration in a test environment first so that you can identify any exceptional cases that arise.

The migration from classic General Ledger Accounting to New General Ledger Accounting occurs at the end of the fiscal year in relation to a key date. The migration date specifies that all documents with a posting date matching or following the migration date (in general,the first day of the new fiscal year) are transferred subsequently to the new tables using a program. Until then, the documents of the new fiscal year are temporarily stored in the classic totals table GLT0.

With this procedure, complete financial statements can be created until the end of the previous fiscal year on the basis of the tables in classic General Ledger Accounting. This guarantees the continuity of the data. Moreover, it makes it possible to reconcile the values from the previous year in the old tables with the current values in the new tables.

The standard procedure for the migration is divided into three phases: • Phase 0

This is the phase before the fiscal year change. In this phase, even though classic General Ledger Accounting is still active, certain activities can still be performed, such as the creation of the blueprint or the configuration of New General Ledger Accounting in Customizing. If you want to use document splitting, you can, in this phase, run an analysis on the business processes and on the Customizing settings for document splitting. This analysis is essential because the document splitting logic depends on the document type.

• Phase 1

This phase concerns the period starting with the migration date and ending upon the activation of New General Ledger Accounting. One of the purposes of the migration date is to determine the open items of the past fiscal year for a specific key date. If the previous fiscal year is closed and document splitting is active, the items that were open on the migration date (such as payables and receivables) are filled with additional account assignments by a Business Add-In (BAdI) and then transferred via balance carryforward for each dimension to the new totals table FAGLFLEXT. The period balances of the new fiscal year are updated by clearing transactions from phase 1 and later.

The balances of the balance sheet accounts not managed on an OI basis are carried forward to the new tables in a separate run.

In general, you can choose any ledger as the origin ledger of the balances. It is possible, for instance, for some balances of the G/L accounts to be built from SL ledgers while other balances are taken from classic Profit Center Accounting. Ensuring the correctness of the result for complete financial statements forms part of the project.

If you additionally want to create the target balances for new dimensions, you have the following options:


Page 13

• You can derive them from the source balances (such as Source: Profit Center Balances - Derivation of the Segment � Target: Balances per Segment). The SAP standard delivery contains a derivation tool.

• You can enable derivation using the BAdI FAGL_UPLOAD_CF. • For balances without dimensions, you can make manual transfer postings into the desired

dimensions.

The period balances of the current fiscal year of these accounts are built in the same way as the accounts managed on an OI basis during the subsequent transfer of postings from phase 1. Ideally, the subsequent transfer of documents should occur at the end of phase 1 and before New General Ledger Accounting is activated. If the check routines provided still identify serious errors, it is then possible to reset the migration completely and perform a new migration.

• Phase 2

This phase starts with the activation of New General Ledger Accounting. The data is now no longer updated to the tables in classic General Ledger Accounting but to the new tables. If you are certain that the system settings lead to correct postings from phase 1, you can wait until phase 2 (instead of at the end of phase 1) before transferring to the new tables any documents posted in the current fiscal year up until New General Ledger Accounting was activated. In principle, the data from phase 1 is now available for comparison purposes in classic General Ledger Accounting as well as in New General Ledger Accounting.

Technical Steps for the Migration from Classic General Ledger Accounting to New General Ledger Accounting

Before you can start the migration, you have to create a migration plan. A migration plan contains the migration date (see above), the affected company codes, and the target ledger. In a migration plan, you specify whether a migration occurs with or without document splitting. You have to assign different migration plans to company codes with different fiscal year definitions because they have a different migration date. All migration steps are performed in relation to the relevant migration plan. The procedure used by companies for the migration can end up quite unique. Nevertheless, the migration generally entails the following steps:

• Creation of the worklist (selection of all items that are open on the migration date and of the documents from phase 1)

• Where required, enhancement of additional account assignments for open items (if financial statements are required for the dimensions in question). This can only occur in combination with the document splitting function.

• Balance carryforward of accounts managed on an open item basis and reconciliation accounts for customers and vendors and so on (possibly supplemented with additional dimensions)

• Transfer of balance carryforward of balance sheet accounts not managed on an open item basis.

• Subsequent transfer of documents from phase 1 into the new tables

• End of the migration

• Activation of New General Ledger Accounting

With mySAP ERP 2005, you can use the Migration Cockpit as an additional tool for performing the migration. This tool has an interface and functions resembling those in the Closing Cockpit. It contains two different task lists: one with and one without document splitting. The task list provides a transparent representation of the migration process. You can adapt the task list to the migration requirements of your company.


Page 14

Another tool that you can use for the migration is the validation of document splitting. The system can deliver documentation on postings that are incorrect from the perspective of Customizing for document splitting. For this, you can make a setting specifying whether the system only creates a background log or whether it also issues a system message or error message. The analysis of this background log could in some cases be used as basic information for a training course allowing users to examine critical cases in terms of posting behavior.


Page 15

9 Summary New General Ledger Accounting combines functions that were previously covered by different SAP components and that used to require periodic reconciliation. With transparent data structures, flexibility in data design, uniform user interface, the elimination of data redundancy, and real-time integration with CO, New General Ledger Accounting meets the requirements of modern, future-oriented general ledger accounting solution for companies of all sizes and from varying industries.

Documents

Architecture NewGL En