migration documentation

1. 90001_TREE_STRUCTURE_HEAD

1.1. NGL00_SETUP_PHASE

1.1.1. NGL00_MIGRATION_DOCUMENTATION (Document Link - /NGL/NGLM_MIGRATION_DOCU )

Migration Documentation

Purpose

New general ledger accounting combines a variety of existing methods for representing ledgers and also delivers new methods. Customers wanting to use all these options face two challenges:

� Which functions are required from the business point of view? � Which ledgers are required besides the leading ledger? � Is document splitting required? � Should segment reporting be possible?

� Setting out from the customer's current situation (such as classic general ledger accounting, account approach, no document splitting), what steps must the customer undertake 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).

The migration monitor assumes that you want to perform the transition from classic general ledger accounting (installed operationally with R/3 Enterprise or an earlier release) to new general ledger accounting in mySAP ERP 2004 (ECC5.0) or SAP ERP 6.0 (ECC6.0).

However, the following limitations apply in SAP ERP 2004:

� The functions for "Validation of Document Splitting" are not available (Migration package 3, 5 and 6).

Note:

If you have not previously used any active installation and you are in the evaluation or project stage, you need to decide (depending on 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 thus avoid the need for any subsequent migration.

Making changes or enhancements to the range of functions available in an active installation of new general ledger accounting 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 are not meant to be used for this purpose.

If you migrate from a third-party system to new general ledger accounting, this migration guide is not relevant to you. For tips on performing the migration from a third-party system, see SAP Note 890237.

Prerequisites

In order for the migration to new general ledger to succeed, it is essential that you follow the migration

of 386

02.03.2011saphtmlp://htmlviewer.sap.com/JMup8GDL3D3X0800mAWyaG/HTML000002.htm

phase model. The phase model consists of the following three phases:

Phase 0

� 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

� Closing the old fiscal year � Customizing of new general ledger accounting � Customizing of migration � Use of validation to check document splitting � Performing the actual migration at the end of phase 1 � Activation of new general ledger accounting after successful migration

Phase 2

� Use of new general ledger accounting � Deactivation of update of classic general ledger accounting (GLT0) after transition period

There are two dates of particular significance:

� Migration date (start of the fiscal year for which the migration is performed) � The migration date is the start of phase 1

� Activation date (date on which new general ledger accounting is activated) � The activation date is the start of phase 2

Note that the previous fiscal year (that is, the fiscal year before the migration date) definitely must be closed before the migration starts. It is technically not possible to reopen the previous fiscal year after the migration.

Additional Information

For a detailed description of the migration process, please refer to the migration guide on SAP Service Marketplace.

https://service.sap.com/glmig

1.1. 2. NGL00_MIGRATION_QUANTITIES_BASE_UNIT (Document Link - /NGL/NGLM_MIG_QUAN_BASE_UNIT )

Prerequisites to Migrate Quantities and Base Unit of Measures

Use

of 386


To be able to migrate quantities and base unit of measures, certain corrections already need to be implemented in the system during Phase 0 itself. Both the below mentioned notes and the related notes are relevant to ensure that quantities fields will be migrated.

SAP Note ERP2004 ERP2005

1477286 X -

1477363 - X

1.1. 3. NGL00_CUSTOMIZING_VIA_TRANSPORT (Document Link - /NGL/NGLM_CSTMZ_VIA_TRANSPRT )

Customizing of Package via Transport Request

Use

If you use the recommended three-system-landscape (typically consisting of a development system, a quality assurance system, and a live system), you have to do all relevant customizing settings and developments for BAdIs in the development system. In this case, you confirm in this activity that customizing and BAdI development take place in another system and that the results will be imported into the current system. Once you have confirmed this, another activity called Customizing via Transport Request Confirmed is automatically inserted in the process tree and set to status green.

If you do the customizing directly in the current system, do not execute this step.

Remark: If you execute this activity before the migration plan has been transported from a development system to the current system, you will get an error message saying that the migration plan does not exist.

1.1. 4. NGL00_CALC_DATA_VOLUME_IN_TOTALS_TABLE (Document Link - /NGL/NGLM_CALC_DATA_VOL_TOTS )

Calculate Expected Data Volume in Totals Table

Use

Independent of the migration, SAP recommends calculating the expected data volume in the new totals table FAGLFLEXT or in your customer-specific totals table (if applicable).

See also SAP Note 820495.

Using report RGUIST01, you can estimate the number of future totals records based on currently existing data (SAP Note 1045430).

Please note that the actual number of entries in the table will most likely differ from these calculated figures.

of 386


1.1. 5. NGL00_CHECK_SYSTEM_MODIFICATIONS (Document Link -

/NGL/NGLM_CHECK_SYSTEM_MODS )

Check System Modifications or Enhancements

Use

We recommend that you check whether there are modifications in your system that have an impact on the new general ledger or on the migration and decide whether these modifications are also required for new general ledger accounting, considering that modifications can often be replaced by SAP standard functionality or enhancements within the SAP standard.

If you decide to keep modifications in ERP, make sure they are tested thoroughly in connection with the new general ledger.

Note that this check is independent of the technical modification clearing (using transaction SPAU) that you did in connection with the technical upgrade to mySAP ERP.

1.1. 6. NGL00_CUSTOMIZING_SETUP_FOR_NEWGL (Document Link - /NGL/NGLM_CUST_SETUP_4_NEWGL )

Confirm Customizing Setup for New GL

Use

In this activity, you confirm that customizing for new General Ledger Accounting is finished and ready for go-live.

Note that it is currently not possible in SAP standard to activate additional non-leading ledgers. Information about the risk of subsequent changes in document splitting, ledgers, and scenarios is provided in SAP Note 891144.

Prerequisites

The business blueprint for new General Ledger Accounting is completed and technically implemented in the system.

1.1. 7. NGL00_CREATE_MIGRATION_PLAN (Document Link - /NGL/NGLM_CREATE_MIG_PLAN )

Create Migration Plan

Use

of 386


In this activity, the Migration Plan is created. The migration plan contains all company code and ledger objects that are to be migrated together for those company codes and ledgers assigned to the migration plan. Company codes that have the same fiscal year limits can be migrated together in one migration plan. For very large volumes of data, you may have to define multiple migration plans to conduct the migration company code by company code. To do this you have to define another migration package in the migration server overview.

The migration plans are internally generated with the keys 'A01', 'A02' to 'Z99'.

Standard settings

SAP does not deliver standard migration plans. You can create at least one migration plan according to your migration package.

Activities

To set up the migration plan, proceed as follows.

1. The migration plan is created automatically when you execute the function for this activity. The migration plan applies to your migration package.

2. In the next activity, you set the migration date, which must coincide with the start date of a fiscal year.

Please note the following:

� The last day of the fiscal year variant of the company code or ledger must agree with the migration date minus one. For more information and an example, see Migration Date.

� You can assign company codes and ledgers to more than one migration plan. However you cannot assign the same combination of company code and ledger to more than one migration plan. There must be no more than one migration running for each combination of company code and ledger.

� Once you have assigned company codes and a ledger to a migration plan and started the migration, you cannot change the migration type and the migration date and assignments anymore.

1. Having set the Migration Date, you assign company codes and ledgers to the migration plan.

1.1. 8. NGL00_SET MIGRATION DATE (Document Link - /NGL/NGLM_SET_MIGRATION_DATE )

Set Migration Date

Use

Having created the Migration Plan, you need to choose the migration date. The activity suggests all possible combinations of migration dates for your company codes and fiscal year variants.

It is not possible to set the migration date to a start date prior to the current fiscal year.

Prerequisites

of 386


The migration plan has been created.

The migration date is always the start of the fiscal year. The migration usually takes place directly after the previous fiscal year has been closed. After the migration, postings to previous fiscal year are no longer possible. Furthermore it is not possible to reset clearing of clearing documents posted in the previous years.

For migration package 6 only (Subsequent activation of document splitting):

Please ensure that the initial migration from classic G/L to new G/L has been executed at least one fiscal year prior to the migration date of the current migration.

Dependencies

Only relevant for SAP ERP 6.0:

If you use a migration scenario with document splitting (migration package 3, 5 or 6), the migration date should also be set as Validation Date. Migration to an environment with document splitting is more complex than the scenario without document splitting. For a migration with document splitting, line items must be supplied with account assignment information in order to guarantee that the processing and results of subsequent processes are correct. For more information, see Validation Document Splitting in the preparation phase of the migration cockpit.

Additional information

The migration date cannot be changed once the migration plan has been started.

Package specific information

For migration package 6 (Subsequent activation of document splitting):

Please ensure that in case of an initial migration from classic G/L to new G/L this migration has been executed at least one fiscal year prior to the migration date of the current migration.

For migration package 7 (Subsequent implementation of a further ledger):

Please ensure that in case of an initial migration from classic G/L to new G/L this migration has been executed completely before you start the current implementation of a new ledger.

For migration package 8 (Subsequent change from account solution to ledger solution):

You can only choose a migration date in future. Please ensure that in case of an initial migration from classic G/L to new G/L this migration has been executed at least one fiscal year prior to the migration date of the current migration.

1.1. 9. NGL00_ASSIGN_CC_AND_LEDGERS_TO_MIG_PLAN (Document Link - /NGL/NGLM_ASSIGN_CC_LEDGERS )

of 386


Assign Company Codes and Ledgers to Migration Plan

Use

Having created the Migration Plan and set the migration date, you assign the company codes and target ledgers to the migration plan. Generally, you can assign all combinations to one migration plan if you use the same fiscal year and migration scenario for all company codes.

The following cases require separate migration plans. (A migration plan relates 1:1 to a migration package):

� The fiscal year limits are different between company codes or ledgers. � You use different migration scenarios regarding document splitting within one client.

If you have multiple migration plans, you can assign company codes and ledgers to one migration plan only. It is not allowed to assign the same combination to more than one migration plan.

Recommendation

If you want to introduce new General Ledger Accounting for a number of company codes, we recommend that you use separate migration plans for company codes with very large volumes of data. Smaller company codes, on the other hand, can be migrated together in one migration plan. In this way, if an error were to occur in a large company code, causing you to reset the data completely, any smaller company codes that had already been successfully migrated would not be affected.

Note that you have to perform all activities within the migration cockpit for all migration packages.

Prerequisites

The migration plan has been created successfully.

Dependencies

The assignment of company codes and ledgers cannot be changed after the migration plan has been started.

Once you have assigned company codes and ledgers to the migration plan you can change the migration date that applies to the fiscal year definition of the assigned company codes as long as the migration plan has not yet been started.

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 (Define and Activate Non-Leading Ledgers).


For migration package 7 and 8:

It is not allowed to assign the leading ledger.

of 386


Once you have assigned the company codes and ledgers to the migration plan the new G/L customizing activity Define and Activate Non-Leading Ledgers automatically starts the migration plan.

1.1.10. NGL00_SHOW_MGPLN_CUSTOMIZING (Document Link - /NGL/NGLM_SHOW_MGPLN_CUSTMZG )

Display Migration Plan

Use

Once you have created the migration plan, you can use this display function to see the customizing settings and status of the migration plan.

The following data is shown:

� Migration date � Migration with document splitting � Migration status (started, ended) � Company codes, target (new G/L) ledger and fiscal year variant

1.1.11. NGL00_ASSIGN_SRC_AND_TRG_LEDGERS (Document Link - /NGL/NGLM_ASSIGN_SRC_TAR_LED )

Assign Source Ledgers

Use

Having assigned the company codes and target ledgers to migration plan, you assign the source ledgers at the level of G/L account intervals or individual accounts 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.

Especially for migration package 4 and 5, you are able to allocate account ranges for several accounting principles to different target ledgers; the source ledger is typically ledger '00' in table GLT0 but also other ledgers with same account balance as ledger '00' are possible.

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.

Example

of 386


You currently use the accounts approach with two accounting principles - one for local valuation and the other one for IFRS. To switch to the ledger solution in new G/L, you might use the following logic:

� All accounts starting with 1xxxxxxxxx are common accounts and will be assigned to all target ledgers

� All accounts starting with 2xxxxxxxxx are IFRS accounts only and will be assigned to leading ledger '0L' only"

� All accounts starting with 3xxxxxxxxx are local accounts only and will be assigned to non-leading ledger 'L1' only.

Features

In activity Assign Source Ledgers, you have several options that can be chosen on the entry screen. The assignment is done for every company code / target ledger combination.

Maintain (Scenario 1-5)

Maintain (Scenario 6)

Display

Propose entries

Check Entries

Copy from another company code

Copy from another migration plan

Transport entries

For migration package 6 only (subsequent activation of document splitting):

When you choose the Maintain function, the system automatically creates the proposal entries. For this specific migration package, the source ledger is always equal to the target ledger. This applies to all target ledgers of the company code and all determined currency types.

Prerequisites

The migration plan has been created successfully. Company codes and ledgers have been assigned to the migration plan.

Dependencies

Deletion or editing of existing intervals is possible as long as no account within the edited or deleted interval has been processed (uploaded). If an account is already processed, you must first RESET the upload of the corresponding interval.

of 386



For migration package 6 (subsequent activation of document splitting):

When you choose the Maintain function, the system automatically creates the proposal entries. For this specific migration package, the source ledger is always equal to the target ledger. This applies to all target ledgers of the company code and all determined currency types.

For migration package 7 (Subsequent implementation of a further ledger) and 8 (Subsequent change from account solution to ledger solution):

It is only possible to assign a new G/L ledger (leading ledger or non-leading ledger) as source ledger. Additionally you can use a FI-FL ledger as a source ledger in case you want to replace a FI-SL ledger by using new G/L ledger. Please note that in case of FI-SL ledger the ledger should provide a balance carryforward function. Otherwise you will get a warning message when checking the entries.

If you assign a FI-SL rollup ledger as a source ledger you will get a warning message.

The function copy from another migration plan can only be used for the same migration plan type. The migration packages 7 and 8 use the same migration plan type.

1.1.12. NGL00_PREPARE_SEGMENTATION

1.1.12.1. NGL00_ACTIVATE_SEGMENT_MAINTENANCE (Document Link - /NGL/NGLM_ALW_SGMNT_MAINTNCE )

Allow Maintenance of Segments

Use

New General Ledger Accounting contains a new characteristic called segment. The segment is meant to be used in particular for segment reporting as required by IAS/IFRS and US-GAAP. This activity is only relevant if you want to use the new characteristic in new General Ledger Accounting.

SAP strongly recommends using the segment derivation before activation of new General Ledger. This function ensures that all necessary documents are filled with segment information during the original posting of these documents. Therefore you need to prepare the postings that take place after the migration date and before the activation date in phase 1.

Activities

The following settings are required for segment derivation:

� You have defined at least one segment in new General Ledger customizing.

of 386


� You define the segment as ready for input in this activity of the migration cockpit. � You have defined profit centers and assigned segments to them. If you already use

profit centers, all you have to do is assign the segment to them. If you do not use profit centers within classic Profit Center Accounting (EC-PCA), you need to set up the profit center master as well. But usually you do not need to activate EC-PCA itself and to use the full functionality of EC-PCA.

1.1.12. 2. NGL00_ACTIVATE_SEGMENT_DERIVATION (Document Link - /NGL/NGLM_ACTIVT_SGMNT_DERIV )

Activate Segment Derivation

Use

In this activity, you activate the standard process of segment derivation by profit centers.

Integration

To use the segment derivation you need to allow the maintenance of segments before new General Ledger is active (in activity Allow Maintenance of Segments).

Prerequisites

To use the segment derivation, you defined all necessary segments in new General Ledger customizing and assigned the segments to profit centers.

Make sure to test your posting processes carefully - including posting processes that involve profit centers.

Example

Your migration date is 01.01.2007 (fiscal year start). The migration to new General Ledger Accounting will take place after the closing of the previous fiscal year on 15.03.2007. All documents that are posted between 01.01.2007 and 15.03.2007 are then assigned to at least one segment based on the profit center contained in the document.

1.1.13. NGL03_CREATE_BADI_FOR_DOCSPLIT_INFO_OPIT (Document Link - /NGL/NGL03_CRT_BADI_DOCSPLIT )

Create BAdI for Document Splitting Information Open Items

Use

With this activity, 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 the logic for supplementing the account assignments in the form of a Business Add-In (BAdI).

of 386


In this way, you can include individual derivation rules in a standard migration process.

Ensure that, from the perspective of the total document, an account assignment is found for each individual open item.

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 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 a specific account assignment value or object using the BAdI intended for this purpose, then this is not critical.

Features

The BAdI FAGL_MIGR_SUBST comprises the following functions:

� Transfer of the following information that you can use to implement the derivation: � The complete document within which the open item is located (IT_BSEG) � The open item that is currently being processed (IS_ACCIT) � The document header (IS_ACCHD)

� You can change the account assignments contained in structure CS_MIG_ASGMT. � With the exception of the characteristic Profit center, only initial fields can take an

account assignment. You cannot change fields that are already filled; you can only delete a dummy profit center or overwrite it with another profit center.

� You may overwrite a specified profit center with the profit center in a CO account assignment if this assignment is also set.

� In structure CS_MIG_ASGMT, you can also set additional account assignments for CO that are used 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 (tables 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, you may need to make 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. In this example, the profit center is derived from the business area of the original document if the business area is distinct. Otherwise profit center '9999' is set.

METHOD if_ex_fagl_migr_subst~subst_item.

of 386


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.

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.

of 386


else.


endif.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING

INPUT = cs_mig_asgmt-prctr

IMPORTING

OUTPUT = cs_mig_asgmt-prctr.

endif.

ENDMETHOD.

The query for 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 conceivable 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 characteristic 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 purpose, segment derivation must be activated. You find this activity in the migration cockpit under Setup phase -> Prepare segmentation -> Activate

segment derivation. You can use method GET_SPLITFIELDS (class CL_FAGL_SPLIT_SERVICES) to find out which active document splitting fields can be changed. Open items in customer and vendor accounts and G/L accounts managed on an open item basis do not usually have a profit center account assignment at the item level. An exception to this could be downpayments or other special sales or purchases. These could indeed have a profit center, which would result in a message being output when this profit center is overwritten by another profit center as a result of the BAdI.

Note: 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 the BAdI, you can perform any checks and have any error messages issued in structure ES_MESSAGE. The error messages then appear in the log. The current open item may not be processed further, regardless of the type of message involved (warning message or error message).

1.1.14. NGL03_VALIDATION_DOCUMENT_SPLITTING

of 386


1.1.14.1. NGL03_WHT_VALIDATION_OF_DOCSPLIT_MEAN (Document Link - /NGL/NGL03_VLD_DOCSPLIT_MEAN )

What Does Validation of Document Splitting Mean?

Use

You use validation during migration phase 1 to check the documents in the production system before activating new General Ledger Accounting (for migration packages 3 and 5) or document splitting (only for migration package 6). By conducting this check, you ensure that error-free documents are available for document splitting when you activate new General Ledger Accounting. 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.

During the migration, you can log error statuses in the production system and post-process them in the test system (preparation system). In this way, you prepare the post-processing of these documents in the test system (if they need to be posted subsequently) or you identify and close any gaps in the modeling of document splitting and in the business processes.

If a document to be posted does not fulfill the requirements of document splitting, you can set up the production system so that messages are issued and grant the user appropriate ways of intervening. In the case of third-party processes (such as MM or SD) and automatic processes in FI (such as payment runs or recurring entries), you can only have entries generated in the log, for example.

You can set up dependencies for the error messages on other constraints (such as account assignment determination or master data processing) that need to be fulfilled coupled with the attainment of a certain project status. You can activate validation of document splitting using time dependency and in stages.

SAP recommends using the validation of document splitting. Note that if you skip this validation the number of errors during the migration is likely to be significantly higher, and the quality of the data would not be as expected. This may endanger the whole migration. Therefore the migration packages with document splitting include a check for activation of the validation. If you use document splitting, it is not allowed to set the migration date retroactively.

to safeguarda successful migration, you must finalize your document splitting customizing including all processes already in phase 0 and transport the settings for document splitting

of 386


to your productive system. Before this takes place, you must carefully test all posting processes in a test or quality insurance system.

Prerequisites

The validation of document splitting occurs in the production system. To be able to perform validation in a useful manner and thereby avoid redundant error logs, the following prerequisites need to be fulfilled:

� You have defined and customized the leading ledger of new General Ledger Accounting.

� You have assigned the document splitting method in the customizing of new General Ledger.

� You have made or checked all other required settings in Customizing for document splitting.

� You activate the validation at migration plan level in the activity Activate Validation of Document Splitting in the process tree. For this reason, you need to transport the migration plan to the production system.

1.1.14. 2. NGL03_ACTIVATE_VALIDATION_OF_DOC_SPLIT (Document Link -

/NGL/NGLM_ACT_VALID_DOCSPLIT )

Activate Validation of Document Splitting

Use

If you want to introduce document splitting with the migration to new General Ledger Accounting, or if you want to introduce document splitting subsequently, we recommend that you activate the validation of document splitting for phase 1 of the migration.

Validating document splitting is important for the following reasons:

� You can test as early on as possible the business processes modeled in document splitting under live system conditions

� You can extend the scope and improve the quality of modeling in an iterative procedure

� You can identify problem areas of the operational posting transactions early on and take any necessary measures

� You can check whether the posting rules specified in document splitting are adhered to and, where necessary, implement measures to enforce adherence to them.

You can decide on the form validation should take:

� No validation � Log only � Warning message and log � Error message

of 386


You make the setting directly in the migration plan. To this purpose, you enter the validation date from which the documents need to be validated. The validation date relates to the posting date; that is to say, the system validates all documents with a posting date falling on or after the validation date.

Prerequisites

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

� The migration plans and the leading ledger are defined � The document splitting method has been specified � The G/L accounts used must be assigned to item categories � The document types used are assigned to business transaction variants � The assignment of item categories to the business transaction variants has been

checked and adjusted where necessary � The document splitting characteristics are defined: 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 for these characteristics directly during document entry.

� For migration packages 1 to 5: Document splitting is active for the company codes to be validated.

� For migration package 6: Document splitting is active at client level but inactivated for the relevant company codes.

Features

The 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. You can also set up different levels of validation for individual business transactions down to the transaction level (in activity Adjust Validation for Specific Processes). This is necessary if 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 Business Add-In (BadI FAGL_SPLVAL_ADJUST) to specify the level of validation in each case. Using the changeable BadI parameter CD_VAL_MOD, you can set the following fixed values in the modifiable parameters:

Validation Level

Value Meaning

Blank No validation

1 Log only

2 Warning messages and log

of 386


3 Error message

Document splitting 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 Business Add-In (BAdI FAGL_SPLVAL_ASSGNMT) 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 the migration cockpit below.

Example

You are currently using business areas in classic General Ledger Accounting. In new General Ledger Accounting, you want to introduce a complete financial statement using profit centers. If you have not yet defined the profit center structure completely, you can still derive a profit center from the business areas currently available. It is important that you only simulate this. This means that you have to supplement the documents subsequently with the account assignment Profit Center for the migration.

1.1.14. 3. NGL03_ADJUST_VALIDATION_FOR_SPECIFIC_PRO (Document Link -

/NGL/NGLM_ADJUST_VALIDATION )

Adjust Validation for Specific Processes

Use

If you are not able to validate certain processes sufficiently because account assignments have not yet been derived completely or conversion has not yet occurred, you can adjust the validation for those particular processes.

Requirements

� You have fulfilled the prerequisites for the validation of document splitting. � You have activated validation in the migration cockpit activity before.

Activities

For each reference transaction, business transaction, transaction, and batch input marker, specify a validation level.

The validation level is adjusted to the level defined if the general activation of validation has a higher level.

Choose one of the following validation levels:

Value Meaning

Blank No validation

of 386


1 Only log

2 Warning messages and log

3 Error message

Example

In the general activation of validation, you have defined the validation level Error. However, you only want to have a log written for background processes. To this purpose, enter the validation level Only Log for the batch input marker.

1.1.14. 4. NGL03_CREATE_BADI_FOR_VALIDATION_ADJUSTM (Document Link - /NGL/NGLM_BADI_FOR_VALID_ADJ )

Create/Change BAdI for Validation Adjustment

Use

If you use validation for document splitting, this BAdI allows you to adjust the degree of validation to your specific requirements.

Requirements

You have fulfilled the prerequisites described in the documentation on how to activate validation for document splitting.

Activities

Implement the method VALIDATION_ADJUST of the BAdI interface.

The method has the following parameters:

� IS_ACCHD: Import Parameter The structure describes the header information of a document to be posted.

� IS_ACCIT: Import Parameter The table describes the lines of a document to be posted.

� CD_VAL_MODE: Modifiable Parameter In this parameter, you can adjust the level of validation. It contains the level of validation determined thus far.

Note: You can override validation by initializing the level setting.

1.1.14. 5. NGL03_CREATE_BADI_FOR_SIMULATE_BASE_ACCO (Document Link - /NGL/NGLM_BADI_SIM_BASE_ACCT )

of 386


Create BAdI for Simulating Base Account Assignments

Use

If account assignment information is not yet available due to the status of a project, you can use this BAdI to simulate account assignments for specific lines. The document splitting characteristics can be defined as a mandatory account assignment for document splitting. The account assignment information in the line items can have different origins.

Requirements

You have met the prerequisites described in the document on validation of document splitting.

Activities

Implement method COMPLETE_ASSGNMT of the BAdI interface.


� IS_ACCHD: Import Parameter The structure describes the header information of a document to be posted together with the information from document splitting.

� IS_ACCHD: Import Parameter The table describes the lines of a document to be posted together with the information from document splitting.

� CT_ACCIT_B: Modifiable Table The lines used as the basis for splitting in rule-based document splitting are transferred in this table. You can only change the document splitting characteristics in these lines.

Note: Specific process-determined account assignments are simulated automatically in document splitting. Account assignments are already simulated in clearing lines, lines of a reversal document, and lines with invoice references.

Example

You activate validation of document splitting for profit centers, but you have not yet made the assignment of cost centers to profit centers in the production system. Since no cost center is assigned, error messages relating to account assignments are issued in the validation of document splitting. You can use this BAdI implementation to simulate the missing derivation and avoid unnecessary log entries.

1.1.14. 6. NGL03_CHECK_VALIDATION_DOC_SPLITTING (Document Link -

/NGL/NGLM_CHECK_VAL_DOCSPLIT )

Check Validation for Document Splitting

of 386


Use

If you chose a migration scenario with document splitting, the program for this activity checks if you have activated the validation at least with level 1 (Only log). You receive a warning message if validation of document splitting is not activated.

1.1.15. NGL00_ADDITIONAL_BADI_IMPLEMENTATION

1.1.15.1. NGL03_CRE_BADI_4_PROC_ACNT_AGNMT_OF_DOCS (Document Link - /NGL/NGL03_CRT_BADI_PRC_ASMT )

Process Account Assignments of Documents

Use

If, in new general ledger accounting, you introduce new account assignment characteristics (such as segments) that do not form part of the documents, you can use a Business Add-In (BAdI) to supplement the account assignment information during runtime. In particular, you can use the BAdI FAGL_MIG_ADJ_ACCIT with the method ADJUST_ACCIT. The documents entered in table BSEG remain unchanged, that is to say, the account assignment is not updated in the document. The enriched account assignment information is added to the document splitting information and applied in building the documents in the general ledger view.

You can use the following inbound parameters:

� Header information of a document in the AC interface (IS_ACCHD) � Line information for a document in the AC interface (IT_ACCIT_EX, enhanced

by document splitting information and by additional ACCIT_EXTENSION information)

� Clearing information at item level (IT_AUSZ_CLR)

Within the BAdI, you can change the account assignment fields of structure CT_ACCIT_ASGMT. To change parts of ACCIT_EXTENSION, set the export parameter EB_ACCIT_EXT_SUPPL. This BAdI enables you to create invoice references subsequently, without writing them to the database. When using this function, ensure that you fill all necessary fields for the invoice reference (REBZG,

REBZJ, and REBZZ).

By changing the invoice reference, you can influence the behavior of document splitting. Document splitting splits up the lines for the following invoice reference types, on the basis of the how the relevant item is split:

� A: Down Payment Clearing � P: Price Reduction � U: Payment for / Down Payment Clearing � U: Invoice Supplement

of 386


You cannot change the account assignments for clearing lines. They are always overwritten by document splitting. Lines changed by the BAdI are no longer split in document splitting.

You may change base account assignments that are relevant for the splitting of items that have to be edited. But you should not change open item line items (XOPVW = 'X') because these items will not longer be split in document splitting.

Example: Vendor invoice

Account Profit Center Segment Amount in EUR

Expense A 001 500 Changed line

Expense B 002 500 Changed line

Tax - 160 Unchanged

Vendor - 1160- Unchanged

1.1.15. 2. NGL03_CREBADI4_CHANGEDOCSPLIT_INFOOF_DOC (Document Link - /NGL/NGL03_CRT_BADI_CHNG_DOC )

Change Document Splitting Information of Documents

Use

The documents that you would like to post to new general ledger accounting using migration may in some cases be split during document splitting in a way that makes little business sense.

This BAdI allows you to specify an alternative splitting result to that produced using the standard process.

You can choose one of the following options for this:

� Line items are split on the basis of a relationship defined in the BAdI (export parameter ET_RELTAB)

� Line items are split on the basis of the lines to be specified in the BAdI (export parameter ET_SPLITITEM)

Requirements

This BAdI is used exclusively for migration with document splitting when the document splitting tables are built for the documents to be posted subsequently.

Activities

of 386


Implement the method SPLIT_ITEMS.


� IS_ACCHD: Import parameter that describes the header information of the interface, enhanced by the document splitting information

� IT_ACCIT: Import parameter that describes the line information of the interface, enhanced by document splitting information

� ET_RELTAB: Export parameter This table describes the relationship used to split a line.The line type of the internal table consists of the following parts:

� The substructure S_POS describes the item to be split. It consists of company code, document number, fiscal year, and the number of the posting item in the accounting document. The fields Company Code, Document Number, and Fiscal Year are only filled in cross-company code documents.

� The substructure FAGL_S_MIG_ASGMT describes the possible account assignments for the distribution. However, the system only transfers fields that are also defined as a document splitting characteristic in document splitting.

Field WRBTR describes an amount that itself describes the relationship of the account assignment records. The total of the amounts do not have to agree with the amount of the item to be split. The amount must not be zero.

Splitting on the basis of the relationship occurs before distribution using the base rows.

� ET_SPLITITEM: Export parameter This table describes which lines are to be split on the basis of other lines. The line type consists of the following parts:

� The substructure S_POS describes the line to be split. It consists of company code, document number, fiscal year, and the number of the posting item in the accounting document. The fields Company Code, Document Number, and Fiscal Year are only filled in cross-company code documents.

� The substructure B_POS describes the lines that form the basis for splitting the line described in S_POS.

When this approach is used, internal dependencies do not apply. If the system identifies a recursion, an error message is issued.

Notes

� You can only use one approach for a given line. � Clearing lines cannot be split using these approaches. � The standard rule-based document splitting no longer processes the split

results. However, you can use the result to split other lines.

Example

of 386


The following document in your system needs to be posted subsequently:

Vendor1 -1000

Vendor2 -2000

Expense PC01 -1200

Expense PC02 800

Expense PC03 1000

In terms of content, Vendor1 and the expenses in lines 3 and 4 belong together, and Vendor2 corresponds to the expense in line 5. Rule-based document splitting cannot recognize this connection and would perform the distribution for vendors on the basis of expense items so that a share in all profit centers results for each vendor. In this way, Vendor1 would be distributed on the basis of expense items 3, 4, and 5.

� First method: Line items are split on the basis of a relationship defined in the BAdI. In table ET_RELTAB, you enter a relation for the distribution to line 1 (Vendor1) and line 2 (Vendor2) for the profit centers.

You fill table ET_RELTAB as follows:

Structure S_POS FAGL_S_MIG_ASGMT

Field BUZEI PRCTR .... WRBTR

01 PC01 120

01 PC02 80

02 PC03 100

� Second method: Line items are split on the basis of the lines to be specified in the BAdI. In table ET_SLITITEM, you describe which lines should be used to distribute Vendor1 (line 1) and Vendor2.

For this purpose, you enter the following in table ET_SPLITITEM:

Structure S_POS B_POS

Field BUZEI BUZEI

01 03

01 04

02 05

of 386


1.1.15. 3. NGL00_CREATE_BADI_FOR_UPLOAD_CARRYFORWRD (Document Link - /NGL/NGLM_UPLOAD_CARRY_FRWD )

BAdI for Uploading Carryforward

Use

With this BAdI, you can control how the fields of the source ledger are transferred to the target ledger when the balance carryforward is uploaded.

To control the transfer, you can use method MOVE_FIELDS. The generated structure GLU1 contains all fields of all possible source and target ledgers. The records are transferred to the method record by record in GLU1 format:

The source record in the importing parameter IS_GLU1_SOURCE.

The changing target record in the changing parameter CS_GLU1_TARGET.

The record CS_GLU1_TARGET has the values of the fields from IS_GLU1_SOURCE with the same name as preassigned values, including the known name inequalities BUKRS/RBUKRS (if the company code field in the source ledger is BUKRS) and PRCTR/RPRCTR (if the profit center field in the source ledger is PRCTR).

You should therefore implement this BAdI particularly if you want to cover additional name inequalities - for example, if you have added a customer field called RZZFIELD1 to the source ledger and want to transfer it to customer field ZZFIELD1 of the target ledger.

The value fields TSL, HSL, KSL, OSL of the target structure CS_GLU1_TARGET already have the correct values (that is, the values corresponding to the currency types of the target ledger).

Prerequisites

The account assignment that you want to allocate to the target structure must be available in your current totals table (e.g. GLT0, GLT3).

Example

The following example illustrates the segment and profit center derivation based on business areas in FI totals records.

method IF_EX_FAGL_UPLOAD_CF~MOVE_FIELDS.

case IS_GLU1_SOURCE-RBUSA.

when '1000

CS_GLU1_TARGET-SEGMENT = 'S001'.

of 386


CS_GLU1_TARGET-PRCTR = 'P001'.

when '2000



when '3000



when others.



endcase.

endmethod.


For the source and target account assignment, you can have a 1:1 relationship or an n:1 relationship. It is not possible to split up a source account assignment into multiple target account assignments.

1.1.16. NGL03_CHECK_MIGRATION_CUSTOMIZING (Document Link - /NGL/NGLM_CHECK_MIG_CUSTMZNG )

Check Migration Customizing

Use

In this activity, the migration plan is checked against the customizing of new General Ledger Accounting:

� The program checks if the migration type of the migration plan fits the document splitting activation status in new General Ledger. You get a warning message if there are company codes with document splitting assigned to a migration plan without document splitting and vice versa.

� Remark: For migration package 6, it is necessary that the document splitting indicator is set at client level and that the relevant company codes are inactive for document splitting. In ERP 6.0 this is set automatically for the first time during activation of the validation of document splitting.

� The program checks if each company code is at least assigned to the migration plan for the leading ledger (not for migration package 7 and 8). You will

of 386


receive a warning message if there are company code and ledger combinations not assigned to at least one migration plan.

� The program checks if there are company codes assigned to the migration plan. � The program checks if the leading ledger is assigned to the migration plan (not

for migration package 7 and 8). If the leading ledger is not assigned to the current migration plan, you will receive a warning message.

� The program checks if non-leading ledgers are assigned to the migration plan. � Additionally, the program checks if clearing reset of cleared items before the

migration date is possible. If yes, you receive a warning message. � The program checks if all relevant accounts have been assigned for source and

target ledgers. 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.

� Based on the assignment of source and target ledger, the program checks if the source and target ledgers use the same fiscal year start date.

� Especially for migration package 4 and 5, at least two target ledgers must have been assigned.

Remark: 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 (not relevant for migration package 7 and 8).

The program for this activity also checks if you implemented the BAdI for document splitting information of open items. If you use a migration scenario with document splitting, the BAdI is required for cases with one or more required document splitting criteria in new G/L. Otherwise you will have no subsequent information in new G/L for clearing of the open items.

Prerequisites

The migration plan has been defined and the company code(s) and ledger(s) have been assigned to the migration plan. The assignment of source and target ledger has been done.

1.1.17. NGL00_CREATE_TRANSPORT_FOR_MGPLN_CUST (Document Link -

/NGL/NGLM_CRT_TRANS_4_MGPLN )

Create Transport for Migration Plan Customizing

Use

With this activity you can create a transport request which includes the migration plan customizing of the current migration package.

The activity execution is independent from the status of the migration plan or migration package. So it is always possible to either create a new transport with the

of 386


current settings or add the current settings to an existing transport.

Example

If you will do the migration customizing in a separate system and need to transport the settings to all other systems (e.g. test system, production system etc.) you can use the current migration plan settings of this package and

1. Include them into a transport 2. Import the transport into another system 3. Create a migration package in the other system 4. Execute activity "Customizing of Package via Transport Request"

With this activity you will be able to use the prior imported migration plan customizing within the newly created package. (Please read also the activity documentation of this step)

Features

The following migration customizing settings will be included in the transport

� Migration Plan

o Automatically included in transport

� Migration Date


� Company Code and Ledger Assignment of the Migration Plan


� Status of Migration Plan (e.g. "Migration Started")


� Activation of Validation of Document Splitting (Migration Plan dependent)

o Only in Release ERP6.0


� Assignment of Source and Target Ledger for Balance Sheet Accounts

o Only included if selected

Prerequisites

The corresponding customizing settings will only be included in the transport if the

of 386


settings already exist in the system (table entries exist).

Example

The status of the migration plan ("Migration Started") will only be included in the transport if the status is already set while executing this activity.


For migration package 7 (Subsequent implementation of a further ledger) and 8 (Subsequent change from account solution to ledger solution):

You have to ensure that the migration plan customizing is transported together with the new G/L customizing of the new ledger. This is necessary because the updates to the new ledger will be controlled by the migration plan and migration date. If there is no migration plan but the new ledger already exists in the system the updates are done without any control of the fiscal year. In case the migration plan with migration date exists the updates into the new ledger will only take place in the fiscal year of activation of the new ledger.

1. 2. NGL00_ANALYZE_PHASE

1. 2.1. NGL00_CHECK_NEWGL_INACTIVE (Document Link - /NGL/NGLM_CHECK_NEWGL_INACTV )

Check if New G/L Is Inactive

Use

The program for this activity checks if the new general ledger is inactive in the current client. The new general ledger can be activated only after successful migration of all company codes within the client.

The migration takes place into initial new general ledger tables. These tables are created during the migration process. A merge with existing data during the migration is not possible. Note that data must be reconciled after migration and before activation of new general ledger accounting.


After upgrading to mySAP ERP, the classic general ledger is still the appropriate application before the migration to new general ledger accounting takes place.

Important Note

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.

of 386


1. 2. 2. NGL03_CHECK_SPLIT_CHARACTERISTICS (Document Link -

/NGL/NGLM_CHK_SPLIT_CHARCTER )

Check Document Splitting Characteristics and Scenarios

Use

In this activity, the migration plan is checked against the customizing of for new General Ledger Accounting:

� The program checks if document splitting characteristics are defined in new G/L customizing.

� Based on the document splitting fields, the relevant new G/L scenarios are determined. First, the program checks if the found scenarios are assigned to the leading ledger. If this is not the case, you get a warning message. Second, the program checks if the scenarios are assigned to non-leading ledgers. For scenarios that are not assigned to any ledger, you get an error message.

� The program checks if the relevant ledgers for document splitting are assigned to the current migration plan or any other migration plan.

� Additionally, the system checks if the document splitting fields are included in the new G/L totals table. For the fields that are not included in the totals table, you get a warning message.

1. 2. 3. NGL00_CHECK_ORGANIZATIONAL_STRUCTURES

1. 2. 3.1. NGL00_CHECK_COMPANY (Document Link - /NGL/NGLM_CHECK_COMPANY )

Check Company

Use

The program for this activity checks if the company setup fits the scenario Preparations for Consolidation for new general ledger accounting:

� If you use the scenario Preparations for Consolidation for new general ledger accounting, the program checks if there are companies defined in the enterprise structure. If this is the case, the company code assignment and master data for customer, vendor, and G/L accounts are also checked.

� If you defined companies, but do not use the scenario Preparations for Consolidation for new general ledger accounting, you will receive a warning message.

Prerequisites

Make sure that all relevant company codes are assigned to the migration plan.

of 386


1. 2. 3. 2. NGL00_CHECK_COMPANY_CODE_PARAMETERS (Document Link -

/NGL/NGLM_CHECK_CCODE_PARAMS )

Check Company Codes

Use

The program for this activity checks if all company codes that are assigned to a migration plan have a valid fiscal year variant assigned. Furthermore it is checked if totals exist for the current and previous fiscal year for the company codes of the current migration plan.

Prerequisites

Make sure that all active company codes are assigned to the migration plan.

Note that SAP standard company codes that you do not use in your live system might be available in customizing but do not have to be considered here.

If there are company codes that are not used actively, but have data, you have to decide if these company codes must be migrated to new General Ledger or if these company codes are no longer valid for any posting and thus will stay in the classic General Ledger tables only. To reactivate an inactive company code you have to perform the migration for this company code as well before any other posting related to that company code takes place.

1. 2. 3. 3. NGL00_CHECK_FUNCTIONAL_AREA (Document Link - /NGL/NGLM_CHECK_FUNC_AREA )

Check Functional Areas

Use

The program for this activity checks for the following:

� If you use the scenario Cost of Sales Accounting for new general ledger accounting, functional areas must exist. Additionally the status of Cost of Sales Accounting must be 'active' or at least 'in preparation'.

� If the Cost of Sales Accounting scenario is not active, but functional areas exist or cost of sales accounting is active, you will receive a warning message.

� You will get information about the new features for determination of functional areas. Additionally, the active substitution call-up points for derivation of functional areas are checked.

Remark: The substitution rules themselves or even user exits are not checked!

of 386


Prerequisites

Make sure that all active company codes are assigned to the migration plan.

1. 2. 3. 4. NGL00_CHECK_CONTROLLING_AREA (Document Link - /NGL/NGLM_CHECK_CNTRLNG_AREA )

Check Controlling Areas

Use

The program for this activity checks if all company codes assigned to a controlling area use the same fiscal year variant in accordance with the SAP standard. In some cases, there might be a modification as described in SAP Note 107211.

If Profit Center Accounting (EC-PCA) is activated in the controlling areas, the program checks if the scenario Profit Center Update is activated for the leading ledger in new general ledger accounting in your system. If you have different fiscal year variant names in FI and CO, the program checks if the start dates and end dates of the fiscal year for FI and CO coincide.

If reconciliation ledger is active, the program checks if you have assigned a CO-FI real-time integration variant to the company code. If cross-profit center postings are activated, you get a warning message because the CO postings in phase 1 have to be posted retrospectively to FI.

Integration

If you did not activate the profit center update and thus do not intend to use Profit Center Accounting in new general ledger accounting, consider the restrictions described in SAP Note 826357.

Prerequisites

Make sure that all relevant company codes are assigned to the appropriate controlling area.

1. 2. 3. 5. NGL00_CHECK_BUSINESS_AREAS (Document Link - /NGL/NGLM_CHECK_BUSINES_AREA )

Check Business Areas

Use

Business areas can be used in different ways in the classic general ledger

of 386


accounting. If you currently use business areas, the system checks for scenario Business Area in customizing for new general ledger accounting. Note that for a complete balance sheet on business area level, the document splitting for business areas is needed (requires migration package 3 or 5).

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.

1. 2. 3. 6. NGL00_CHECK_CONSOLIDATION (Document Link -

/NGL/NGLM_CHECK_CONSOLID )

Check Consolidation

Use

The pogram for this activity checks the consolidation integration.

There are the following checks:

� You use the integration with EC-CS for � Company consolidation

The scenario Preparations for Consolidation (FIN_CONS) must be active for at least one ledger in new general ledger accounting. If it is not active for the leading ledger, you will get a warning message.

� Business area consolidation: The scenario Business Area (FIN_GSBER) must be active for at least one ledger in new general ledger accounting. If it is not active for the leading ledger, you will get a warning message.

� Profit center consolidation The scenario Profit Center Update (FIN_PCA) must be active for at least one ledger in new general ledger accounting. If it is not active for the leading ledger, you will get a warning message.

� You use the integration with classic FI-LC for � Company consolidation

The scenario Preparations for Consolidation (FIN_CONS) must be active for at least one ledger in new general ledger accounting. If it is not active for the leading ledger you will get a warning

of 386


message. � Business area consolidation

The scenario Business Area (FIN_GSBER) must be active for at least one ledger in new general ledger accounting. If it is not active for the leading ledger you will get a warning message.

Important note: Consider also the information provided in SAP Note 918675.

Integration with EC-CS

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 if the relevant fields in new general ledger accounting use the same data elements as in the profit center totals table GLPCT.

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 setup, 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.

More information referring to the integration SEM-BCS and new general ledger accounting is provided in SAP Note 852971.

1. 2. 3. 7. NGL00_CHECK_SEGMENTATION (Document Link - /NGL/NGLM_CHECK_SEGMENTATION )

Check Segmentation

Use

The program for this activity checks the customizing in new G/L for

of 386


segmentation:

� If you defined segments in the customizing IMG Enterprise Structure -> Definition -> Financial Accounting -> Define Segment, the program checks if the new G/L scenario Segmentation is assigned for at least one ledger. Otherwise, you get a warning message.

� If you assigned the new G/L scenario Segmentation, the program checks if segments exist in the related customizing table as before. If no segments are defined, you get an error message. In this case, you have to create the segments first before proceeding with the migration.

� If you use the new G/L scenario Segmentation, the program also checks if you activated the profit center update. In SAP standard, the segment is derived from the profit center. If you do not intend to use new G/L profit center update, you get a warning message.

� If the scenario Profit Center Update is active, the program also checks if document splitting for profit center or segment is active.

SAP recommends activating Profit Center Accounting in combination with segments. Otherwise you should not activate document splitting for profit centers and for segments (according to SAP Note 826357).

Only for migration packages with document splitting:

Note that segments are correctly assigned to open items from previous fiscal years (migration phase 0) during the migration by means of a BAdI for document splitting information of open items (Setup phase -> Create/Change BAdI for document split information open items).

You may also derive the account assignment for documents in the fiscal year of the migration during the migration using a BAdI. You will find this BAdI in the Setup phase -> Additional BAdI implementation -> Create BAdI for process account assignments of documents.

You can add the segment information in the balance carryforward by using a BAdI for uploading the carryforward. You will find this BAdI in the Setup

phase -> Additional BAdI implementation -> Create BAdI for upload carry forward.

Prerequisites

The customizing of new G/L and document splitting is finished and transported to the current system.

Important Note for package 6:

Make sure that the relevant transport to the current test or productive system does not contain an activation of document splitting at company code level. Document splitting for company codes must not be activated until the migration has been completed successfully.

of 386


1. 2. 3. 8. NGL00_CHECK_PROFIT_CENTER (Document Link -

/NGL/NGLM_CHECK_PROFIT_CENTR )

Check Profit Center

Use

The program for this activity checks the customizing in new general ledger accounting for profit center update:

� 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 non-leading ledger, the program also checks if the company code is assigned to that ledger.

� If you assigned the scenario Profit center update, the program checks if any master data exists. If no profit center master data has been defined, you will get an error message. In this case, you should create the profit center first before proceeding the migration.

Only for document split (Package 3 or 5)

Note that profit centers are correctly assigned to open items from previous fiscal years (migration phase 0) during the migration by means of the BAdI for document split information of open items. (Setup phase -> Additional BAdI

implementation -> Create BAdI for process account assignments of documents.)

Profit center account assignments for documents in the fiscal year of the migration can also be derived during the migration by means of a BAdI. You will find this BAdI in the Setup phase Additional BAdI implementation --> Create BAdI for process account assignments of documents.

You can add the segment information in the balance carry-forward by using a BAdI for uploading the carry-forward. You will find this BAdI in the Setup phase -> Additional BAdI implementation -> Create BAdI for upload carry

forward.

Prerequisites

The customizing for new general ledger accounting is finished and transported to the current system.

1. 2. 3. 9. NGL00_CHECK_ASGMNT_PRO-CENTER_AND_SEGMNT (Document Link - /NGL/NGLM_CHCK_ASMT_PRFT_SGT )

of 386


Check Assignments of Segments to Profit Centers

Use

If you use the scenarios Segmentation (FIN_SEGM) and Profit center update

(FIN_PCA) in new general ledger accounting, the program for this activity checks if segment information is available in all profit center master records. If the program finds missing assignments, you will receive a warning message. The program also checks if you use the segment as required field for document splitting. If so, you will get an error message if any assignments are missing and if the BAdI implementation for BAdI FAGL_DERIVE_SEGMENT is missing.

Prerequisites

The customizing for new general ledger accounting is finished and transported to the current system. The profit center master data has been created completely.

Dependencies

Note that you cannot change the segment assignment to profit center using transaction KE52 if transaction data exists for the profit center (SAP Note 940721).

Activities

If applicable, fill in the segment in all profit center master data records.

1. 2. 4. NGL00_CONFIRM_PROFITCENTER_ASSIGNMENT (Document Link - /NGL/NGLM_CHECK_PRFT_CNT_ASG )

Confirm Profit Center Assignment

Definition

The profit center is assigned to various data objects, such as cost center, internal order, or material master. The assignment of profit centers to the appropriate data objects must be finalized before the migration takes place. After the migration, the assignment cannot be changed if you create a profit center or segment balance sheet. You will find a list of assignments in customizing under Financial Accounting (New) -> General Ledger Accounting (New) -> Master data -> Profit Center -> Assignments of Account Assignment

Objects to Profit Centers.

If you do not use the Profit Center Accounting in new general ledger accounting, you can simply confirm this activity without further action.

of 386


Dependencies

Note that the assignment of profit centers to account assignment objects cannot be changed once the account assignment object holds transaction data.

1. 2. 5. NGL00_CHECK_CURRENCIES_AND_LEDGERS

1. 2. 5.1. NGL00_CHECK_CURRENCIES (Document Link - /NGL/NGLM_CHECK_CURRENCIES )

Check Currencies

Use

The program for this activity checks the currency settings if you use parallel currencies in FI.

If you use a second and third local currency in FI, the program checks if you use another currency within classic EC-PCA, FI-SL, or classic consolidation preparation in GLT3. In new general ledger accounting, it is possible to assign a second and third local currency to the leading ledger. If you have more currencies for the mentioned components than the three local currencies that are available for the company code, this cannot be reflected in new general ledger accounting.

1. 2. 5. 2. NGL00_CHECK_SOURCE_LEDGERS (Document Link - /NGL/NGLM_CHECK_SOURCE_LDGRS )

Check Source Ledgers

Use

The program for this activity makes the following checks:

� For all company codes with transaction data in FI-GL (table GLT0), the program checks if these company codes are assigned to a migration plan for the leading ledger.

� If GLFUNCT contains data, the program checks if the scenario Cost of Sales Accounting (FIN_UKV) is active for the leading ledger or for non-leading ledgers in new general ledger accounting.

� If you use GLT3 or GLT1 with trading partner or movement type information, the program checks if the scenario Preparations for Consolidation (FIN_CONS) is active for the leading ledger or for non-leading ledgers in new general ledger accounting.

� If you use GLT1 with cost center information, the scenario Cost Center Update (FIN_CCA) in new general ledger accounting is checked.

of 386


� If EC-PCA is active or data exists in GLPCT, the program checks if the scenario Profit Center Accounting (FIN_PCA) is active for the leading ledger or for non-leading ledgers in new general ledger accounting. Additionally, it checks for document splitting for profit centers.

1. 2. 6. NGL00_CHECK_DOCUMENTS

1. 2. 6.1. NGL03_CHECK_DOCUMENTS_AND_LINE_ITEMS (Document Link

- /NGL/NGLM_CHCK_DOC_LINE_ITMS )

Check Documents and Line Items

Use

The FI documents for the fiscal year of the migration are subsequently posted to the new G/L. It is not possible to transfer FI archives to the new G/L. This is why the program for this activity checks if there are archive runs for FI_DOCUMNT after the migration date in the current system.

Only for migration packages 1 - 5 : In addition, the program checks if all clearing documents (clearing date equal or higher than migration date) in phase 1 are updated to the table BSE_CLR, which is needed for technical purposes. As BSE_CLR was not updated in SAP releases lower than 4.5, it could happen that entries in BSE_CLR are missing if the technical upgrade took place in phase 1.

Activities

If you run archiving for FI_DOCUMNT, you will get an error message. In that case, you have to check if FI documents have been deleted and, if so, create a message for component FI-GL-MIG. Otherwise you can set the status of this activity to green.

Note that restore programs for FI_DOCUMNT have been deleted from SAP standard with support package SAPKH50007 (SAP Note 877439).


For building-up the new ledger it is also necessary that all documents in phase 1 are available. Furthermore several documents, for instance periodic postings from FI-AA, have to be reversed during the migration process.

1. 2. 6. 2. NGL00_CHECK_CROSS-COMPANY_DOCUMENTS (Document Link - /NGL/NGLM_CHCK_CROS_COMP_DOC )

Check Cross-Company Documents

of 386


Use

The program for this activity checks if you use cross-company postings in FI. To this purpose, the customizing settings (IMG Financial

Accounting -> General Ledger Accounting -> Business transactions -> Prepare Cross-Company Code Transactions) are read for the relevant company codes within a migration plan. The program checks if the related company codes have the same fiscal year start and end date. If the fiscal year start differs, the program also checks if FI cross-company documents exist in the fiscal year of the migration (migration phase 1). If so, you will receive an error message. If this is the case, contact SAP by creating a message for component FI-GL-MIG.

Related company codes with same fiscal year definition must be assigned to the same migration plan if cross-company documents exist in phase 1.

Only relevant for migration package 3 , 5 and 6

For all combinations in customizing of cross-company code transactions, the program checks if the relevant company codes use document splitting. It is not allowed to deactivate the document split partly for individual company codes. If this is the case in your project, you will receive an error message.

Prerequisites

All relevant company codes and ledgers are assigned to the migration plan.

1. 2. 6. 3. NGL00_ZERO_CLEARING_CHECK (Document Link - /NGL/NGLM_CHECK_BSTAT_A )

Use

The program for this activity checks if there are clearing documents without line items in the system for phase 1 of the migration. Clearing documents without line items only have an entry in table BKPF with status BSTAT = 'A'. There are no line items in BSEG for these documents. Since the migration with document splitting cannot process these documents correctly, implement SAP Note 1054674 to ensure that no such documents are created in phase 1. To this purpose, you must transport the migration plan into your production system.

If clearing documents without line items in phase 1 already exist, you must reverse (reset clearing) and repost these documents. A report you can use for this purpose is provided in the migration cockpit.

of 386


1. 2. 6. 4. NGL03_CHECK_PAYMENT_REQ_FOR_PRE_POSTINGS (Document Link - /NGL/NGLM_CHECK_REF_DOCS )

Check Reference Documents

Use

For the migration of documents in phase 1, the program for this activity checks if there are actual FI documents that refer to preliminary postings or noted items. This may occur in case of advance payments for preliminary documents.

Dependencies

If document references are found, you must post these documents during the next phase.

1. 2. 7. NGL03_CHECK_DOCUMENT_SPLITTING

1. 2. 7.1. NGL03_CHECK_VALIDATION_DOC_SPLITTING (Document Link - /NGL/NGLM_CHECK_VAL_DOCSPLIT )

Check Validation for Document Splitting

Use

If you chose a migration scenario with document splitting, the program for this activity checks if you have activated the validation at least with level 1 (Only log). You receive a warning message if validation of document splitting is not activated.

1. 2. 7. 2. NGL03_CHECK_GLACCOUNTS_FOR_DOC_SPLITTING (Document Link - /NGL/NGL03_CHK_G/L_4_DOCSPLT )

Check General Ledger Accounts for Document Splitting

Use

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 (see also in Customizing under Financial Accounting -> General Ledger Accounting

-> Business Transactions -> Document Splitting -> Classify G/L Accounts for Document Splitting).

of 386


Features

The proposal is compared against the classification of general ledger accounts for document splitting. If needed, you can also restrict the selection to individual company codes and general ledger accounts.

� @08@ Proposal fits classification � @09@ Proposal differs from classification � @0A@ Classification is missing

The system displays the output data as an interactive list. You can execute the following functions for an item in the list:

� Double-clicking a general ledger account: allows you to edit the general ledger account master data

� Double-clicking an item category: takes you to the classification of general ledger accounts for document splitting

1. 2. 7. 3. NGL03_CHECK_DOC_TYPES_FOR_DOC_SPLITTING (Document Link - /NGL/NGL03_CHK_DOCTY_4_DOCSP )

Check Document Types for Document Splitting

Use

This program checks the classification of the document types for document splitting.

Prerequisites

You have defined the classification of document types for document splitting (IMG Financial Accounting (New) -> General

Ledger Accounting (New) -> Business Transactions -> Document Splitting -> Classify Document Types for Document Splitting).

Features

The program counts the number of accounting documents before and after the migration date for all company codes in the migration plan. For 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.

The system displays the output data as an interactive list. You can navigate to the function with which you define the business transaction variant for a selected item in the list. A dialog box appears in which the permitted item categories and indicators are displayed. The dialog box also tells you whether the item category

of 386


for this business transaction variant is mandatory or just defined once.

1. 2. 7. 4. NGL03_CHECK_BUSI_TRANS_ASSGMNT_FOR_DOCS (Document Link - /NGL/NGL03_CHK_BUSI_TRAN_ASG )

Check Business Transaction Assignment for Documents

Purpose

The program checks whether each of the selected documents posted in migration phase 1 applies the rules stored in the business transaction variant assigned to that document.

Prerequisites

The customizing for document splitting in new general ledger accounting has been created.

Features

The program checks the selected document types to determine whether the documents posted since the migration date fulfill the definition of the assigned business transaction variant. You check the assignment of the business transactions to document types in activity Check Document Types for Document Splitting.

If you have already assigned a document-specific business transaction and activated it in customizing for the migration, this assignment is applied for the check. For all other documents, the system derives the business transaction from the document type used.

Documents that do not fit the assigned business transaction variant are listed as containing errors. You can use the Save Docs Containing Errors indicator to include these documents with the checked business transaction variant and status Inactive in the table for alternative business transaction assignments. Here, you can assign to these documents a suitable business transaction variant for use in migration.

If required, you can specify a posting period or document number for which you want the system to display the documents to be checked.

1. 2. 7. 5. NGL03_LIST_LOG_FOR_VALIDATION (Document Link - /NGL/NGLM_LIST_LOG_FOR_VALID )

of 386


List Log for Validation of Document Splitting

Use

In this activity, you can analyze the log entries for validation.You can delete any entries that are no longer required from the log. However note that deleted log entries cannot be recreated.

Requirements

You have activated the validation.

1. 2. 7. 6. NGL03_ALTERNATI_SETTINGS_4_DOC_SPLITTING

1. 2. 7. 6.1. NGL03_DEF_ALTERNATIVE_DOC_SPLIT_METHOD (Document Link - /NGL/NGL03_DEF_ALT_SPLT_METH )

Define Alternative Document Splitting Method

Use

In this activity, you enter a separate document splitting method that is to be used exclusively for the migration of documents that have already been posted.

Requirements

� In the customizing for document splitting in new general ledger accounting, you have defined the alternative method in the activity Define Document Splitting Method.

To prevent inconsistencies between the migrated documents and the documents posted after activating new general ledger accounting, you need to copy the standard method (stored under Assign Document Splitting Method and make adjustments accordingly.

� In the alternative document splitting method for the migration, all Document Splitting Rules used for the migration must be defined completely. To this purpose, copy all the document splitting rules of the document splitting method stored as standard to the alternative document splitting method for the migration, and then make the migration-specific changes to the document splitting rules.

� If necessary, you can define more business transaction variants. You can then define alternative rules for these business transaction variants or change the assignment to the item category (see also the activity Define alternative

of 386


business transaction assignment in the migration cockpit).

Activities

Specify the alternative document splitting method for the migration.

Note that this method is only used for the documents to be migrated. The alternative document splitting method is not applied to documents posted after the migration!

Example

Customer invoices in the current year need to be handled with an alternative document splitting rule.

The standard method cannot split this document in a way that makes business sense because the document contains posting items with item category Balance Sheet Account (01000).

To define an alternative document splitting method, you copy the document splitting rules from the standard method and change the rules to meet your requirements. In this example, you add a new rule for the business transaction variant Customer Invoices that splits item category 01000 on the basis of the revenue item.

In this way, the change takes effect for migration documents, but it is not applied to new documents to be posted after new general ledger accounting has been activated.

1. 2. 7. 6. 2. NGL03_DEF_ALTERNATIVE_BUSI_TRANSACTION (Document Link - /NGL/NGL03_DEF_ALT_BUSI_TRAN )

Define Alternative Business Transaction Assignment

Use

In this activity, you can assign an alternative business transaction variant to selected documents. In the migration, this assignment overrides the standard derivation of the business transaction variant, such as derivation from the document type.

Prerequisites

Either you have assigned a document splitting method in customizing for document splitting, or you have specified an alternative document splitting method in the related activity.

of 386


Note: Here you only assign existing business transaction variants. You may also need to define a document splitting method for the migration only.

Activities

For documents that cannot be migrated using the business transaction variant derived by the standard method, assign an alternative business transaction variant.

For cross-company code documents, single documents from other company codes are automatically assigned to the same business transaction variant. For this reason, the internal key of the entire document is displayed in the fields Reference Key and Reference Transaction. You cannot assign different business transaction variants to documents with the same reference fields. Check your assignments and how they are derived by saving your settings.

For the migration of the documents contained in the table, the business transaction variant assigned explicitly is used instead of the business transaction variant derived from the document type or transaction used to interpret the document. This is logged in the status management of the migration objects in the Adjustment field. You can display the status management in the migration cockpit under Migration phase -> Evaluation -> Analyze

Migration Status and in the -> log for document adjustment.

Example

You have entered a customer invoice with document type DZ. In customizing for document splitting, however, document type DZ has the business transaction Payment assigned in a variant that requires a bank account line in the document.

Migration of the invoice is rejected with the error message that the document does not contain the required bank account line.

You assign business transaction Customer Invoice with an appropriate business transaction variant to the document in this activity and then repeat the migration for this document.

Document splitting now interprets the document as a customer invoice and no longer applies the business transaction Payment to this document.

1. 2. 7. 6. 3. NGL03_DEF_ALTERNATIVE_ITEM_CATG_ASSGNMT (Document Link - /NGL/NGL03_DEF_ALT_ITEM_CATG )

of 386


Define Alternative Item Category Assignment

Use

In this activity, you assign an alternative Item category to the posting item of a document. During migration, this assignment overrides the standard item category assignment for document splitting.

Prerequisites

Either you have Assigned a document splitting method in customizing for document splitting, or you have entered a migration-specific document splitting method in the related migration cockpit activity.

Activities

Assign the item category to the line items that cannot be classified uniquely or correctly for document splitting.

When the line items in the table are migrated, the item category that has been assigned explicitly is used (instead of the item category derived internally or from the G/L account) to interpret the line item. This is logged in the status management of the migration objects in the Adjustment field. You can display the status management in the migration cockpit under Migration phase -> Evaluation -> Analyze Migration Status and in the -> log for

document adjustment.

Example

You have posted items with different types, such as bank clearing and other accruals. These items should be handled differently in document splitting.

You have classified the G/L account in customizing for document splitting using the item category that is applied most frequently. Here, however, you assign this alternative item category explicitly to the items that are to be interpreted using an alternative item category.

Document splitting then applies these explicitly assigned alternative item categories during the migration.

1. 2. 7. 6. 4. NGL03_ALTERNATIVE_CLEARING_RELATIONSHIP (Document Link - /NGL/NGL03_DEF_ALT_CLRNG_REL )

of 386


Alternative Clearing Relationship

Use

You can influence the behavior of document splitting by changing the clearing relationship of a clearing line. This is necessary in the following cases:

� If you have created the clearing relationships of documents subsequently

� If the clearing relationships of documents are incomplete � If the clearing process is to be excluded from document

splitting

The document splitting programs always process clearings and expect to find document splitting information for the items to be cleared. If the document splitting information is missing or incomplete, the document cannot be posted subsequently.

Prerequisites

In the customizing for document splitting, you can assign a document splitting method or an alternative document splitting method specific to the migration cockpit activity above.

Activities

The change of the clearing relationship is not part of the standard migration procedure. If you need to change the clearing relationship, create a message under component XX-RC-FI-MIG.

If you want to influence clearing lines, please note the following:

� You change a clearing relationship for a document line by entering the corresponding data in the fields of the document line to be processed.

� In the following fields, you assign the document line to be cleared by entering the corresponding data for the cleared item.

� You assign one of the following actions to the line: � Add

If you want to add the clearing relationship, select the action Add. If you want to represent multiple clearing relationships with the same clearing line, give the entries a unique number (which can be a randomly chosen number) in field Seq. No. Clearing.

� Ignore Individual Clearing Relationships If you want to delete the clearing relationship, select the action Ignore Individual Clearing Relationships. If you want to delete multiple clearing relationships with

of 386


the same clearing line, give the entries a unique number (which can be a randomly chosen number) in field Seq. No. Clearing.

� Ignore Entire Clearing If you want to delete all clearing relationships, select the action Ignore Entire Clearing. In this way, all clearing relationships for this clearing item are not used internally and no clearing is processed in document splitting. The fields of the cleared item are

not used.

Ensure that the account and the amounts in the clearing relationships agree.

If you create additional clearing relationships for document lines that were posted before the migration date, you need to ensure that the assigned cleared items are already in the work list of open items to be migrated or that they are included explicitly in that work list.

In the migration of document line items contained in the table, the explicitly assigned clearing relationship is used in addition to the clearing relationships represented in posting table BSE_CLR to build the document splitting information, or any such clearing relationship is ignored. This is logged in the status management of the migration objects in the Adjustment field. You can display the status management in the process tree under Migration phase -> Evaluation -> Analyze Migration Status and in the -> log for

document adjustment.

1. 2. 8. NGL00_CHECK_FOR_SAPNOTES (Document Link - /NGL/NGLM_CHECK_FOR_SAPNOTES )

Check Implementation of SAP Notes

Use

For the technical migration process it might be necessary to implement some SAP notes into the SAP system. This activity checks if the system has the needed technical prerequisites.

The activity does not check if application relevant SAP notes are installed.

Prerequisites

The program can only check the implementation of a note if the implementation was done via the standard procedure (transaction

of 386


SNOTE).

Activities

Execute the activity.

You will receive a list of SAP notes. A status will indicate if the SAP note is installed or not. If the program could not determine the correct implementation you will have two options to proceed.

1. Check the implementation manually. If the SAP note is already implemented, change the status of the note manually to yellow.

2. Implement the required SAP note with help of transaction SNOTE. Execute the check again.

1. 2. 9. NGL00_CONF_RPLCMNT_OF_MOD_OR_ENHNCMNT (Document Link - /NGL/NGLM_CONF_RPL_MOD_ENHMT )

Confirm Replacement of Modifications and Enhancements

Use

If you use modifications or enhancements that could affect the migration and are no longer applicable for the new general ledger accounting, confirm that these have been replaced by SAP standard or deactivated.

1. 3. NGL00_PRE-MIGRATION_PHASE

1. 3.1. NGL00_CONF_RECON_AND_CLOS_OF_PREV_FIYEAR (Document Link - /NGL/NGLM_CONF_RECON_CLOSEFY )

Confirm Reconciliation and Closing of Previous Fiscal Year

Use

A basic requirement for the migration is that the previous fiscal year is definitely closed and must not be re-opened under any circumstances.

The reason why re-opening the previous fiscal year is forbidden is that, if you did so, the balance carry-forward would be changed and become incorrect.

of 386


It is not possible to re-run the normal FI balance carry-forward to update the balance carry-forward in new general ledger accounting. The migration is a one-time activity where it is not possible to repeat the balance carry-forward program in order to refresh the figures.

Activities

� Close posting periods in FI � Close posting periods in FI-SL � Close periods in CO � Close previous fiscal year in Asset Accounting (FI-

AA) � Close previous fiscal year in other SAP components

like Material Management, Sales and Distribution, and so on

Prerequisites

The previous fiscal year has been closed and audited by your auditor.

Consider also that all sending applications to FI must not be opened again for back-dated postings. Otherwise the corresponding FI documents for previous years can not be processed.



You are able to start updating the new ledger(s) at beginning of the fiscal year. Therefore the customizing of the new ledger(s) as well as the migration plan must be imported into your production system. At this point in time you post into the new ledger and the previous fiscal year is still open. In the meantime there is no complete reporting on the new ledger(s) possible. Once you have closed the previous year you can takeover the balance carry forward and open items into the new ledger(s) and completely use these ledger(s).

1. 3. 2. NGL00_REGISTER_USERS (Document Link - /NGL/NGLM_REGISTER_USERS )

Register SAP Users for Migration Project

Use

of 386


In this activity, you register the SAP users for the migration project. These users are authorized to access the system during the following migration timeframe. All other users that were not registered here will be locked for logon in the next step (not for migration package 7 and 8).

Make sure to register users for representatives of the relevant business departments as well as technical users and IT users for performing the technical activities.

Before you register and lock users, inform all users in your organization that the SAP system will not be available for a certain period of time due to the migration.



In contrast to other migration packages the users are not blocked in migration package 7 and 8. You have to make sure that all existing documents are posted into the new ledger(s) subsequently until all documents are posted. In this manner you do not have any downtime for creating the new ledger(s).

1. 3. 3. NGL00_LOCK_SAP_USERS (Document Link - /NGL/NGLM_LOCK_USERS )

Lock SAP Users

Use

In this activity, all SAP users that have not been registered in the activity before are locked. This is necessary to ensure that no unauthorized user activities that might endanger data consistency take place during the migration.

Before you register and lock users, inform all users in your organization that the SAP system will not be available for a certain period of time due to the migration.

1. 3. 4. NGL00_DATA_BACKUP_BEFORE_MIGRATION (Document Link - /NGL/NGLM_DATA_BACKUP_BEFORE )

Data Backup Before Migration

of 386


Use

Before you start the migration, you need to create a full data backup. This data backup is needed for rebuilding the system if irreparable errors occur during the migration.

Activities

Contact your system or database administrator.

1. 3. 5. NGL00_DATABASE_ACTIVITIES (Document Link - /NGL/NGLM_DBASE_ACTIVITIES )

Database and System Activities

Use

Before the migration starts, it is necessary to back up the SAP system in order to ensure the data integrity in the event of errors. We recommend you use a classic, full data backup.

Additionally you should deactivate database logging by using the appropriate system parameters for performance reasons. The detailed activities concerning your database need to be decided by your system administrator. Please note that in case of deactivated database logging a point-in-time-recovery is not possible.

Consider also related activities like

� Cancellation of periodic and occasional jobs � Stopping connections for RFC, EDI, ALE, and so on � System operation mode (work processes for

background, update, and so on)

Activities

Please contact your system or database administrator.

Prerequisites

Before you proceed with database and system activities, please make sure that all users who are not registered for the migration are logged off. The functions for registration and locking users do not log off the users automatically.

of 386


1. 3. 6. NGL03_REVERSE_BALANCE_SHEET_ADJUSTMENT (Document Link - /NGL/NGL03_REV_BALSHEET_ADJS )

Reverse Balance Sheet Adjustment

Use

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 the following.

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.

We recommend 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.

During the time interval after you performed the report for the last time and before you start the migration, you must not perform any clearing.

Example

You have previously posted a vendor invoice as follows:

of 386


Vendor Invoice

Account Business Area Amount in EUR

Expense 0001 500

Expense 0002 500

Tax - 160

Vendor - 1160-

Adjustment Posting


Tax adjustment 0001 80

Tax adjustment - 80-



Adjustment posted - 580

Adjustment posted 0001 580-



After the migration (with document splitting), the General Ledger view looks as follows:

a) Original document


Payables 0001 580-

Payables 0002 580-

Expense 0001 500

Expense 0002 500

Tax 0001 80

Tax 0002 80

b) Adjustment document

of 386











Clearing account 0001 580

Clearing account - 580-

Clearing account 0002 580


Clearing account - 80

Clearing account 0001 80-


Clearing account 0002 80-

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

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

Financial Statement for Business Area 0001

Business Area Amount in EUR

Payables 0001 1160-

Clearing 0001 580

Expense 0001 500

Tax 0001 160

of 386


Clearing 0001 80-

The correct financial statement for business area 0001 would look as follows:


Payables 0001 580-

Expense 0001 500

Tax 0001 80

1. 3. 7. NGL03_REVERSE_P/L_ADJUSTMENT (Document Link -

/NGL/NGL05_REVERSE_PL_ADJUST )

Handling of SAPF181 Documents in the Context of new G/L Migration With Document Splitting

Unlike the SAPF180 documents for splitting of balance sheet accounts by business areas, the documents created by report SAPF181 (profit and loss adjustment) should not be reversed during a general ledger migration. In the classic general ledger, this report covers several areas:

1. Splitting of cash discount paid and cash discount received (or lost cash discount and exchange rate differences respectively) by business areas and profit centers

2. Subsequent activation of cash discount paid and cash discount received (or lost cash discount respectively) for fixed assets

3. If the accounts for cash discounts or exchange rate differences were created as cost elements, the report also makes an adjustment to cost centers

4. Splitting of backdated tax calculation due to deducted cash discount

In new G/L, the functions described above are implemented directly during the original posting of a document using the document splitting function. For postings during phase 1 of the migration, not all information that is required to completely replace the SAPF181 documents is available in the original documents. The reason for this is that in new G/L the adjustment for CO account assignments and fixed assets does not take place in the general ledger view, but in the entry view for a document (see example 3). During the migration to new G/L, only the general ledger views are rebuilt by subsequent processing of document splitting,

of 386


whereas the entry screen for already posted documents remains unchanged (see examples 1 and 2). This is why the SAPF181 documents from phase 1 must be migrated.

Procedure for the Migration:

If the accounts for cash discounts or exchange rate differences were created as cost elements, all these lines should have a default account assignment (profit center / business area), for example from the cost center. If these lines do not contain all account assignments that are relevant for document splitting, for example because not all accounts were created as cost elements or because a new account assignment is introduced, you should add the missing default account assignments in the documents using BAdI FAGL_MIG_ADJ_ACCIT. This description also includes sample programming for the BadI (see below). The example given below assumes that the SAPF181 documents were posted with document type "SU" and that document splitting by profit centers and by business areas is used.

As you can see in examples 1 and 2 below, there are two possible ways of splitting the tax line from the backdated tax calculation. With variant 1, splitting of the tax line is based on the cash discount line in the payment and consequently gets the default account assignment during the migration. In this case, the splitting takes place based on the default splitting method (0000000012 - splitting: like 0000000002 (follow-up costs online)) and the business transaction (variant) 1000/0001 for payment documents. As you can see in the example, the drawback of this method is that the balance sheet for the business area for phase 1 does not have a zero balance and that you must adapt the balance of the tax account for each account assignment using transaction FB41 after the migration.

With variant 2, a customer-specific modification of document splitting for business transaction variant 1000 is required for payments. You can define an alternative splitting method for the migration in the migration customizing. In this alternative splitting method, you can make the required customer-specific modifications. To do so, copy the complete splitting method you want to use for document splitting (normally, this will be approach 0000000012) to the customer namespace and define the new splitting method as a deviating method in migration customizing. After that, you define the basis positions 02000 (customer) and 03000 (vendor) as references for item category 05100 (value added tax) and set the indicator for automatic splitting for the added items. Next, deleted item category 40100 (cash discount) in Customizing (Financial

of 386


Accounting (New) -> General Ledger Accounting (New) -> Business Transactions -> Document Splitting -> Extended Document Splitting -> Define Document Splitting Rule).

Caution: If you used report SAPF181 to post documents for splitting of backdated tax calculation, you should reverse these documents. (They are documents of their own.) You identify these documents by means of the reference number (XBLNR) in the document header and then reverse them using a mass reversal (TA F.80). To find the relevant documents, enter the following search string for the reference number: SAPF181/*/4 (The asterisk is a wildcard for the middle part of the number.)

Sample Coding for BAdI FAGL_MIG_ADJ_ACCIT

METHOD IF_EX_FAGL_MIG_ADJ_ACCIT~ADJUST_ACCIT.

* In the example, the profit center as well as

the business area are

* supplied with a default value if one of these

two fields is initial.

* The coding must be modified in accordance with

your new G/L configuration.

FIELD-SYMBOLS: <LS_ACCIT> LIKE LINE OF

CT_ACCIT_ASGMT.

* Subsequent posting of the SAPF181 lines using

a default value for lines

* that were posted without an account assignment

because the original line

* itself did not have an account assignment

* In the standard setup, SAPF181 documents are

posted with document type'SU'.

* If necessary, this must be changed in

accordance with the actual system

* configuration.

READ TABLE IT_ACCIT_EX WITH KEY ACCIT-BLART =

'SU' TRANSPORTING NO FIELDS.

IF SY-SUBRC = 0.

LOOP AT CT_ACCIT_ASGMT ASSIGNING <LS_ACCIT>

of 386


WHERE PRCTR EQ SPACE

OR GSBER EQ SPACE.

* Copy default account assignment for profit

center

IF <LS_ACCIT>-PRCTR IS INITIAL.

"Sample value for a default profit center

<LS_ACCIT>-PRCTR = '0000009999'.

ENDIF.

* Copy default account assignment for business

area

IF <LS_ACCIT>-GSBER IS INITIAL.

" Sample value for a default business area

<LS_ACCIT>-GSBER = '9999'.

ENDIF.

ENDLOOP.

ELSE.

* Subsequent posting of cash discount and

exchange rate difference lines in

* FI cocuments with a default value

LOOP AT IT_ACCIT_EX TRANSPORTING NO FIELDS

WHERE ( ACCIT-KTOSL EQ 'SKE'

OR ACCIT-KTOSL EQ 'SKT'

OR ACCIT-KTOSL EQ 'VSK'

OR ACCIT-KTOSL EQ 'KDF' )

AND ( ACCIT-PRCTR EQ SPACE

OR ACCIT-GSBER EQ SPACE ).

READ TABLE CT_ACCIT_ASGMT ASSIGNING <LS_ACCIT>

INDEX SY-TABIX.

* Copy default account assignment for profit

centers

of 386


IF <LS_ACCIT>-PRCTR IS INITIAL.

" Sample value for a default profit center

<LS_ACCIT>-PRCTR = '0000009999'.

ENDIF.

* Copy default account assignment for business

area

IF <LS_ACCIT>-GSBER IS INITIAL.

" Sample value for a default business area

<LS_ACCIT>-GSBER = '9999'.

ENDIF.

ENDLOOP.

ENDIF.

ENDMETHOD.

Example 1:

� Vendor invoice with 2% cash discount � Accounts for cash discounts are also created as cost

elements, and the default account assignment is die cost center CS99 with business area BA99

� Balance sheets by business areas are activated

Documents before the migration

Vendor invoice (entry view):

G/L account Business area Cost center Amount

Vendor -1,100.00

Expense account 1 BA01 CS01 500.00


Tax 100.00

Vendor payment (entry view):


of 386


Vendor 1,100.00

Bank -1,078.00

Cash discount received BA99 CS99 -20.00

Tax -2.00

Adjustment by SAPF181 (entry view):

G/L account Business area Trading partner business area Cost center Amount

Cash discount received BA99 CS99 10.00


Cash discount received BA99 CS99 10.00


Offsetting account BA99 BA01 -10.00

Offsetting account BA01 BA99 10.00



Documents after the Migration

� Document splitting for business areas including zero balance is active

Vendor invoice (general ledger view):


Vendor BA01 -550.00

Vendor BA02 -550.00

Expense account 1 BA01 500.00


Tax BA01 50.00

Tax BA02 50.00

of 386


Vendor payment (general ledger view - variant 1):


Kreditor BA01 550.00

Vendor BA02 550.00

Bank BA01 -550.00

Bank BA02 -550.00

Bank BA99 22.00

Cash discount received BA99 -20.00

Tax BA99 -2.00

Vendor payment (general ledger view - variant 2):


Vendor BA01 550.00

Vendor BA02 550.00

Bank BA01 -549.00

Bank BA02 -549.00

Bank BA99 20.00


Tax BA01 -1.00

Tax BA02 -1.00

Adjustment by SAPF181 (general ledger view):

The SAPF181 document in the general ledger view is not changed by the document splitting.


Cash discount received BA99 10.00


of 386








Example 2:

� Customer invoice with 2% cash discount � The account for cash discount paid has not been

created as a cost element � Balance sheets by business areas are activated

Documents before the migration

Customer invoice (entry view):


Customer 1,100.00

Revenue account BA01 -500.00


Tax -100.00

Customer payment (entry view):


Customer -1,100.00

Bank 1,078.00

Cash discount paid 20.00

Tax 2.00

Adjustment by SAPF181 (entry view):


of 386


Cash discount paid -10.00

Cash discount paid BA01 10.00

Cash discount paid -10.00

Cash discount paid BA02 10.00

Offsetting account BA01 10.00

Offsetting account BA01 -10.00

Offsetting account BA02 10.00

Offsetting account BA02 -10.00

Documents after the migration

� Document splitting for business areas including zero balance is active and the business area field is a required entry field

Customer invoice (general ledger view):


Customer BA01 550.00

Customer BA02 550.00



Tax BA01 -50.00

Tax BA02 -50.00

Customer payment (general ledger view - variant 1):


Customer BA01 -550.00


Bank BA01 550.00

Bank BA02 550.00

of 386


Bank BA99 22.00


Tax BA99 2.00

Customer payment (general ledger view - variant 2):




Bank BA01 549.00

Bank BA02 549.00

Bank BA99 20.00


Tax BA01 1.00

Tax BA02 1.00

Adjustment by SAPF181 (general ledger view):

In the general ledger view, the SAPF181 document is enriched by the stored default value.










of 386


Example 3:

� Vendor invoice with 2% cash discount � Document splitting for business areas including zero

balance

Posting in new G/L with active document splitting

Vendor invoice (entry view):


Vendor -1,100.00



Tax 100.00

Vendor invoice (general ledger view):


Vendor BA01 -550.00

Vendor BA02 -550.00



Tax BA01 50.00

Tax BA02 50.00

Vendor payment (entry view):


Vendor 1,100.00

Bank -1,078.00



Tax -2.00

of 386


Vendor payment (general ledger view):


Vendor BA01 550.00

Vendor BA02 550.00

Bank BA01 -539.00

Bank BA02 -539.00



Tax BA01 -1.00

Tax BA02 -1.00

1. 3. 8. NGL03_REVERSE_TAX_ADJUSTMENT_POSTINGS (Document Link - /NGL/NGLM_REV_TAX_ADJUST_POS )

Reverse Tax Adjustment Postings

Use

In one of the preceding activities, you reversed the balance sheet adjustment (if applicable). Generally, the same may happen for the tax adjustments created by SAPF181. The reference number (XBLNR) in SAPF181 for tax adjustment documents always follow the naming convention "SAPF181/*/4", so we recommend using this string as selection criteria for the mass reversal.

Please note that the other functions of SAPF181 must be treated in a specific manner as described in the documentation for preceding activities.

Example

You have previously posted a vendor invoice and payment as follows:


Expense 0001 500

of 386


Tax Account - 100

Vendor 0001 600-

Vendor Payment with 5% cash discount, 20% tax rate


Cash Discount 0001 25-

Tax Account - 5-

Bank 0001 570-

Vendor 0001 600

Adjustment Posting


Tax Adjustment Account 0001 5-

Tax Adjustment Account - 5

After the migration (with document splitting), the General Ledger view looks as follows:

a) Original document

