Working With The New GL Migration Cockpit

Working with the New GL Migration Cockpit
Applies to:
Migration of Classical GL to New GL with Document Splitting. For more information, visit the Enterprise Resource Planning homepage.
Summary
The note lists the steps to be followed in New GL Migration for Scenario 3 (Migration with Document Splitting). It also lists some common prerequisites and notes which must be applied while working with migration cockpit Author: Sanil K Bhandari
Company: Capgemini India Pvt Ltd Created on: 03 June 2011
Author Bio
Sanil K Bhandari is a Senior Consultant for Financials and Controlling at Capgemini India Pvt Ltd..
SAP COMMUNITY NETWORK 2011 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com 1
Table of Contents
Migration to New GL with Document Splitting .................................................................................................... 3 Prerequisites and Suggested Steps before and During Migration ..................................................................... 4 Working with Migration Cockpit .......................................................................................................................... 4 Create Proposal Entries ...................................................................................................................................... 7
Maintain ....................................................................................................................................................................... 9
Related Content ................................................................................................................................................ 34 Disclaimer and Liability Notice .......................................................................................................................... 35
Migration to New GL with Document Splitting

Migration Process in SAP, seeks to perform the function of transition from the General Ledger Accounting Environment being used to the diverse functions offered by New General Ledger Accounting. Migration to an environment with Document Splitting is more complex than the scenario without document splitting. In the case of migration with Document splitting, documents must be enriched with account assignment information in order to guantee that the subsequent processes are correct. The major steps for Migration with Document Splitting are as under: Analysis of the Initial Situation Analysis of the Desired Target Scenario Customizing Settings for the Migration Validation of Document Splitting Performing the migration
The Initial situation warrants the understanding of the Goal of GL Migration and the existing processes. The following aspects need to be considered for analyzing the initial scenario: Previous use of Profit Center Accounting (EC-PCA) Previous use of Cost of Sales Accounting (COS) Previous use of External Interfaces to SAP System Previous Use of Special Purpose Ledger (FI-SL) Number of Open Item managed GL Accounts
The Analysis of the desired Target Scenario depends on the goals and outcome of the GL Migration: Portraying parallel valuation using a ledger approach Using several ledger Document Splitting and assorted parameters
The customizing settings that need to be made for a migration project can broadly be classified into two main categories: The customization for Target scenario in New GL Migration involves achieving the overall concept of the new portrayal of accounting with ledgers and document splitting, testing the functionalities, testing for completeness etc. The other step involves the setting up of the migration cockpit
Validation of document splitting is an important step for the migration, if document splitting is introduces with New GL Migration. The Actual migration happens in the migration cockpit and entails the following major steps: Determination of Migration Objects Preparations for Documents from Phase 0 Preparation for Documents from Phase 1 Carrying forward balances
Prerequisites and Suggested Steps before and During Migration

It is recommended to follow the steps as listed below:
Create Index for the Tables as per SAP Note 1014364. This will help in improving the performance of Program FAGL_MIG_OPITEMS_FILL Before starting the migration, the statistics updation should be done for all the Tables During execution of migration, regular statistics updation should be done through T Code DB20. After Activation of New GL, SAP Note 1447089 should be applied for
Working with Migration Cockpit