Vendor Invoice


Expense 0001 500

Tax Account 0001 100

Vendor 0001 600-

Vendor Payment



Tax Account 0001 5-

Bank 0001 570-

of 386


Vendor 0001 600

b) Adjustment document


Tax Adjustment Account 0001 5-

Tax Adjustment Account - 5

Clearing Account 0001 5

Clearing Account - 5-

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 in EUR

Payables 0001 0

Bank 0001 570-

Tax 0001 90

Clearing 0001 5


Expense 0001 500

The correct financial statement for business area 0001 considering these documents only would look as follows:

Financial Statement for Business Area 0001 Business Area Amount in EUR

Payables 0001 0

Bank 0001 570-

Tax 0001 95

of 386



Expense 0001 500

1. 3. 9. NGL03_CONF_REVERSAL_OF_P/L_B/S_ADJUSTMNT (Document Link - /NGL/NGL05_CONF_REVERSAL_ADJ )

Confirm Reversal of Balance Sheet / P&L Adjustment

Use

In this activity, you confirm that reversal of balance sheet and P&L adjustment in phase 1 has been carried out completely, if applicable.

1. 3.10. NGL00_REVERSE_FOREIGN_CURRENCY_VALUATION (Document Link - /NGL/NGLM_REV_FOR_CURR_VAL )