The T Code for Opening the Migration Cockpit is CNV_MBT_NGLM The first step in Migration Cockpit is the Setting up the Migration Project, also known as Create Project
The second step in Migration cockpit is to create Package. Each package denotes the respective scenario.
Each package denotes the respective migration scenario. Each package will further consist of six phases. You can multiple packages created as part of New GL Migration, depending on the Business Requirements.
The Starting phase for New GL Migration is the Setup Phase in the Package created for migration. The first step in the setup phase is to calculate the expected data volume in the Totals Table. Independent of the Migration, it is recommended to calculate the expected data volumes in the new Totals Table FAGLFLEXT or in your Customer Specific Totals Table (If applicable). The Report RGUIST01 can be used to estimate the number of future totals records based on currently existing data. However, this is most likely to differ, as migration happens only at the fiscal year start and lot of clearings can impact the number of entries in the new Totals Table FAGLFLEXT.
The next step in the Set Up phase is to identify whether there are modifications in the system that have an impact on the New GL or on the migration and decided whether these modifications are also required for the New General Ledger Accounting . It should be considered that the New General Ledger Accounting in SAP has many features and functionalities along with enhancement spots, which can be used in place of customer specific customizations.
The next step is to confirm the Customizing of New Gl (Except Activation of New GL). The Transport for New GL should have been migrated to the Migration Client. Generally, the Transport of the New GL Configuration should be done only when there are no users logged into the system and when the load on the client is very minimal. This step is just a confirmation that the Configuration for New GL is complete and ready for go live. This is just a confirmation for Go Live.
The next step of the migration cockpit is the creation of the migration plan. The migration plan contains all the company codes and the ledgers that are to be migrated to New GL. It is necessary that all the company codes in one migration plan should have the same fiscal year. Further, if the expected volumes are more, you may choose to have separate migration plan for each company code. Before the New GL is activated, it is required to be taken care that all the migrations plans in a package have been migrated completely and the balances are to the satisfaction of the Business Owner. The migration plan is created automatically, when you execute the function for this activity in the migration cockpit. You can assign the combination of Company codes and ledgers to multiple migration plans. However, you cannot assign the same combination of company code and ledger to more than one migration plan. You also assign the Migration date, which has to be the start of the fiscal year.
The next step is the assignment of the company codes to the migration plan. Once you have assigned a
company code with a non-leading ledger to the migration plan you cannot delete this in the new G/L customizing
Having assigned the company codes and target ledgers to the migration plan, you assign the source ledger at the level of GL Intervals or individual ledgers and currency types. This allows you to define (in particular for the
balance carryforward) which G/L Accounts are uploaded from which source ledgers and consequently tables, for instance GLT0, GLPCT. Since the configuration made in Assign Source Ledgers controls the upload carryforward it is not possible to assign G/L accounts with open-item management or customer and vendor reconciliation accounts. Currency type '10' (company code currency) and '00' (transaction currency) are always linked to the same ledger.
Create Proposal Entries