Reverse Foreign Currency Valuation

Use

In classic General Ledger Accounting, it was possible to use a function called BDIFF update (in SAPF100). With this function, the valuation difference of an open item was updated into the corresponding line item in BSEG. This function is no longer supported in new General Ledger Accounting.

In the new foreign currency valuation (FAGL_FC_VALUATION), BDIFF is not read. The new foreign currency of evaluated items causes incorrect results if the BDIFF update is not reset.

Recommendation

SAP recommends using the function for resetting foreign currencies, which sets the BDIFF to zero and reverses the valuation.

Note

Please refer SAP Note 960661 and 1006684 for more information.

of 386



For migration package 8 (Subsequent change from account solution to ledger solution):

Please use the Reset Valuation function in the new foreign currency valuation program (FAGL_FC_VALUATION) for reversal of the valuation for all periods in current fiscal year by selecting all valuations from migration date until now.

Please note:

Valuations are only reset if a valuation has taken place for the same key date with the same valuation area. If an item is not valuated for the key date, the valuation for the item cannot be reset and nothing happens to the item.

1. 3.11. NGL00_REVERSE_FOREIGN_CURR_VAL_CONFIRM (Document Link - /NGL/NGLM_REV_FOR_CURR_CONF )

Confirm Reversal of Foreign Currency Valuation

Use

In this activity you confirm that the valuation run(s) starting from migration date have been reversed completely.

Dependencies

After reversal of the original valutation run(s) and the transport of the new account assignments you are able to rerun the foreign currency valuation.

1. 3.12. NGL03_POST_PARKED_DOCUMENTS (Document Link - /NGL/NGL05_POST_PARKED_DOCS )

Post Parked Documents

Use

As a rule, parked documents are not relevant for the migration. There is one exception, however, that makes it necessary to differentiate between two categories of parked or preliminary documents:

� Preliminary documents, such as invoices, that have not

of 386


been posted yet and that do not refer to follow-up documents

� Preliminary documents that are used as reference documents in follow-up processes; currently this can be prepayments on preliminary postings

If there are actual documents in FI that refer to parked or preliminary documents, these parked documents must be posted before the migration (because of document splitting). If there is no reference to the parked document, the document can be enriched by all necessary account assignments and finally posted when new general ledger accounting is active. As an option, these parked documents can also be posted before the migration.

1. 3.13. NGL03_PERF_OTH_OPEN_BTCH_IP_SSINS_N_POST (Document Link - /NGL/NGLM_PERF_OPN_BTCH_SESS )

Check Open Batch Input Sessions and Postings

Use

In this manual step, you confirm that all open batch-input sessions and postings have been performed successfully. Open batch-input sessions are those with status