In this activity, user can generate source ledger and G/L account combination assignment proposals by filling the various options based on the migration base package being used. Company code(s): Specify the company code(s) which are assigned to the current migration plan. Target Ledger(s): Specify the ledger(s) which are assigned to the current migration plan. Activity would make assignment proposals if there is a valid combination of specified company code(s) and ledger(s) available in the current migration plan. Currency: Enter a currency type which is maintained at both specified company code and target ledger combination level. If more than one company code and target ledger combination is specified
in the selection screen, then the common currency which is maintained at all the specified company code and ledger combination(s) level has to be entered. o If user has specified a single currency, then source ledger and G/L account combination assignments will be proposed with that currency alone for each of the specified company code and target ledger combinations. If user has selected 'all currency types' option, then source ledger and G/L account combination assignments will be proposed with each of the common currencies which are maintained at all the specified company code and ledger combination(s) level. If user specifies either '00' (document currency) or '10' (company code currency) as currency type, then the assignment proposals will be made for both of these currencies.
Source Ledger: Based on the company code(s) and currency type(s) entered by the user and the migration scenario being used, user will get a list of valid source ledgers in F4 help. Source ledger is valid only if the currency type(s) chosen by the user is also available at the specified source ledger level and the specified company code(s) are also used in the source ledger entered in the selection screen. G/L Accounts: o If user has specified G/L accounts, then assignment proposals will be made only with these G/L accounts that are customized as non open item managed across all specified company code(s). If user has selected 'All Common G/L accounts' option, then assignment proposals will be made with all common G/L accounts that are customized as non open item managed across all specified company code(s). If user has selected 'All G/L accounts' option, then assignment proposals will be made with all G/L accounts that are customized as non open item managed at each specified company code(s).
Maintain With this option, you can select the G/L account(s) that are customized for the selected company code and save it with currency types and source ledgers. Currencies that are maintained at the selected company code and target ledger level would be displayed in the transaction for assignment. Only those source ledgers which are customized for the selected company code with the currencies maintained at the company code and target ledger level would be available for selection.
In the next step, the function for Segment Derivation from Profit Center is set up. This step is required to be done only, if Segment reporting is also required as part of New General Ledger.
The next step is to implement the BADI, FAGL_MIGR_SUBST, wherein all open items to be processed receive a correct account assignment. This account assignment is the basis for building the document splitting tables. The logic has to built in the BADI for supporting the standard Account Assignment. Individual derivation rules can be included in this BADI. The BADI itself does not change the account assignment in the standard open item & FI Document tables, BSIK, BSID and BSIS, BKPF and BSEG. It builds up the Open Items in the Table FAGL_MIG_OPTEMS.
The next step is to check the validation for Document Splitting. This step is required only in case, migration with Document Splitting (Scenario 3) is used. The validation is used during migration phase 1 to check the documents in the production system before activating new General Ledger Accounting. By conducting this check, it is ensured that error-free documents are available for document splitting when new General Ledger Accounting is activated. During validation, no data is updated to the general ledger tables or the information files for document splitting. The aim of validation is to test as early as possible and in a live system the business processes modeled in document splitting. Validation enables you to perform the following quality assurance measures: Extend the scope and improve the quality of modeling In an iterative procedure Identify early on any problem areas in the operational posting transactions and undertake any necessary measures Ensure that the posting rules specified in document splitting are adhered to Prevent the accumulation of documents containing errors in the current production system that are relevant for subsequent posting during migration
If migration with Scenario 3 is used, the step Check Validation for Document Splitting checks if the validation has been activated with at least Level 1 (Warning). The system issues a warning, if the validation has not been activated.
The next step in the Set Up Phase is to Check Migration Customizing. The migration plan is checked against the customizing of New General Ledger. The Program checks, if the migration plan fits the document splitting activation status in New GL. A warning message is issued, if there are company codes with document splitting assigned to a migration plan without document splitting and vice versa. The program also checks, if company codes are assigned to the migration plan and if the leading ledger and non leading ledgers are assigned to the migration plan. The Program additionally checks, if all relevant accounts have been assigned. All balance sheet accounts that are not managed on an open item basis and that are no
reconciliation accounts for customers and vendors are relevant here. Additionally, the currency types in use are also considered. Different migration plans could be handled with separate migration packages. If you have multiple migration packages respectively migration plans due to multiple source and target ledgers with different fiscal years, you might ignore the warning message that the leading ledger is not assigned to the migration plan
After the completion of this activity, the Setup phase for Migration Cockpit is complete. The next step is the Check
Up Phase. The first step in the check up phase is to check that New GL is inactive in the Client which is to be migrated to New GL. The New GL can be activated only after successful migration of all company codes with in the Client. Make sure that the relevant transport to the current test or productive system does not
contain an activation flag for New G/L. New G/L must not be activated until the migration has been completed successfully.
In the step, Check Document Splitting Characteristics and Scenarios, the program checks if Document Splitting
Characteristics are defined in the New GL customizing. Based on the Document Splitting fields, the relevant New GL Scenarios are determined. The system also checks, if the Document Splitting fields are included in the New GL Totals Table. For the Fields, that are not included in the Totals Table, you get a warning message.
In the next step, Check Company system checks if the Company Setup meets the requirements of Consolidation.
In the next step, Check Company Codes, the system checks, if all the company codes assigned to migration plan have a valid fiscal year variant assigned. The system also checks, if the totals exists for the current and the previous fiscal year for the company codes under the migration plan. SAP standard company code that are not used in the live system but which are available in customizing do not have to be considered and the warning messages can be ignored.
In the next step, Check Controlling Area, the system checks if all the company codes assigned to the Controlling Area have the same fiscal year variant assigned. If Profit Center Accounting (EC-PCA) is activated, this step also checks, if the scenario Profit Center Update is active in New General Ledger Accounting in the Migration Client. If reconciliation ledger is activated, the system checks if you have assigned a CO-FI Real Time Integration variant to the company code.
The next step is to check the Business Areas. In many cases, Business Area is used in different ways in Classical GL. If Business Area is used in the classical GL, the system checks for Customizing of Business Areas in the New GL. If Business Area wise Balance is required, document splitting scenario based on Business Area is a mandatory configuration. If you enabled the business area balance sheet in the classic general ledger or if there are totals records in GLT0 on business area level, the program for this activity checks if the scenario Business Area for new general ledger accounting is activated for the leading ledger or at least one ledger that is assigned to the relevant company codes. If the scenario is missing, you will get a warning message. If you use the business area as a document splitting criteria, the program checks if you also use the scenario Business Area for the leading ledger in new general ledger accounting. Depending on the zero balance option within the document splitting, you will get an error message if the scenario is missing and zero balance is active. Otherwise the system outputs a warning message.
In the next step, system checks for customization for Segment Derivation. SAP recommends using Profit Center as a splitting scenario, if Segmentation is also used a Splitting criterion. The segmentation of items in the current year of the migration should be checked by implementation of BADI, FAGL_MIG_ADJ_ACCIT. Segment Information in the balance carry forward can be added by implementation of BADI, FAGL_UPLOAD_CF for upload of balance carry forward.
In the next step, the check for Profit Center is performed. If you defined profit center master data, the program checks if the scenario Profit center update (FIN_PCA) is assigned for at least one ledger in new
general ledger accounting. Otherwise you will get a warning message. If the scenario is assigned to a nonleading ledger, the program also checks if the company code is assigned to that ledger.
The next step in the Check Phase is for Currencies. The system checks this setting if parallel currencies are used in the system.
The next step is the check for Source Ledgers. For all Company Codes with transaction data in FI-GL (GLT0), the system checks if these company codes are assigned to a migration plan for Leading Ledger. If GLFUNCT contains data, the system checks, if the scenario FIN_UKV is active for the leading or non leading ledger. If EC-PCA is active or if there is transactional data in GLPCT, the system checks if FIN_PCA is active for one of the ledger at least.
The next step in check up phase is the Check for FI Documents and line items. The system checks, if there is an archive for any documents, posted after the migration date. The check happens for the archival object FI_DOCUMNT.
For scenario 3 (Migration with Document Splitting), the next step in the migration plan is the check for validation of Document Splitting. The system checks, if Document Splitting check has been activated, at least with Level 1 (Warning).
Using the settings made in the general ledger account master record as well as a given general ledger account in customizing, the program determines an assignment proposal for the item category that is to be used to classify that particular general ledger account.
The system than checks the Document Type for classification for Document Splitting
During the Actual Migration, the system may take a lot of time in Execution of this Program. In such a case, the package in the item should be reduced to 5000 from 50000. The next step is to check Business Transaction Assignments for Documents. The program checks whether each of the selected documents posted in Phase I applies the rules stored in the Business Transaction Variant assigned to that document.
The next step in the check up phase is the check for implementation of SAP Notes. The system checks, if the required technical prerequisites for migration are maintained in the system.
The Next Phase in the GL Migration Cockpit is Preparation Phase. The first step in the Preparation phase is the Reconciliation and closing of previous fiscal year. A basic requirement for migration is that the previous fiscal year is definitely closed and must not be opened under any circumstances. The activities required to be done are as: Closing of FI Posting Periods Closing of FI-SL Posting periods Closing of CO Periods Closing Previous Year in Asset Accounting Closing Previous Fiscal Periods in MM
The next step in the Preparation Phase is the Registration of User Id. The User Id which need to be registered are the user ids which will be used for migration. All other user id need to be locked during this phase.
The next step in the Preparation Phase are database and system activities. At this point, it is recommended that a full offline back up of the migration client is taken before the actual migration starts. The other system related activities include cancellation of the scheduled job, stopping connection for RFC, ALE etc.
If you use business areas and also use adjustments for the creation of business area financial statements, you need to consider a special feature that applies to the migration to new General Ledger Accounting: Adjustments are no longer used in new General Ledger Accounting because these functions have been replaced by document splitting. If you continue to use the business area as a financial statement characteristic, you need to perform document splitting using the characteristic Business Area with option Zero Balance (requires migration package 3 , 5 or 6). In this case, you have to consider that adjustments are performed for financial statements. Summary postings are made to subsequently assign any items not assigned to a business area and to enable the creation of a complete financial statement with a zero balance at business area level. In general, you perform the adjustment for mid-year closing at the same time as the migration (that is, in migration phase 1). In this way, you can assume at the time of the migration that there are adjustment documents that are also included in the migration with document splitting. It is also recommended using a mass reversal to reverse those documents from the financial statement adjustments (SAPF180) that were posted in migration phase 1 (by period). Please note that the SAPF180S reversal function resets only the tables for the balance sheet adjustments, but not the FI documents created by SAPF180. For reversal of FI documents, you have to use transaction F.80 with a suitable condition to select the relevant documents. The reference number (XBLNR) of the adjustment documents always starts with "SAPF180", so we recommend using the string "SAPF180*" as selection criteria for the mass reversal.
The next step in the Preparation phase is to confirm the reversal of foreign currency valuation.
The next step is to confirm posting or deletion of all the parked documents. There should not be any parked documents for the company codes to be migrated in any current or previous fiscal year at this point of time.
The next step in the Preparation phase is to confirm the status of open batch sessions. It is required to be confirmed that all the batch sessions have been completed processed with required postings. There should not be any open batch sessions in SM35 at this point.
The next step in the preparation phase is the applicability of automatic payment runs. It is required that no payment runs are in processing stage. Payment Runs not required should ideally be deleted at this time of migration.
A prerequisite for a consistent migration of the open items is that the current account control settings are correct. If in the past the account control settings have been switched from "open item managed" to "non-
open item managed" or vice versa without adjusting the corresponding line items, there is an inconsistency that will cause problems during/after the migration process.
The transfer of the balance carry-forward to new general ledger accounting cannot take place until the balance carry-forward program for the source ledger has been performed completely. The balance carryforward in the source ledgers up to the current fiscal year (of the migration) completion will be confirmed. In the case of G/L accounts that are not managed on an open-item basis and that do not represent reconciliation accounts for customers or vendors, balances are transferred in totals, not by document line item to the New GL Totals Table FAGLFLEXT. Make sure that you create the balance carry forward for these accounts within the relevant source ledger in classic G/L. Activity 'Transfer Balance Carry-Forward' in 'Migration phase' transfers the balance carry forward values from an appropriate source ledger (such as GLT0, GLT3, or GLFUNCT) that has been assigned in the setup phase into a ledger in New General Ledger Accounting. Balance carry forward in the source ledgers up to the current fiscal year (of the migration) is required to build the totals table in New General Ledger Accounting correctly using the 'Transfer Balance Carry-Forward' activity.
Create the Balance Sheet in Classical Ledger
The next phase in the Migration Cockpit is the Migration Phase . This essentially is done in two parts: Migration of data of previous fiscal year Migration of data from the fiscal year as that of migration
The first step in the Migration Cockpit is the building up of Worklist for open items. All G/L account lines that are managed on accounts payable, accounts receivable, or open item basis and that were not cleared on the date of the migration are selected for the specified migration plan. The worklist is stored in the Table FAGL_MIG_OPITEMS
The next step is to build work list for Documents. All Documents that have been posted from the migration date are built in this worklist.
The next step is the confirmation of Worklist creation. After this step, no further open items or documents can be added to the work list created.
The next step in the Migration is to generate coding for New GL. To ensure that the migration process will be executed with the most current coding of the posting interface for new G/L, you can execute program RGZZGLUX. If you use several migration packages within one and the same system you have to perform the activity only once. For all other migration packages you can set the status of the activity manually. Make sure that no other postings will be done during the runtime (less than 15 minutes) of the generation. The generation affects the whole system (client-independent).
The first step in migration of Previous Fiscal year is the balance carry forward of previous fiscal year. In this step, system creates a balance carry forward to the year of migration by transferring the balance carry forward from an existing ledger into a ledger in New General Ledger Table FAGLFLEXT. There is an option to restrict the posting to individual company codes and ledger. However, the same has to be done for all the company codes and all ledgers. The fields of the source ledger are transferred to the fields of the target ledger on the basis of name equality. If however, you want to map a custom field in source ledger to a custom field in New GL Table, you need to implement the BADI, FAGL_UPLOAD_CF, in which the relationship should be defined.
The next step is to check the completeness of the balance carry forward. The system checks that the balance carry forward is complete for all the GL set up in the activity, Assign Source Ledger.
The most critical step in the migration is the Processing of Split Information of Open Items from Previous Fiscal Year. This program is used to generate entries in the document splitting tables for open items that were posted before the migration date (migration phase 0). This program only collects the relevant documents, but does not do the document splitting as such. The BADI Implementation, FAGL_MIGR_SUBST is used to build the splitting information for these documents. The open items are selected from the worklist. If an error occurs for an open item (for example during validation), an error message is issued, and the open item is not saved in the tables for document splitting (FAGL_SPLINFO and FAGL_SPLINFO_VAL). The status for building up splitting information or error is built in the table FAGL_MIG_OPITEMS. The status information is as under: 00: Open items with this status have not yet been processed with this program in an update run. 01: Open items with this status have been processed with this program in an update run. However, an error has occurred. 10: Open items with this status have been successfully processed with this program in an update run. Entries have been generated in the document splitting tables. Open items with status 10 cannot be processed by this program again. You first need to change the status to 00. XX: This status is not considered in this program. This status is set once all open items have been posted subsequently to new General Ledger Accounting.
The next step is the creation of Open Items and Balances in the New GL Tables. The open items are built up in table FAGLFLEXA and balances in the Table FAGLFLEXT. For all the open items, the status is set up to XX after completion of this activity in the Table FAGL_MIG_OPITEMS.
The next step checks the completion of the Open Items Creation and balance carry forward from the work list for open items of previous year.
The next step in the migration of the previous year items is the comparison of the balances of the Target and the source ledger. The comparison by the system is at the Company code and Account level combination. There should not be any difference for this combination in the source and target ledgers.
At this point there is a provision to repost the balances in Totals Table, FAGLFLEXT manually. This is done by Transaction Code FBCB. An important point to note while posting the Transaction through FBCB is to enter the amounts both in Document Currency and Local Currency at each line item. The FBCB T Code is particularly useful in migration of balances from GLT0 to new gl and where profit center (FIN_PCA) is a scenario in New GL. In the classical GL, Profit Center wise balances are not updated in GLT0 and when the balances are carry forwarded, these are also not updated in FAGLFLEXT. As a result, the new gl trial balance report, S_PL0_86000030 has many balances with Blank Profit Center. Through reposting by FBCB, it is possible to update the GL Balances for a Profit Center, without impacting the balances at the company code level. Hence, FBCB can be used to update the balances at the Account Assignment Level for different New GL scenario like FIN_PCA, FIN_GSBER, FIN_UKR etc to name a few. All the Documents generated through FBCB are updated in period 0 for balance carry forward. It is possible to have an LSMW or BDC update for FBCB.
The next step in the New GL Migration cockpit is processing of split information for Current Year Documents. This is done from the worklist which updates the Table FAGL_MIG_OPITEMS. If the standard document splitting set up is not able to build split information for Current Year document, BADI FAGL_MIG_CL_ACCIT should be used for building alternative split information for current year documents. Each successfully processed document is assigned the status 10 in the table FAGL_MIG_OPITEMS. Documents for which split information cannot be built for what so ever reason are assigned the status as 01. You need to make sure that all documents should have the status as 10, for this step to be considered as complete.
The next step in the migration cockpit is the posting of the current year documents to New GL. With the transfer, you create entries in the line item and totals tables in new General Ledger Accounting for the documents to be transferred (migration phase 1). Thereafter, the documents from the work list will have status as 10, for processing without errors and for which split information has been built.
The next step is to check completeness of transfer of documents to New GL.
The next step in the Migration cockpit is the comparision of the source and target ledger for the current year documents and balances.
With this step all the Previous year and current year data is migrated to New GL. The next step is the evaluation of the migration.
In this tree of the migration, there is also option to reset the migration of open items or for entire migration, of the same is not found to be satisfactory. The next step in the migration cockpit is the validation phase, where in migration is validated by the business owner for correct balances, successful migration of open items etc. The steps in validation are as under: Check Correctness of Open Items and Documents Create Opening Balance Sheet for Company Codes in New General Ledger Create Balance Sheet in New General Ledger Create Opening Balance Sheet for Additional Acct Assignment Create Balance Sheet for Additional Acct. Assignments Create Additional Lists Acceptance of Migration Results by Business Owner
The next phase in the migration is the Activation of New GL Phase. In this step, the New GL is activated in the Client. This has to be performed at the last once the Migration is carried out for all the Packages Created. After activating the New GL Individually Close the Migration for each Package.
With this step the entire migration to New GL is complete.
Related Content
http://help.sap.com http://www.sap-press.de/download/dateien/1344/sappress_new_general_ledger.pdf http://sapfico-answers.blogspot.com/2010/02/sap-ecc-60-new-new-gl.html For more information, visit the Enterprise Resource Planning homepage.
Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.

Working With The New GL Migration Cockpit

Uploaded by

Document Information

Original Description:

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

Working With The New GL Migration Cockpit

Uploaded by

Copyright:

Available Formats

Working with the New GL Migration Cockpit

Company: Capgemini India Pvt Ltd Created on: 03 June 2011

SAP COMMUNITY NETWORK 2011 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com 1