� New � Incorrect � In Process � In Background � Being Created

Note: Customer-specific programs that create batch-input sessions must be adapted if you use additional account assignments in the new general ledger accounting. Especially if you use document splitting (requires migration package 3 or 5), you should analyze the impact of the created documents regarding the document splitting in new general ledger accounting. Make sure that these processes are tested adequately.

Activities

Process all relevant sessions and confirm the status in this migration cockpit activity.

1. 3.14. NGL03_COMPLETE_PAYMENT_RUNS (Document Link

of 386


- /NGL/NGL05_COMPL_PAYMNT_RUNS )

Check Payment Runs

Use

In general, payment runs should be processed before any migration activities are started. If there are open payment runs at this point in time, this might have an impact on the follow-up process in new general ledger accounting. With document splitting (requires migration package 3 , 5 or 6), it could happen that the payment proposal does not contain account assignments that are required for the postings under new G/L later on, for instance, if you introduce document splitting by profit centers. If there are downpayment requests without a profit center within the payment proposal, you receive an error. In this case there are two options:

� Complete the payment run under classic G/L and make sure that all necessary account assignments are available or derived by a BAdI.

� If you do not complete the payment run, you can delete it in new general ledger accounting. Note that changes in payment proposal will possibly be lost then.

1. 3.15.

NGL00_STOP_POSTINGS_DURING_MIG_PROCESS (Document Link - /NGL/NGLM_STOP_POST_DURG_MIG )

Stop Postings During Migration Process

Use

In order to be able to migrate a constant set of data to the new general ledger accounting, you must stop all postings in the system. We recommend that you specify a system downtime for the migration during which no operational activity takes place.

Prerequisites

You have finished all necessary postings. After the migration, posting in the previous fiscal year is no longer possible. Reopening the previous fiscal year is forbidden.

Depreciation and periodic postings from FI-AA were completed for the previous fiscal year. Also other

of 386


sending applications that create FI documents have been processed completely.

1. 3.16. NGL00_CHECK_RESET_CLEARING_CONTROL (Document Link - /NGL/NGLM_CHK_RESET_CLR_CTRL )

Check Clearing Reset Control

Use

The program for this activity checks if your system allows a clearing reset for clearing dates before the migration date. If so, you will receive a warning message. When you proceed with the migration, you are no longer allowed to reset clearing for entries from before the migration date. Re-posting to the previous year is forbidden as well. (More information about this is provided in the documentation for activity Confirm Reconciliation and Closing of Previous Fiscal Year).

Activities

Delete the message control for area FAGL_MIG and message number 066 or set this message to type "E" (error message).

1. 3.17. NGL03_CHECK_DOCUMENT_SPLITTING

1. 3.17.1. NGL03_CHECK_BUSI_TRANS_ASSGMNT_FOR_DOC1 (Document Link - /NGL/NGL03_CHK_BUSI_TRAN_ASG )

Check Business Transaction Assignment for Documents

Purpose

The program checks whether each of the selected documents posted in migration phase 1 applies the rules stored in the business transaction variant assigned to that document.

Prerequisites

The customizing for document splitting in new general

of 386


ledger accounting has been created.

Features

The program checks the selected document types to determine whether the documents posted since the migration date fulfill the definition of the assigned business transaction variant. You check the assignment of the business transactions to document types in activity Check Document Types for Document

Splitting.

If you have already assigned a document-specific business transaction and activated it in customizing for the migration, this assignment is applied for the check. For all other documents, the system derives the business transaction from the document type used.

Documents that do not fit the assigned business transaction variant are listed as containing errors. You can use the Save Docs Containing Errors indicator to include these documents with the checked business transaction variant and status Inactive in the table for alternative business transaction assignments. Here, you can assign to these documents a suitable business transaction variant for use in migration.

If required, you can specify a posting period or document number for which you want the system to display the documents to be checked.

1. 3.17. 2. NGL03_LIST_LOG_FOR_VALIDATION

(Document Link - /NGL/NGLM_LIST_LOG_FOR_VALID )

List Log for Validation of Document Splitting

Use

In this activity, you can analyze the log entries for validation.You can delete any entries that are no longer required from the log. However note that deleted log entries cannot be recreated.

Requirements

You have activated the validation.

of 386


1. 3.17. 3.

NGL03_ALTERNATI_SETTINGS_4_DOC_SPLITTING

1. 3.17. 3.1. NGL03_DEF_ALTERNATIVE_DOC_SPLIT_METHOD (Document Link - /NGL/NGL03_DEF_ALT_SPLT_METH )

Define Alternative Document Splitting Method

Use

In this activity, you enter a separate document splitting method that is to be used exclusively for the migration of documents that have already been posted.

Requirements

� In the customizing for document splitting in new general ledger accounting, you have defined the alternative method in the activity Define Document Splitting Method.

To prevent inconsistencies between the migrated documents and the documents posted after activating new general ledger accounting, you need to copy the standard method (stored under Assign Document Splitting Method and make adjustments accordingly.

� In the alternative document splitting method for the migration, all Document Splitting Rules used for the migration must be defined completely. To this purpose, copy all the document splitting rules of the document splitting method stored as standard to the alternative document splitting method for the migration, and then make the migration-specific changes to the document splitting rules.

� If necessary, you can define more business transaction variants. You can then define alternative rules for these business transaction variants or change the assignment to the item category (see also the activity Define alternative business transaction assignment in the migration cockpit).

Activities

Specify the alternative document splitting method for

of 386


the migration.

Note that this method is only used for the documents to be migrated. The alternative document splitting method is not applied to documents posted after the migration!

Example

Customer invoices in the current year need to be handled with an alternative document splitting rule.

The standard method cannot split this document in a way that makes business sense because the document contains posting items with item category Balance

Sheet Account (01000).

To define an alternative document splitting method, you copy the document splitting rules from the standard method and change the rules to meet your requirements. In this example, you add a new rule for the business transaction variant Customer Invoices that splits item category 01000 on the basis of the revenue item.

In this way, the change takes effect for migration documents, but it is not applied to new documents to be posted after new general ledger accounting has been activated.

1. 3.17. 3. 2. NGL03_DEF_ALTERNATIVE_BUSI_TRANSACTION (Document Link - /NGL/NGL03_DEF_ALT_BUSI_TRAN )

Define Alternative Business Transaction Assignment

Use

In this activity, you can assign an alternative business transaction variant to selected documents. In the migration, this assignment overrides the standard derivation of the business transaction variant, such as derivation from the document type.

Prerequisites

Either you have assigned a document splitting method

of 386


in customizing for document splitting, or you have specified an alternative document splitting method in the related activity.

Note: Here you only assign existing business transaction variants. You may also need to define a document splitting method for the migration only.

Activities

For documents that cannot be migrated using the business transaction variant derived by the standard method, assign an alternative business transaction variant.

For cross-company code documents, single documents from other company codes are automatically assigned to the same business transaction variant. For this reason, the internal key of the entire document is displayed in the fields Reference Key and Reference

Transaction. You cannot assign different business transaction variants to documents with the same reference fields. Check your assignments and how they are derived by saving your settings.

For the migration of the documents contained in the table, the business transaction variant assigned explicitly is used instead of the business transaction variant derived from the document type or transaction used to interpret the document. This is logged in the status management of the migration objects in the Adjustment field. You can display the status management in the migration cockpit under Migration

phase -> Evaluation -> Analyze Migration Status and in the -> log for document adjustment.

Example

You have entered a customer invoice with document type DZ. In customizing for document splitting, however, document type DZ has the business transaction Payment assigned in a variant that requires a bank account line in the document.

Migration of the invoice is rejected with the error message that the document does not contain the required bank account line.

You assign business transaction Customer Invoice with an appropriate business transaction variant to the

of 386


document in this activity and then repeat the migration for this document.

Document splitting now interprets the document as a customer invoice and no longer applies the business transaction Payment to this document.

1. 3.17. 3. 3. NGL03_DEF_ALTERNATIVE_ITEM_CATG_ASSGNMT (Document Link -

/NGL/NGL03_DEF_ALT_ITEM_CATG )

Define Alternative Item Category Assignment

Use

In this activity, you assign an alternative Item category to the posting item of a document. During migration, this assignment overrides the standard item category assignment for document splitting.

Prerequisites

Either you have Assigned a document splitting method in customizing for document splitting, or you have entered a migration-specific document splitting method in the related migration cockpit activity.

Activities

Assign the item category to the line items that cannot be classified uniquely or correctly for document splitting.

When the line items in the table are migrated, the item category that has been assigned explicitly is used (instead of the item category derived internally or from the G/L account) to interpret the line item. This is logged in the status management of the migration objects in the Adjustment field. You can display the status management in the migration cockpit under Migration phase -> Evaluation -> Analyze Migration Status and in the -> log for document adjustment.

Example

You have posted items with different types, such as bank clearing and other accruals. These items should be handled differently in document splitting.

of 386


You have classified the G/L account in customizing for document splitting using the item category that is applied most frequently. Here, however, you assign this alternative item category explicitly to the items that are to be interpreted using an alternative item category.

Document splitting then applies these explicitly assigned alternative item categories during the migration.

1. 3.18. NGL00_CHECK_ACCT_CONTROL_SETTINGS (Document Link - /NGL/NGLM_CHK_ACT_CTRL_STNGS )

Check Account Control Settings

Use

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.

Example

If you post an open item, the corresponding line item will be technically posted with the account control settings that are valid while the posting happens. If afterwards the account control settings will be changed (switch from "open item managed" to "non-open item managed") without adjusting the existing line items it would look like that the line item is an open item although the corresponding account is no longer open item managed.

Activities

Execute the activity.

The program will check for all assigned company codes of the current migration plan if the existing line items are consistent with the current account control settings.

of 386


The check will be done for all line items of the G/L accounts in the system (technically: tables BSIS and BSAS will be checked).

If inconsistent line items exist you will find the corresponding G/L account in the protocol (reconciliation accounts will not be checked). Inconsistent line items must be corrected before the migration starts. Check SAP Note 175960 for further information. If you need assistance for the correction, open a customer message on component XX-RC (XX-RC = remote consulting).

Remark

In a huge database the runtime of the program can be very long as all existing line items and all existing accounts for each assigned company code will be checked.

Relevant for Enhancement Package 3 (EhP3) or higher

With EhP3 (and the activation of the corresponding business function for new G/L) it is possible to do clearings specific to ledger groups. This new feature can be activated for G/L accounts in the corresponding account master data with flag "Clearing Specific to Ledger Groups" (further information can be found in the F1 help of this flag).

If at least EhP3 is installed in your system, the program will do some further consistency checks related to this new feature. The program will check that the account master data as well as the existing open and cleared items of the G/L accounts are fulfilling the basic requirements for the new feature.

1. 3.19. NGL00_RECONCILE_CLASSIC_GL (Document Link - /NGL/NGLM_RECNCILE_CLASK_LEG )

Reconcile Classic G/L for Current Fiscal Year

Use

SAP recommends reconciling the system by using the Financial Accounting Comparative Analysis (SAPF190) at period end, for example monthly. In

of 386


particular, this program should be performed before the migration takes place to ensure the consistency of the transaction figures.

Remark Within scenarios 4 and 5 transaction FAGLF03 (program TFC_COMPARE_VZ) will be used.

Activities

In the event of differences, the incorrectness must be clarified and repaired. If necessary, contact SAP Support (by creating a message).

1. 3.20. NGL00_RECONCILE_SOURCE_LEDGERS (Document Link - /NGL/NGLM_RECNCILE_SRC_LEGS )

Reconcile Source Ledgers

Use

Depending on the source ledgers that you actually use and the account assignments that you would like to transfer within the balance carry-forward, you may use either standard GLT0 or the appropriate ledger in the other SAP totals tables GLFUNCT, GLT3, GLPCT, or other FI-SL ledgers in your own totals table.

Normally, GLT0 is the table to be used for uploading the balance carry-forward. If you want to migrate the balance carry-forward for additional characteristics such as Profit Center or Trading Partner, you can upload the balance carry-forward for instance from the ledgers in GLT3, GLFUNCT, or GLPCT.

Note that GLFUNCT is only relevant if you have trading partner information in GLFUNCT that requires balance sheet accounts (and not only P&L accounts in combination with functional area) to be posted to GLFUNCT as well. The P&L accounts whose balance is zero are not relevant for the upload balance carry-forward.

If you use tables other than GLT0 for the upload carry-forward, you have to reconcile the ledger that you want to use with GLT0 on company code and account level.

of 386


For a migration from GLT0 ledger '0' only, you can set this activity to status green, and no further action is required in this activity.

1. 3.21. NGL00_CONFIRM_EXEC_OF_BALCF_OF_SRC_LEDGS (Document Link - /NGL/NGLM_CONF_EXEC_CF_SRCLD )

Confirm Balance Carry-Forward of Source Ledgers

Use

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.

In this activity, you confirm that balance carry-forward in the source ledgers up to the current fiscal year (of the migration) has been done.

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.

Make sure that you create the balance carryforward for these accounts within the relevant source ledger in classic G/L. Activity 'Transfer Balance Carry-Forward' in 'Migration phase' transfers the balance carryforward 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 carryforward 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.

1. 3.22.

NGL00_CRE_OPEN_BALANCE_SHEET_4_CC_IN_CLA (Document Link -

of 386


/NGL/NGLM_CRT_OPN_BAL_SHT_CL )

Create Opening Balance Sheet in Classic General Ledger

Use

We recommend creating an opening balance sheet in classic general ledger accounting for the current fiscal year for all company codes and uploading it in the migration cockpit for documentation purposes. You can use the report you normally use for this purpose, for example RFBILA00.

Activities

Create the balance sheet. We recommend that you upload the list output as attachments in the migration cockpit to have it available for documentation purposes.

1. 3.23. NGL00_CRE_OPEN_BAL_SHEET_4_CC_IN_CLA_PDF (Document Link - /NGL/NGLM_CRE_OPN_BSHT_CLPDF )

PDF Conversion of Balance Sheet

Use

Once you have created the balance sheet (in the preceding activity), you convert it to a PDF file and attach this file to the activity.

1. 3.24. NGL00_CRE_YTD_BALANCE_SHEET_4_CC_IN_CLAS (Document Link - /NGL/NGLM_CRT_YTD_BAL_SHT_CL )

Create Balance Sheet in Classic General Ledger

Use

We recommend creating a balance sheet and P&L in classic general ledger accounting for the current fiscal year (with the migration date as the key date) for all company codes and uploading it to the migration

of 386


cockpit for documentation purposes. You can use the report you normally use for this purpose, for example RFBILA00.

Activities

Create the balance sheet. We recommend that you upload the list output as attachments in the migration cockpit to have it available for documentation purposes.

1. 3.25. NGL00_CRE_YTD_BAL_SHEET_4_CC_IN_CLAS_PDF (Document Link - /NGL/NGLM_CRE_YTD_BSHT_CLPDF )

PDF Conversion of Balance Sheet

Use

Once you have created the balance sheet (in the preceding activity), you can convert it to a PDF file and attach this file to the activity.

1. 4. NGL00_MIGRATION_PHASE

1. 4.1. NGL00_REBUILD_DATABASE_STATISTICS_DOC (Document Link -

/NGL/NGLM_REBLD_DB_STAT_DOC )

Rebuild Database Statistics

Use

To determine an optimum access path for search queries in the database and to avoid long runtimes for individual database accesses or generally bad performance of the database it is always better to 'Update Database Statistics'. If this statistical data is obsolete or does not exist, this can cause performance problems because the optimizer may then use an unfavorable access path.

This activity needs to run in a repetitive fashion i.e. before triggering the activities in 'Migration from Prior Years' and 'Migration from Current Year'.

of 386


The tables FAGLFLEXA and FAGL_SPLINFO will be updated first by the creation of G/L line items and balance carry-forward.

The tables FAGLFLEXA, FAGLFLEXT and FAGL_SPLINFO will be updated by the execution of Transfer Documents to New General Ledger.

The tables FAGL_MIG_RPITEMS and FAGL_MIG_OPITEMS will be updated by the execution of Build Work List for Open Items and Build Work List for Documents respectively.

We recommend that you rebuild the database statistics before you start the update programs. To know more about database statistics refer SAP Note : 588668.

Activities

Contact your system or database administrator.

1. 4. 2. NGL00_BUILD_WORK_LIST (Document Link - /NGL/NGLM_BUILD_WORK_LIST )

Build Work List

Use

Before the migration programs update the new general ledger tables, you have to build the work lists that contain all relevant data for open items (from migration phase 0) and documents in the current fiscal year of migration (migration phase 1). The open items and documents are selected by these programs and saved into separate tables.

Therefore there are two work lists:

� Work list for open items � Work list for documents

You use this activity to start the relevant selection programs to generate the work lists for both open items and documents. The migration plan will automatically receive the status Started.

Note

of 386


For scenario NGL04 and NGL05 migration plan will be already started using activity Start Migration Plan.

1. 4. 2.1. NGL00_RECONCILE_WORK_LIST_OPEN_ITEMS (Document Link - /NGL/NGLM_BLDWRK_LST_OPNITMS )

Build Work List for Open Items

Use

In this activity, the system generates the worklist of open items to be migrated. In this process, all G/L account lines that are managed on an 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.

Once the worklist for open items has been created, you may not perform the following postings:

� Postings with a posting date earlier than the migration date

� Clearings with a clearing date earlier than the migration date

� Clearing reset with a clearing date earlier than the migration date.

The worklist is stored in table FAGL_MIG_OPITEMS for open items.

Features

The indicator "Reconcile work list and dataset" on the selection-screen is no longer supported (see SAP note 1115351 for further details).

A reconciliation of the worklist can be relevant:

� If you execute the program for determining the worklist of open items to be migrated more than once

� If the periods of the old fiscal year (prior to the migration date) are not yet closed or were reopened temporarily

� If you have performed clearing postings.

Activities

of 386


To still be able to reconcile the worklist, refer to SAP note 1115351 and use program FAGL_MIG_CHECK_WORKLIST_OP (check also to the report documentation for further details).

The output list of the program will show you all open items that are no longer necessary which means they have been cleared in the meantime after building the first worklist. Additionally, if you have changed the account control settings in the meantime, you will also find those open items in the output list, because the program does not know how to check these accounts.

Open items that are no longer relevant for the migration have to be removed from the worklist. Use activity "Reset Open Items Only" within subphase Evaluation of phase Migration Phase to remove the open item from the worklist.

Remark

Note, however, that we strongly recommend closing the periods of the fiscal year for the migration before you generate the worklist. In this case, you do not have to reconcile the worklist because the status of the open items (with regard to the migration date) can no longer be changed.

Example

You have already generated the worklist of open items. The worklist contains open item A, which was open on the migration date. You have successfully performed the migration for the open items.

However, for closing operations, item A still has to be reconciled in the old fiscal year (before the migration date). Reconciliation is performed using item B in the old fiscal year.

If you were now to regenerate the worklist of open items for migration, neither item A nor item B would be relevant for the migration because both items had been reconciled before the migration date. Furthermore, the opening balance of the account for item A has been determined incorrectly in the update of open items to new general ledger accounting because item A is contained in the balance, which is no longer justified.

of 386


Output

The system determines the migration objects and specifies the number of migration objects transferred to the worklist or the number of migration objects already contained in the worklist.

New migration objects that have been included in the worklist receive the status Not Processed (00).

Furthermore, if the migration plan has not been processed previously, the corresponding migration plan receives the status Started.

1. 4. 2. 2. NGL00_CHECK_WORKLIST_OP (Document Link - /NGL/NGLM_CHECK_WORKLIST_OP )

Check Worklist of Open Items

Use

With SAP note 1115351 the program (FAGL_MIG_OPITEMS_FILL) for building the worklist for the open items was modified, so that the option Reconcile Worklist is no longer available.

There are several reasons for deactivating this feature. With SAP note 1014617 the program was enhanced to be able to handle mass data in huge customer systems. Due to technical and performance reasons it was decided to exclude the reconciliation of the worklist within the same program.

To be able to check the worklist regarding validity, you have the chance to start the reconciliation of the worklist manually in a separate step.

When is it relevant to perform this reconciliation?

� You have executed activity "Build Work List for Open Items" more than once

� The periods of the old fiscal year (prior to the migration date) are not yet closed

� You have performed clearing postings

Prerequisites

You have implemented SAP note 1115351 (or the

of 386


corresponding support package) in your system but you still want to check if all open items that are in the worklist are still relevant for the migration.

Note, however, that we strongly recommend closing the periods of the fiscal year for the migration before you generate the worklist. In this case, you do not have to set this indicator because the status of the open items (with regard to the migration date) can no longer be changed.

Example

You have already generated the worklist of open items. The worklist contains open item A, which was open on the migration date. You have successfully performed the migration for the open items.

However, for closing operations, item A still has to be reconciled in the old fiscal year (before the migration date). Reconciliation is performed using item B in the old fiscal year.

If you were now to regenerate the worklist of open items for migration, neither item A nor item B would be relevant for the migration because both items are reconciled before the migration date. Furthermore, the opening balance of the account for item A has been determined incorrectly in the update of open items to New General Ledger Accounting because item A is contained in the balance, which is no longer justified.

Activities

Execute program

FAGL_MIG_CHECK_WORKLIST_OP (see SAP note 1115351) manually. Enter the migration plan of the package that you would like to check.

The output list of the program will show you all open items that are no longer necessary which means they have been cleared in the meantime after building the first worklist. Additionally, if you have changed the account control settings in the meantime, you will also find those open items in the output list, because the program does not know how to check these accounts.

Open items that are no longer relevant for the migration have to be removed from the worklist. Use activity "Reset Open Items Only" within subphase

of 386


Evaluation of phase Migration Phase to remove the open item from the worklist.

Attention

If the items are not removed, they could cause differences in the balance carryforward of the corresponding reconciliation account / account managed on an open item basis.

Remark The program can have a very long runtime. It will check all existing open items within the worklist table of the corresponding migration package (= migration plan) if it is still open. Background execution is recommended in huge databases.

1. 4. 2. 3.

NGL00_RECONCILE_WORK_LIST_DOCUMENTS (Document Link - /NGL/NGLM_BLDWRK_LST_DOCS )

Build Work List for Documents

Use

In this activity, the system determines the work list for the documents to be migrated. All documents that were posted in the period starting with the migration date are determined for the specified migration plan. If the program is executed more than once, the system only considers additional documents that have been posted since the last time the program was run.

Features

Use the Read completely indicator to specify whether the complete dataset should be read when the work list is regenerated or whether the system should only select the documents created since the last time the program was run.

� Indicator is set ('X') The complete dataset is read. In some cases, this can cause the program to have very long runtimes.

� Indicator is not set (' ') The system only determines the migration

of 386


objects that have been added since the last time the program was run. The decision regarding whether a document is considered or not depends on the system time at which a document was posted, not on the posting date of a document. (This is the recommended setting.)

Output

The system determines the migration objects and specifies the number of migration objects transferred to the work list or the number of migration objects already contained in the work list.

New migration objects that have been included in the work list receive the status Not Processed (00).

Furthermore, if the migration plan has not been processed previously, the corresponding migration plan receives the status Started.

1. 4. 2. 4. NGL00_CONFIRM_BUILD_WORKLIST (Document Link - /NGL/NGLM_CONF_CREATN_WRKLST )

Confirm Completion of Work List Creation

Use

The programs for creation of work lists can be repeated. In this activity, you confirm that creation of work lists for open items and documents is completed. After that, no further postings may be added to or deleted from the work list.

1. 4. 3. NGL00_GENERATE_CODING_FOR_NEWGL (Document Link - /NGL/NGLM_GENERATE_CODE_NGL )

Use

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

of 386


once. For all other migration packages you can set the status of the activity manually.

Prerequisites

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

Features

Executing this activity while postings will happen in parallel (also in different clients in the system), a shortdump of the posting transaction might occur (error LOAD_PROGRAM_LOST).

1. 4. 4. NGL00_MIGRATION_FROM_PRIOR_YEARS

1. 4. 4.1.

NGL00_TRANSFER_BALANCE_CARRY_FORWARD (Document Link - /NGL/NGLM_TRANSF_BALCARY_FWD )

Transfer Balance Carryforward

Use

In this activity, you can generate an opening balance (balance carryforward period) for new General Ledger Accounting for the current fiscal year by transferring the balance carryforward from an existing ledger into a ledger in new General Ledger Accounting. The balance carryforward is transferred from the source ledgers that have been assigned in the setup phase.

You can restrict the selection to individual company codes and accounts or account intervals. The program updates the status for the selected accounts or account intervals.

A check will be carried out in this activity at the end of execution to make sure whether balance carryforward is over successfully for all the assigned account intervals or not. As long as not all intervals are processed, this check will end with error.

Preconditions

of 386


� You have made the settings in activity Assign source ledgers for those accounts or account intervals that have to be transferred.

� If FBCB documents have been posted, these documents have to be reversed before upload carryforward takes place to the affected accounts.

Dependencies

If you want to correct the balance carryforward once you have performed the transfer, you must first reset the balance carryforward period in the target ledger. To do this, choose activity Reset Balance Carry Forward. Having reset the balance carryforward, you can change the settings in activity Assign source ledgers.

To get an overview about the balance carryforward, execute the function for activity Display Status for

Balance Carryforward.

Note

The fields of the source ledger are transferred to the fields of the target ledger on the basis of name equality. Some known name inequalities are corrected in this process, such as BUKRS and RBUKRS (company code) or PRCTR and RPRCTR (profit center). If, however, you want to transfer a customer field to a customer field in a ledger (such as the field RZZAUFNR for the order number to the customer field ZZAUFNR of the FI-SL target ledger in new General Ledger Accounting), you must implement the BAdI FAGL_UPLOAD_CF, in which you define the relation between these fields. (More information is provided in the documentation for activity Additional BAdI Implementation in the setup phase.)

1. 4. 4. 2. NGL00_DISPLAY_LOG_FOR_BALANCE_CARRY_FOR2 (Document Link - /NGL/NGLM_DISP_LOG_4_BCFWD )

Display Log for Balance Carryforward

Use

Use the program for this activity to analyze the origin

of 386


of the transfer of balance carryforward.

Prerequisites

You have uploaded the balance carryforward (Migration Phase -> Migration from Prior Years -> Transfer Balance Carryforward).

Features

The system displays the accounts for which the balance was carried forward. You can see how the balance carryforward was created. For the amount of the balance carryforward itself, you can use activity Compare Source and Target Ledger for Balance

Carryforward to reconcile the figures.

The status of the balance carryforward can be displayed in activity Display Status for Balance Carryforward.

1. 4. 4. 3. NGL00_DISPLAY_STATUS_FOR_BAL_CARRY_FORWA (Document Link - /NGL/NGLM_DISP_STS_4_BCARFWD )

Display Status for Balance Carryforward

Use

Within this activity, you can display and analyze the status of each account respectively account interval that you assigned to source ledgers in the Setup Phase.

Features

For every company code / target ledger combination, the defined accounts are shown with the status:

� Upload has been performed successfully � Upload has been performed with errors � Upload has not yet been performed.

If you select a single line, you see the processing status for this line including information about the user, timestamp and "upload or reset (delete)" action. This allows you to find out about the reasons for any incorrect or incomplete balance carryforward figures

of 386


that may occur.

Recommendation

SAP recommends printing out the results of this report and attaching this information to the activity for documentation purposes.

1. 4. 4. 4.

NGL00_CONFIRM_COMPLETE_EXEC_OF_TRAN_BCF (Document Link - /NGL/NGLM_CONF_BALCARY_FWD )

Check Completeness of Transfer Balance Carryforward

Use

The program for this activity checks if the balance carryforward has been transferred for all accounts that have been set up in Assign Source Ledgers.

Activities

If any account or interval of accounts are missing, complete the transfer of balance carryforward.

1. 4. 4. 5. NGL03_PROCESS_DOCSPLIT_INFO_FOR_OPENITEM (Document Link - /NGL/NGL03_PROC_DOCSPLT_OPIT )

Process Document Splitting Information for Open Items

Use

Use this program to generate entries in the document splitting tables for open items that were posted before the migration date (migration phase 0). This step is only relevant for migration packages with document splitting.

Note:

This program only collects the relevant documents, but does not do the document splitting as such. You

of 386


can use a BAdI to add an account assignment for each individual open item. (This does not change the open item itself in the original tables BSIS or BSIK or BSID, BSEG.)

Prerequisites

� Implementation of BAdI FAGL_MIGR_SUBST. You have implemented this BAdI, which allows you to enhance the open items with account assignments posted without document splitting.

� If you derive the segment from the profit center, you need to have set the Segment derivation is active indicator in the activity Prepare segmentation -> Activate segment derivation (Setup Phase). If you have implemented the BAdI FAGL_DERIVE_SEGMENT, it overrides each segment derivation. Please note that the BAdI FAGL_DERIVE_SEGMENT is not part of the migration cockpit; rather, it is a functionality provided by new General Ledger Accounting in general.

Features

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.

Status Management

If an open item has a status other than 10, the program displays the item as not processed or as containing an error. The following statuses are possible:

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

of 386


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

Note:

Since open items can also be assigned to more than one migration package respectively migration plan (in cases involving a non-calendar fiscal year variant), the status of an open item is adjusted independently of the migration plan selected.

Example

The open item 100000090 exists in the worklist for migration plan MP1 as well as in the worklist for MP2. When you execute the program for migration plan MP1, the status of this open item is updated in migration plan MP1 as well as in migration plan MP2. Previously, you had determined the worklists for both migration plans. However, the program does not display the documents of migration plan MP2.

1. 4. 4. 6. NGL00_CREATE_GL_LINEITEMS_N_BALCARRYFORW (Document Link - /NGL/NGLM_CRT_G/L_LITM_BCFWD )

Create G/L Open Items and Balance Carry-Forward

Use

This activity allows you to transfer open items from the previous year to new general ledger accounting and, simultaneously, to adjust the balance carry-forward (period 0) of the migration year.

The items are selected from the work list of open items to be transferred.

For migration plans without document splitting, the following statuses apply:

� Status 00: Items with this status have not yet been processed.

� Status 01: Items with this status have been processed with errors.

of 386


The following status is available for migration plans using document splitting:

� Status 10: Items with this status have already been successfully processed in an update run. Entries have been generated in the document splitting tables.

Items that have already been transferred to new general ledger accounting without errors are not selected again for processing.

Under Output Control, you can select the type of output:

� Display Overview Only

The system displays the number of items processed with errors, the number of items that were successfully updated but with messages, and the number of items that were updated correctly.

� Overview + Incomplete Objects

Besides the overview of processed items, the system issues a list of all items for which messages were issued.

� Overview + All Objects Besides the overview of processed items, the system issues a list of all items.

Under Parallel Processing, you can make the settings for executing the program using parallel processing. You only have to make all settings in this area if you want to use the program for mass processing and parallel processing.

� In the Package Size field, specify how many documents should be processed in a single process. If you specify a package size of 1000, the system always processes 1000 documents in a process.

� If you want to use specific application servers for processing, specify a server group. Making an entry here is optional. If you do not make an entry, all application servers that are currently available in the current SAP system are used as a server group.

� Specify the maximum number of processes to

of 386


be run in parallel. If you leave this field empty, the program is not performed in parallel.

� Please be aware that the number of parallel processes you enter here need to be available as

UPDATE work processes in the current system. It helps to prevent deadlock situation.

Notes on system performance

� To improve system performance, you can reduce the package size and thus use the available processes more effectively. Note, however, that this increases the overall workload on the network

� Furthermore, you can execute the program in multiple jobs, or by company code or fiscal year, or by a combination of both.

1. 4. 4. 7. NGL00_ANALYZE_MIGRATION_STATUS1 (Document Link - /NGL/NGLM_ANALYZE_MIG_STATUS )

Analyze Migration Status

Use

You can use this program to analyze the processing status of the migration objects.

The program produces statistics on the processing statuses for the work lists of open items to be processed and documents to be transferred. The system displays the total number of migration objects for each status value and the percentage of the migration objects in the work list that have a given status.

Furthermore, the system generates a list of the error messages for the work list objects, showing the total number and the percentage share of the amount of occurrences for each error message.

You also have the option of displaying the analyzed migration objects as a list.

Selection

� To analyze the processing status of the

of 386


open items in the work list, select the Open Items To Be Prepared indicator.

� To analyze the processing status of the documents in the work list, select the Documents To Be Transferred indicator.

� In the Selections for the Document area, you can select individual documents or ranges of documents from the work list of the specified migration plan.

� In the Selections for Processing Status area, you can select migration documents by status or error message from the work list of the specified migration plan.

� Select the level of detail you require: � Statistics Only

Set this indicator to display just a summary of the analysis results for the selected objects.

� Statistics + Incomplete Objects Set this indicator to display a list of the migration objects that have not yet received the migration status Complete (XX) in addition to the summarized analysis results for the selected objects.

� Statistics + All Objects Set this indicator to display a list of all migration objects in addition to the summarized analysis results for the selected objects.

Output

� If you have started the program directly, the system displays the data as an interactive list in the ALV grid format. You can use pushbuttons to switch between the evaluation views (statistics, error statistics, or document list).

� If you have executed the program in the background, the system prints out a series of sublists for each selected work list, depending on the selected level of detail.

Activities

Depending on the level of detail you select, you can use the following display and navigation options for each work list (open items to be processed or documents to be transferred):

of 386


� Display Complete Statistics � Display Error Statistics � Display Object List � You can switch to the analysis results for

the other work list. � From the object list, you can display other

details: � For transferred documents, you can

display the document splitting results independent of the ledgers.

� Document display using the Document Number field.

� Log display for migration-specific document adjustment using the Adjustment field.

� Message documentation display using the Message Text field.

1. 4. 4. 8. NGL00_CONFIRM_G/L_LINEITEMS_BALCARRYFRWD (Document Link - /NGL/NGLM_CONF_GL_LITM_BCFWD )

Check Completeness of G/L Line Items and Balance Carryforward

Use

The program for this activity checks if G/L line items from the worklist have been created completely for accounts managed on an open item basis.

Prerequisites

The work list that has been created at the beginning of the migration phase is complete.

Activities

If open items are not yet processed, run the function for creating G/L line items and balance carryforward once again.

1. 4. 4. 9.

of 386


NGL00_COMP_SRC_N_TRGT_LEDGERS_TECHNICALL (Document Link - /NGL/NGLM_COMP_SRC_TRGT_LEG )

Compare Source and Target Ledgers for Balance Carryforward

Use

To ensure and document the correctness of the entire migration, you have to compare classic General Ledger Accounting against new General Ledger Accounting by means of a ledger comparison. The ledger comparison provided by this activity checks whether the values for balance carryforward in the specified source and target ledgers agree. The comparison is made at company code and account levels.

Features

Within the activity, you can select the company code and target ledger as well as the currency type. With the option Display differences only, you only get the accounts with differences. The final status of the report is set to green only if no differences occur for any of the company codes and target ledgers assigned to the current migration plan. If the comparison reveals differences in company code currency, the traffic light is red. For all other currency types, you get a warning message if the figures do not match.

The activity always shows the comparison status of all the company code and target ledger combinations assigned to the current migration plan, regardless of which combination has been checked during the execution.

Activities

of 386


Perform a ledger comparison for all relevant combinations, and upload the lists to the migration cockpit for documentation purposes.


Since the comparison of the balance carryforward also includes open-item accounts, the G/L line items and balances must be migrated completely. This is also checked within the activity.

It is not possible to compare the balances of open item managed accounts if the company code (source ledger 0) and target (non-leading) ledger have different fiscal year variants. In this case, you have the following options:

� Either skip the comparison of open item managed accounts.

� Or Speciify the correct source ledger with same fiscal year variant.

1. 4. 4.10. NGL00_REPOST_BAL_CARRY_FORWARD_MANUALLY (Document Link - /NGL/NGLM_REPOSIT_BCFWD_MANU )

Repost Balance Carry-Forward Manually

Use

This activity allows you to repost balance carry-forward manually.

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

of 386


carry-forward from classic general ledger accounting or from another ledger (in FI-SL or EC-PCA, for example). This depends on the dimensions (other than the company code) that you want to use for your future financial statements in new general ledger accounting. Using the function Post Balance Carryforward for Ledger Groups (transaction FBCB), you can make postings to the balance carry-forward of the current fiscal year (Period 0).

Prerequisites

The transfer of balance carry forward has been done, and the migration plan containing the leading ledger (only for migration package 1-6) is

not completed. In migration package 7 and 8 the migration plan containing the new ledger is not completed.

Features

When using this function, consider the following:

� Postings can only be made to accounts that are not managed on an open item basis. Postings cannot be made to reconciliation accounts (customers or vendors). For asset accounts, consider SAP Note 937940.

� In the posting, you have to specify the amounts explicitly in all currencies. There is no automatic translation of the

of 386


transaction currency into the local currency. This means that you can post explicit currency amounts with the foreign currency posting (F-05).

� Only relevant for migration package 1 - 5: Besides the standard totals table in new General Ledger Accounting (FAGLFLEXT), table GLT0 in classic General Ledger Accounting is also updated in period 0 for postings made to the leading ledger. In this way, when a ledger comparison is performed, the balances in classic General Ledger Accounting match the balances of the leading ledger in new General Ledger Accounting.

� Only relevant for migration package 1 - 5: If you carry out FBCB postings to non-leading ledgers, table GLT0 in classic General Ledger Accounting is not updated in parallel. Therefore the opening balance sheet in new G/L differs from the opening balance sheet in classic G/L at account level. We recommend creating opening balance sheets in classic G/L and new G/L for documentation and certification purposes.

of 386


Activities

Enter the amounts in all currencies. The system does

not automatically convert the amounts into the local currencies. You also have to enter the ledger group of the subsequently introduced ledger in which the posting must happen.

If you do not need manual postings to balance carry-forward, set the status for this activity manually.

Dependencies

If FBCB documents exist, you can no longer reset the migration. If it is essential to reset the migration, you need to reverse all FBCB documents.

It is also no longer possible to reset the balance carryforward for accounts that have been updated from FBCB postings. Please be careful about this because there is no automatic function for checking and repairing this.

1. 4. 5. NGL00_MIGRATION_FROM_CURRENT_YEAR

1. 4. 5.1. NGL03_PROCESS_SPLIT_INFO_FOR_DOCUMENTS (Document Link - /NGL/NGL03_PROC_DOCSPLT_DOCU )

Process Split Information for Documents

Use

of 386


Use this program to generate document splitting information for the documents to be migrated.

Features

Using the worklist of documents to be migrated, the program finds all documents for which document splitting information can be built. This is only the case if the migration plans to be processed have been defined with document splitting. Documents for which the document splitting information has already been built and documents that have already been written to New General Ledger Accounting are not processed further.

The program only finds only migration objects from the worklist that have the following status:

� Status 00: Documents with this status have

not yet been processed by this program in an update run.

� Status 01: Documents with this status have already been processed by this program in an update run, but an error occurred.

Document splitting is performed for each found document. The system first checks for the alternative document splitting settings (as made in activity Additional settings for document splitting in the

of 386


setup phase) for this document, and builds the document splitting information on the basis of these settings. If no alternative Customizing settings are defined, document splitting uses the standard Customizing settings for this document. If the standard Customizing settings lead to errors in building the document splitting information, you can make alternative migration settings for this document (Setup phase -> Additional

settings for document splitting). These migration-specific assignments are only determined and applied by this program; they do not have any effect on the processing of new documents to be posted.

The system uses the found Customizing settings to build the document splitting information for the document to be processed. The documents are processed in the correct chronological order because for postings with clearing or invoice references the clearing information is transferred from the documents referenced. If the system processes the entire migration plan without restrictive selection criteria, the program automatically applies a corresponding sequence for processing.

Each successfully processed document is assigned processing status 10 in the work list for migration documents. Documents for

of 386


which the document splitting information could not be built successfully are assigned processing status 01 and logged in the work list together with the corresponding error message.

1. 4. 5. 2.

NGL03_SIMULATE_DOCUMENT_SPLITTING (Document Link - /NGL/NGLM_SIMULATE_DOC_SPLIT )

Simulate Document Splitting

Use

With this activity, you obtain detailed information for a specific document about the split document as well as about the document splitting rules applied. The document splitting is simulated based on the existing customizing and the active BAdIs.

Prerequisites

You have activated document splitting in customizing. Optionally (as part of the migration from classic general ledger accounting to new general ledger accounting), you can make any necessary settings in the activities for Alternative Settings for Document

Splitting below.

Features

You can display:

� The document after document splitting as well as the document-

of 386


related customizing settings

� The settings relating to business transactions in customizing for document splitting

� The log of the error or warning messages that occurred during document splitting

1. 4. 5. 3. NGL00_TRANSFER_DOCUMENTS_TO_NEWGL

(Document Link - /NGL/NGLM_TRANSF_DOCU_NEWGL )

Transfer Documents to New General Ledger

Use

Use this program to transfer documents from the migration year to new General Ledger Accounting. 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).

Features

The documents are selected from the worklist of documents to be transferred.

Under Output Control, you can select the type of output:

� Display Overview Only: The system

of 386


displays the number of documents processed with errors, the number of documents that were successfully updated but with messages, and the number of documents that were updated correctly.

� Overview + Incomplete

Objects: Besides the overview of processed documents, the system issues a list of all documents for which messages were issued.

� Overview + All Objects: Besides the overview of processed documents, the system issues a list of all documents.

Under Parallel Processing, you can make settings for executing the program using parallel processing. You only have to make all settings in this area if you want to use the program for mass processing and parallel processing.

� In the Package

of 386


Size field, specify how many documents should be processed in a single process. If you specify a package size of 1000, the system always processes 1000 documents in a process.

� Specify a server group if you want to use a certain application server for processing. Making an entry here is optional. If you do not make an entry, all application servers that are currently available in the current SAP system are used as a server group.

� Specify the maximum number of processes to be run in parallel. If you leave this field empty, the program is not performed in parallel.

� Please be aware that the number of parallel processes you enter here need to be available as UPDATE work processes in the current system. It helps to prevent

of 386


deadlock situation.

Notes on performance: To improve system performance, you can reduce the package size and thus utilize the available processes more effectively. Note, however, that this increases the overall workload on the network. Furthermore, you can execute the program in multiple jobs, or by company code or fiscal year, or by a combination of both.

From the work list of documents to be migrated, the program determines all documents that can be transferred to new General Ledger Accounting.

For migration plans without document splitting, the following statuses apply:

� Status 00: Documents with this status have not yet been processed.

� Status 01: Documents with this status have been processed with errors.

For migration plans

with document splitting, the following status applies:

of 386


� Status 10: Documents with this status have already been successfully processed in an update run. Entries have been generated in the document splitting tables.

Documents that have already been transferred to new General Ledger Accounting (status XX) are not selected again for processing.

For the documents to be determined, the program uses the data from the original document and any document splitting information to generate general ledger line items and totals records. The data is always written to all ledgers that are assigned to the company code in the migration plan.

Logging the Processing Status:

� In the worklist of the migration documents, each document that has been successfully processed is assigned processing status XX (completely processed).

� Documents for

of 386


which the document splitting information could not be built successfully are assigned processing status 01 (for migration plans without document splitting) or remain in processing status 10 (for migration plans with document splitting). The documents are logged in the worklist together with the corresponding error message.

1. 4. 5. 4. NGL00_ANALYZE_MIGRATION_STATUS2 (Document Link - /NGL/NGLM_ANALYZE_MIG_STATUS )


Use


The program produces statistics on the processing statuses for the work lists of open items to be

of 386


processed and documents to be transferred. The system displays the total number of migration objects for each status value and the percentage of the migration objects in the work list that have a given status.

Furthermore, the system generates a list of the error messages for the work list objects, showing the total number and the percentage share of the amount of occurrences for each error message.


Selection

� To analyze the processing status of the open items in the work list, select the Open

Items To Be

Prepared indicator.

� To analyze

of 386


the processing status of the documents in the work list, select the Documents

To Be Transferred indicator.

� In the Selections for the

Document area, you can select individual documents or ranges of documents from the work list of the specified migration plan.

� In the Selections for Processing

Status area, you can select migration documents by status or error message from the work list of the specified migration plan.

� Select the level of detail you require:

of 386


� Statistics Only Set this indicator to display just a summary of the analysis results for the selected objects.

� Statistics +

Incomplete Objects

Set this indicator to display a list of the migration objects that have not yet received the migration status Complete(XX) in addition to the summarized analysis results for the

of 386


selected objects.

� Statistics +

All ObjectsSet this indicator to display a list of all migration objects in addition to the summarized analysis results for the selected objects.

Output

� If you have started the program directly, the system displays the data as an interactive list in the ALV grid format. You can use pushbuttons to switch between the evaluation views

of 386


(statistics, error statistics, or document list).

� If you have executed the program in the background, the system prints out a series of sublists for each selected work list, depending on the selected level of detail.

Activities

Depending on the level of detail you select, you can use the following display and navigation options for each work list (open items to be processed or documents to be transferred):

� Display Complete Statistics

� Display Error Statistics

� Display Object List

� You can

of 386


switch to the analysis results for the other work list.

� From the object list, you can display other details:

� For transferred documents, you can display the document splitting results independent of the ledgers.

� Document display using the Document Numberfield.

� Log display for migration-specific document adjustment using the Adjustment field.

� Message documentation display using the Message

of 386


Text field.

1. 4. 5. 5. NGL00_CONFIRM_TRANSFER_DOCU_TO_NEWGL

(Document Link - /NGL/NGLM_CONF_TRASF_DOC_NGL )

Check Completeness of Transfer of Documents to New General Ledger

Use

The program for this activity checks if all documents from the worklist were transferred to the new general ledger.

Prerequisites

The worklist that has been created

of 386


at beginning of the migration phase is complete.

Activities

If open items are not yet processed, run the function for activity Transfer Document

to New General

Ledgeronce again.

1. 4. 5. 6. NGL00_COMP_SRCTRG_LEDGERS_CURYEAR2 (Document Link

- /NGL/NGLM_COMP_SRCTRG_LEDCUR )

Compare Source and Target Ledgers for Documents from Current Year

of 386


Use

To ensure and document the correctness of the entire migration, you have to compare classic General Ledger Accounting against new General Ledger Accounting by means of a ledger comparison. The ledger comparison checks whether the values in the specified source and comparison ledgers agree for the current fiscal year. The

of 386


comparison is made at company code and account levels. You can also include additional fields (such as business area) in the comparison.

Since you can transfer data selectively from multiple source ledgers, you need to take this into account during the ledger comparison.

By using the option Other key

of 386


figure, you can switch between various currencies.

Activities

Perform a ledger comparison for all relevant combinations and upload the lists to the migration cockpit for documentation purposes.


Use this report if, during the implementation phase of new General Ledger Accounting, you still update the tables

of 386


of classic General Ledger Accounting (GLT0) in parallel for non-ledger specific postings or postings to the leading ledger. This report allows you to compare the totals records in the tables for new General Ledger Accounting against the totals records in the tables for classic General Ledger Accounting (GLT0).

of 386


1. 4. 6. NGL00_EVALUATION_PHASE

1. 4. 6.1. NGL00_ANALYZE_MIGRATION_STATUS (Document Link

- /NGL/NGLM_ANALYZE_MIG_STATUS )


Use


The program produces statistics on the processing statuses for the work lists of open items to be processed and documents

of 386


to be transferred. The system displays the total number of migration objects for each status value and the percentage of the migration objects in the work list that have a given status.

Furthermore, the system generates a list of the error messages for the work list objects, showing the total number and

of 386


the percentage share of the amount of occurrences for each error message.


Selection

�

�

of 386


�

�

of 386


�

of 386


of 386


Output

�

�

of 386


Activities

Depending on the level of detail you select, you can use the following display and navigation options for each work list (open items to be processed or documents

of 386


to be transferred):

�

�

�

�

�

of 386


of 386
