SAP System Landscape Optimization (SLO)

Service Description

Currency Conversions

Currency Conversions
As-Is Situation

You consider a currency change in your SAP system, for example for the following reasons: Your company has bought another company. Before the data from the SAP system of the acquired company can be integrated into the SAP system of your company, the group currency for the acquired company must be changed in accordance with the currency definitions for your company. You would like to change the local currency for your company. (For example, even companies in non-participating countries may have to use the Euro as a local currency.) The country in which your company is located changes its currency. (Example: In Ecuador, the Sucre was replaced by the US-Dollar.) The currency of the country in which your company is located is devaluated. This change must be reflected in the SAP system of your company. You plan to introduce a unified parallel local currency in your company. To bring your accounting practices in line with IAS/US-GAAP (FASB 52), you need an additional functional currency that differs from the national currency. You plan to restructure your SAP system, e. g. by merging controlling areas. As a prerequisite, however, all relevant organizational units need to use the same currency, which is not the case at the moment. You need to change the number of decimal places for a currency in your SAP system or to make other technically

motivated changes to a currency in your SAP system.

Currency Conversions
The Way to the To-Be Situation

SAP System Landscape Optimization (SLO) offers currency conversions for the following change requirements: Generic local currency conversion o Selectively by organizational units o For any source currency o For any target currency Implement, change, or delete parallel local currencies Decimal point conversion Group currency conversion or individual change of: o Controlling area currency o Operating concern currency o Currency for profit center accounting o Controlling object currency o Parallel ledger currency o Depreciation area currency. For renaming currency keys, SLO offers a specific Conversion Service. For further information on this service, see the separate service description on Currency Key Rename. Beyond this offering, other requirements can be met by means of customer-specific projects. However due to technical limitations not all currency changes that are theoretically possible can actually be implemented with a reasonable amount of effort. Consequently, a systematic analysis of the current situation and the requirements must be made before the detailed planning for a currency change project can start.
Background Information on Currencies and Currency Conversions

in an SAP system. The currency type defines the role of the currency. Example: A company receives an invoice in currency Yen (currency type: transaction currency). The companys currency for accounting purposes is Euro (currency type: company code currency), consequently the invoice will be posted in Euro. The currency for controlling purposes is US-Dollar (currency type: controlling area currency), so the invoiced amount will also be stored in USD. There are two groups of currency types: transaction currencies and local currencies. Examples for local currencies are: Accounting currency (often simply referred to as local currency) Parallel currencies in accounting Depreciation area currencies in asset accounting Controlling area currency CO object currencies (for orders, cost centers) Group currency (= client currency) Currency for profit center accounting Operating concern currency Ledger currency The purpose of local currencies is to have a constant measuring unit for reporting, comparisons and further processing that supplements the currencies of the individual business transactions (transaction or document currency). To ensure that a local currency still serves these purposes after a currency conversion, a typical conversion will not only consider future business transactions, but will also cover historical data and guarantee that all relevant data will be changed in a consistent way.

For a given business transaction, there may be data in different currencies or valuations

Currency Conversions
Under specific circumstances, the necessary changes can also be made without actually executing a currency conversion. Examples: If the planned change affects only a few documents, it would be possible to repost these documents and them or correct them manually. For objects such as internal orders that have a limited lifetime anyway, it may make sense to define a new internal order in the necessary new currency and bill to this order in the future. Instead of changing the currency for an organizational unit, one could also re-create the relevant organizational unit with the new currency, transfer the relevant data from the original organizational unit to the new one, and use the new unit instead of the old one in the future. However this may require a disproportionate amount of effort, and historical data will be lost. For example, the group currency is defined at client level. As a consequence, if the group currency was to be changed by this method, a new client would have to be created, and this would require the same amount of work as a complete implementation project.
Basic Information Relevant for All Currency Conversion Services

change rate. Depending on the scenario, it is possible to define time-dependent exchange rates (When was an item posted?), but not exchange rates for individual objects. Thus, it is not possible to use different exchange rates with different profit centers or to use one exchange rate for converting the balance sheet and another exchange rate for converting the profit and loss statement. The two most important factors in a currency conversion are: o What exchange rates will be used for the conversion? o To what extent is reconciliation for removing translation differences (see below) and exchange rate differences possible and required? There is necessarily a trade-off between the number of different exchange rates and the possibilities for reconciliation. Consequently, you need to consider the importance of each of these two factors in your project and to find out how much work would be required to reach the different possible targets. The SLO consultants can support you during the consideration process; the final decision, however, is up to you. In individual cases, it will not be possible to define the optimal solution until the results of a first test conversion are available. Translation differences will necessarily occur as a consequence of a currency conversion even if all values are translated using the same exchange rate. In some cases, it will not even be possible to correct the differences manually with a reasonable amount of effort after the conversion.

In general, the approach for all currency conversions closely resembles a Euro local currency conversion project. As a consequence, the experience gained during a previous Euro conversion project will be very helpful in a currency conversion project. During a currency conversion, the existing values are translated from the old currency to the new one using an ex-

Currency Conversions
With few exceptions, all values will be converted without any relation to other values. As a consequence, related data such as line items and totals records will no longer fit due to exchange rate or translation differences, and settlement postings may be inconsistent after the conversion. It will not be possible to reconstruct all aggregated data or derived data from the given data with a reasonable amount of work. Consequently, the reconciliation effort will normally focus on differences that are critical from the business or technical point of view as defined in the scope of service for the certified SAP Euro solution. (This means, for example, that data from past fiscal years will only be reconciled at request.) Currencies are suitable as measurement and valuation units only if their definition remains constant and does not change over time. This is why the SLO currency conversions cover the complete history of the system and why the conversion cannot be limited to certain periods of time (e. g. individual fiscal years). Scope of service: Unlike other (transaction-based) methods, SLO currency conversions operate at table and field level directly in the database. This also means, for example, that no change documents are created during a currency conversion. After the conversion, the system will look almost (!) as if it had always been in the new state - almost for one thing because the history can only be adapted based on certain assumptions, and for another because certain adaptations are actually not desirable. Example 1: In connection with a settlement, differences that partly resulted from exchange rate differences were posted. Depending on the exchange rate that is used, this transaction may look rather different after the conversion: The loss from exchange rate fluctuation may have turned into a gain, which would have to be posted to a different account. The currency conversion cannot cover dependencies of this kind. In fact this would not even be desirable, because otherwise it would result in a change annual financial statements that had already been audited. Example 2: In asset accounting as well as in materials management, there are technical limitations regarding postings that refer to the past. Here, adaptation is possible only for data that is technically available. To ensure data consistency across all applications under these circumstances (that is, considering the limitations described above), SLO uses standardized procedures wherever possible. The conversion package is particularly important. It includes standardized methods, parameters, programs and tables for a given conversion task. The SLO consultants adapt this package to meet the requirements in the given scenario (that is, the specific situation in your SAP system). This package is used to execute the conversion (first in a test environment, then in the production system). Standard tables are automatically included in the conversion. Tables that were created in your company as well as modifications of standard tables can also be converted (for more information on customer-

Currency Conversions
specific developments, see below). Prior to the conversion, the scenario is analyzed. After the conversion follows the reconciliation phase, during which the data is made consistent again wherever it is necessary and feasible. In addition, SAP takes care of the co-ordination for the a. m. activities. Customer-specific developments: Customer-specific developments should also be converted to ensure data consistency. During the test conversion, the relevant tables will be found and included in the conversion process. This is particularly easy if the relevant fields refer to domains that are standard domains for the relevant objects in the given release. In any case, input from the responsible persons in the application departments of your company is necessary for successful conversion of customer-specific objects (tables as well as programs, reports and interfaces). Due to the way a conversion works, only data that is stored in tables of the SAP system can be covered. Consequently, the following objects are not converted: o IDocs o Dunning runs and payment runs o Batch Inputs o Transports o Other types of flat files. Archives, however, can be converted using additional SLO services. Performance: For performance optimization activities (particularly regarding operating system, database and disk system), we collaborate closely with you to define the necessary steps. For more information on the necessary system settings, se Note 534036. If your database is very large or if the test conversion shows that performance bottlenecks are likely to occur during the production conversion, we recommend additional technical consulting as well as organizational activities, and we will support you in time planning for the project. It is not possible to convert several clients simultaneously. In fact, this is no problem because the conversion technology uses the system resources very efficiently anyway, so that the sequential conversion will not cause any unnecessary loss of time.

Additional Information on Different Types of Currency Conversions

Generic Currency Conversions The services for generic local currency conversion are based on the SAP Euro solutions. With these services, changes from any original currency to any new currency can be facilitated. In addition, it is possible to execute the conversion only in some of the organizational units of an SAP system (e. g. for some, but not all of the company codes). The services include provision and support of the technical solution for generic currency conversion as well as a training on the differences to the Euro solution. If required, we offer additional consulting services, e. g. in the areas of project planning and project management, adaptation of the solution to specific requirements (customer-specific development, industry solutions), preparations (e. g. elimination of differences), execution of the test and production conver-

Currency Conversions
sions, and shortening of the system downtime. As the solutions for generic currency conversion are based on the SAP Euro solution, only one fixed exchange rate can be used for the conversion (see Note 120094). Parallel Local Currency Parallel local currencies can be used in financial accounting (SAP component FI) and in asset accounting (SAP component FIAA). Introducing a parallel local currency in FI In general, the procedure for introducing a parallel local currency looks as follows: If a data record already contains the amount in the new parallel local currency, this amount is copied to an empty local currency field in the same data record. If a data record does not yet contain the amount in the new parallel local currency, the value in the first local currency s translated accordingly and written to an empty local currency field in the data record. Here (unlike a generic local currency conversion) you can specify exchange rates by year, by period or by day. However reconciliation will get much more difficult if you use several different exchange rates. With regard to reconciliation between line items and totals records, the general conditions as defined for the Euro solution apply. As far as reconciliation between different SAP components (particularly FI and CO) is concerned, it is important to note that reconciliation at line item level is not possible. In addition, the service includes reconciliation at totals levels only for cases where inventory values are updated e. g. profit center accounting, but no controlling or profitability analysis. If the CO-FI reconciliation ledger is active in your SAP system, standard transactions can be used for reconciliation. Depending on the given settings in your SAP system, the first step will be to define a new ledger for table GLT0 to which the transaction data in the parallel currency can be written. Changing a parallel currency in FI The procedure for changing a parallel local currency is the same as for introducing a parallel local currency. The new values can be taken either from the existing parallel currency or from the mandatory first local currency. A change of the currency type for the parallel currency equals a new implementation of the parallel currency plus deletion of the previous parallel currency. Deleting a parallel local currency in FI To achieve this, all relevant table fields are initialized, and data records that are only relevant for the parallel currency are deleted.

Currency Conversions
Introducing a parallel local currency in FI-AA In asset accounting, the parallel currencies are depicted in valuation areas. The chart of depreciation specifies which valuation areas can be used in a given company code. To introduce a new parallel currency you need to define a new additional valuation area for the relevant charts of depreciation. In this environment, amounts in parallel currencies are defined basically by the depreciation rules and not so much by the exchange rates. Consequently, the necessary changes are implemented by means of standard R/3 functions (and not by translating existing amounts). Example: If you have straight-line depreciation for assets in valuation area 01, depreciation must also be straight-line in the parallel valuation area irrespective of any exchange rate fluctuations. For assets under construction, deactivated assets and group assets, there are specific conditions that need to be analyzed in each individual case. Changing a parallel local currency in FIAA To change a parallel local currency in FI-AA, the previous currency is deleted, and the new currency is introduced. Deleting a parallel local currency in FIAA To this purpose, the relevant parallel valuation areas are deleted. General remarks on parallel currency handling in FI-AA With regard to the fact that valuation areas are defined at chart of depreciation level, the parallel currency settings must be identical for all company codes that are assigned to a given chart of depreciation. Depending on which functions are used (particularly if settlements to assets under construction are made), substantial changes in FI-AA customizing that go beyond the service described here may be advisable or even required. Due to technical conditions, reconciliation is possible only for the current fiscal year. Depreciation is re-calculated, and the delta is posted to the current period. Changing currency settings in asset accounting (FI-AA) Currency conversions in asset accounting are only supported to the extent described in the section on parallel local currencies. Individual solutions can be worked out on request. Decimal Point Conversion The service Decimal Point Conversion makes it possible to change the settings for decimal places even if postings have al-

Currency Conversions
ready been made in the relevant currency. It is particularly valuable if the affected systems contains so many documents that the target situation cannot be achieved by a reasonable amount of manual reverse posting work. The procedure generally is to rename the currency that was configured incorrectly. Thus, the ISO code for this currency becomes available again and can be reintroduced in the system this time with the correct settings. Consequently, the prerequisites defined for the services Generic Local Currency Conversion and Currency Key Rename also apply for the service Decimal Point Conversion. If the affected currency was used as a local currency, an additional local currency conversion (as described above) will be required e. g. for resetting the currency of an affected company code to the ISO code. (The values are not changed and the decimal places are not adapted until in this step.) Values in transaction currency will not be changed because changing them would amount to a violation of the document principle. For further information, see SAP Notes 434349 and 137626. With regard to the fact that decimal places for currencies are defined at system level, while a currency conversion is always executed at client level, several conversions are required if your SAP system contains more than one client If the affected system is part of a system group, the interfaces may have to be adapted accordingly so that the decimal point conversion will not have any adverse effects on data transfer. Group Currency Conversion The group currency (or client currency) is hardly ever used directly. Instead, several other currency types can refer to the group currency: Controlling area currency Currency for account-based profitability analysis Currency for profit center accounting Parallel currencies in the General Ledger Ledger currencies Currencies for parallel valuation areas in FI-AA Parallel valuation in Material Ledger Currency for consolidation (FI-LC, ECCS)

In addition, other currency types (for example, the currency for costing-based profitability analysis) can have the same settings as the group currency without actually referring to it. It may be desirable to change these other currency types as well when the group currency is changed. Consequently, changing the group currency amounts to a combination of several currency conversions (see the respective chapters).

Currency Conversions
Controlling Area Currency Conversion Up to three currencies are used in controlling: controlling area currency, object currency and transaction currency. The controlling area currency is also the leading currency for the project system and for account-based profitability analysis. During a controlling area currency conversion, all relevant values are converted for the relevant controlling areas. Variable exchange rates can be used. However translation with variable exchange rates is possible only for data that has suitable time references. Example: Some plan data is only saved with reference to a year. If you want to do the translation using day rates, you need to define the date whose exchange rate will be used. For example, you could specify the first day of the year or the last day of the previous year. Another issue is aggregated data, e. g. monthly totals: When day rates are used, differences between line items and totals will occur, and some of these differences cannot be reconciled with a reasonable amount of effort. Reconciliation is possible in the following areas (subject to the limitations described above): Recreation of the totals records Reconciliation of settlement (depending on the scenario) Recreation of project info database Recreation of FI-CO reconciliation ledger. Reconciliation at line item level is not included. For cross-application settlement (e. g. settlement for projects regarding assets under construction) problems may occur that need to be resolved on project basis. Note: If the controlling area currency has currency type group currency, all data (across all applications) in group currency needs to be converted. Alternatively, the currency type could be changed; however this is not possible in all cases, because some functions will only be available with specific currency types (see Note 120826). Change Currencies in Profit-Center Accounting (EC-PCA) Though the basic organizational unit for profit center accounting is the controlling area, the currency type (and consequently the currency) for profit center accounting can be selected freely. Values for the following are updated: document currency, company code currency, and currency in profit center accounting. The change covers all data that refer sto the currency in profit center accounting. Consequently, the selection criterion is the controlling area, and it is not possible to use different exchange rates for profit centers that belong to the same controlling area. Depending on which currency type is used, it may not be possible to do a separate conversion in profit center accounting (see the information on controlling area currency conversion).

Currency Conversions
You can use standard transactions for reconciliation in the following areas: Recreation of the totals records Reconciliation with financial accounting same currency in different applications. If this is the case in your project, it is necessary to check which additional conversions are required. The conversion covers all data in operating concern currency. Optionally, the totals can be recreated. The service does not include reconciliation with integrated modules because CO-PA only receives and reports data without any subsequent processing. For some parts, reconciliation can be achieved by deleting the data and re-transferring it from the source applications. However long runtimes may cause problems. If your project should include reconciliation with integrated modules, we need detailed information on the data transfers. Based on this information, we will work out a project-specific solution. Change Object Currencies in Controlling In controlling, each data record has fields for the controlling area currency, the object currency, and the transaction currency. The object currency must be the same as the company code currency unless the controlling area itself uses the company code currency. Consequently, an object currency change is relevant only in projects that involve changing the currency type for controlling. This can be necessary either if the controlling area currency itself is to be changed or if the controlling area currency will no longer be identical with the first local currency for all company codes because additional com-

To do the reconciliation, we need into know which data is transferred to profit center accounting by which method. Change Currencies in Profitability Analysis (CO-PA) There are two types of profitability analysis which can be used in parallel: account based profitability analysis and costingbased profitability analysis. From the technical point of view, accounting-based profitability analysis is depicted in controlling (CO) and uses document currency, object currency and controlling area currency (see the information on changing the controlling area currency). For costing-based profitability analysis, up to four currencies or valuations are used in parallel: Operating concern currency, legal valuation Operating concern currency, profit center valuation Company code currency, legal valuation Company code currency, profit center valuation

Costing-based profitability analysis has its own currency type and is thus independent of all other currency settings in the system. Nevertheless it may make sense to use the

Currency Conversions
pany codes have been assigned to the controlling area. If the object currency was used already, the first step would be to check how many objects would be affected by the conversion. If the number is very small, it might make sense to close or archive the relevant objects and recreate them. Otherwise, the object currency can be converted. The procedure is the same as for a controlling area currency conversion. For this type of conversions, it is particularly important that all necessary exchange rates are maintained correctly.
Prerequisites that Apply for All Currency Conversion Projects:

A conversion project is much easier to handle if the Project Team does not change in the course of the project. From your companys side, there should be one person who co-ordinates the project starting from the preparations and up to the final tests after the production conversion. Besides, we need one contact person from System Administration who is available for the whole project duration and particularly during the test and production conversion phases. In particular, the tasks for system administration in connection with a currency conversion include: o Build up and operate a test system or test system environment o Maintain system settings in accordance with the administrators ex-

perience and information provided by SAP o Carry out transports o Make data backups o Monitor system performance during the conversions o Schedule and cancel jobs o Create users and authorizations o Manage interfaces. In addition, people from the relevant application departments must be involved in the testing procedures. The project language will normally be English or German. If the conversion will affect financial accounting, make sure to involve the responsible auditor in the project and to observe the applicable rules and procedures for documentation. The course of the production conversion depends to a large degree on the results of the test conversion. That is why the following prerequisites are decisive for the success of the project: o The test system must be available exclusively for conversion purposes during the whole project duration, that is, no projects (not even tests) must be run in the system at that time. o The hardware of the test system must be as similar as possible to that of the production system. If the performance of the test system is much slower than that of the production system, the time required for the test conversion will be considerably longer than planned, and as a consequence the project may be delayed. o The test system must be a current copy of the production system. In

Currency Conversions
particular, the Customizing and the table definitions in the test system and in the production system must be identical. o It must be possible to carry out transports from the test system into the production system.
Project Steps

The SLO consultant needs extensive authorization (e. g. SAP_ALL) in all systems that you want to convert. This is required because for example before the start of the data conversion phase he or she needs to lock all users who do not belong to the project team. Also, it is necessary for the SLO consultant to monitor the conversion using standard transactions, and to do spot checks in the converted tables. In addition, the SLO consultant must be allowed to modify tables and programs (at least temporarily). As some settings for go-live cannot be transported, the SLO consultant needs to get the authorization for making changes directly in the production system (system change option) for about two days before the go-live.

A project for changing currency settings in an SAP system consists of the following phases: 1. Scoping & Conceptual Design Analysis of the initial situation and the desired target situation 2. Business Blueprint Drawing up the detailed concept 3. Realization Preparations and test of the planned changes 4. Go-live & Support Implementation of the changes in the production system, post-processing work, and project completion For some of the tasks within the phases, pre-defined methods and programs are available, while others require customerspecific solutions. The share of customerspecific and pre-defined solution components in a project depends on the prerequisites in the given project. More detailed statements on this as well as on the likely project duration cannot be made until a thorough analysis has been completed. SAP System Landscape Optimization offers comprehensive consulting services as well as standardized solutions (wherever possible) for all project phases. 1. Scoping & Conceptual Design Depending on the specific requirements in a project, a more or less extensive analysis is required to clarify whether the project is actually feasible, to determine the project scope, and to specify the required amount of work. General questions that should be addressed even before we can send you a detailed quotation are for example: How many clients in how many systems (production, quality assurance, consoli-

A large part of the product work can be done via remote connection, and with regard to efficiency it is actually recommendable to do as much work as possible via remote connection (instead of onsite). As a prerequisite for development support, a remote connection to all affected systems is required. Any software that is needed for the project will normally be provided via SAPSERV<X>.

Currency Conversions
dation, development, customizing) do you plan to convert? What is the size of the database you want to convert? Do you plan to convert archives as part of the conversion project? Which SAP R/3 applications do you use? In particular, we need to find out if any data from SAP component HR must be taken into consideration in the project. Do you use Industry Solutions (IS)? If so, we need to find the IS tables that contain relevant data and make sure that they are included in the conversion. Does the project affect any mySAP components apart from R/3, such as BW, SEM, CRM etc.? Do you use interfaces, particularly ALE scenarios? If so, it is necessary to determine at an early stage of the project what consequences the planned conversion will have with regard to the existing interfaces. If necessary, the interfaces will have to be adapted accordingly. Do you use variants in Report Painter and Report Writer? If so, you should check beforehand (for example by means of the SLO Report Variant Analysis) if these variants contain any data that needs to be changed. Is any data that will be converted used directly in coding? If so, the responsible persons in your company should find this coding before the conversion (for example by means of SLO services Customer-Specific Coding Scan) and adapt it so that it reflects the future status. Does the system that you want to convert contain any modifications or customer-specific development, particularly in the Z* namespace, that may be affected by the conversion?

Based on the results of the analysis, we draw up the project schedule together with you and provide you with a quotation for the implementation of the planned changes. 2. Business Blueprint Together with SAP, you define the detailed objectives of the conversion. The responsible persons in your company work out the test procedures. For more information on testing, see the following sections. The test system will also be built up in this phase. 3. Realization Existing solution modules are adapted, and new solutions are developed in accordance with the requirements defined during the Business Blueprint phase. With these solutions provided by SLO, several test cycles are executed. First, all steps of the conversion are carried out in a copy of the production system (test conversion). The conversion process includes the following steps: Backup before conversion Preparations for testing (lists) Conversion Reconciliation Verification Acceptance Backup after conversion The production conversion cannot start until the responsible persons in your company

Currency Conversions
have checked the results of the test conversion and confirmed that they are correct. As a general rule, it is fairly easy to avoid post go-live issues, but very hard (or even impossible) to correct them afterwards. On average, a cycle takes four weeks. Consequently, the minimum project duration (if an existing solution can be reused) is eight weeks. However depending on the complexity of the requirement a currency conversion project may also take several months. 4. Go-live and Support During conversion of the production data, the affected SAP system must be locked to all other activities. Consequently, the production conversion is usually executed during a weekend. The general procedure for the production conversion is basically the same as for the test conversion (see under section 3 Realization). However based on the results of and the experience from the test conversion, the schedule for the production conversion and the subsequent check of the conversion results can be much tighter, so that the production conversion can normally be completed during one weekend. Due to the limited amount of available time, only a minimum selection of important tests can be executed after the production conversion. After the conversion, the system cannot be released for productive operation until you have confirmed that the results of the conversion are correct. Other non-production systems (development systems etc.) can be converted during the weeks before or after the production conversion. Alternatively, you can rebuild these systems after the conversion. The responsible SLO consultants will be available for one to two weeks after the production conversion to provide support in post-processing if required.
Additional Information on Testing

After the test conversion, the responsible persons in your company need to thoroughly check the results of the conversion to make absolutely sure that all objects (including customer-specific ones) have been converted correctly, that there are no inconsistencies and that all processes work in the same way as before the conversion. Exactly which tests are required or make sense for a given SAP system depends to a very large extent on the configuration of that system and on the business processes. As a consequence, it is not possible for SAP to provide generic procedures or checklists for testing, and it is up to the responsible persons in your company to define suitable test procedures. On request we can offer you comprehensive support in defining the optimal testing procedures for your specific requirements. A major difference between currency conversions and other projects (like upgrades or rollouts) is that a currency conversion changes neither functions nor data structures. Instead, the data itself is changed, so that existing test procedures can be applied only to a limited extent and the responsible persons from the affected application departments need to define and execute specific tests. There are two different types of tests: process-related tests and before/after comparisons.

Currency Conversions
In terms of process-related testing, you need to make sure that all critical processes in your company are checked to guarantee that they still work as required. Examples: Month-end closing Business-processes in the context of period-end closing: Allocations (assessments, distributions, periodic repostings, activity allocations, settlement of internal orders etc.) Cross-application processes (e. g. in FI and CO) Process chains, e. g. original document follow-on document, document and reversal, document and clearing etc. Account assignment to cost centers, profit centers etc. Before/after comparisons are made to check whether only the defined changes were made in the system. In the appendix, you can find an overview of standard lists which should be a mandatory part of the testing. In general, it is important to make the spot checks for aggregated data as well as for detail data. Documentation of the test procedures and test results is a mandatory part of a conversion.
Appendix Lists for Testing

Print the lists as described below (plus other reports that are used in your company and that might be affected by the conversion) once before and once after the conversion and compare the values from before with the values from after the conversion Regarding the time when the lists should be printed before the conversion, the following aspects must be taken into consideration: The values in the lists can vary if any transactions are executed between the time when the lists are printed and the actual conversion. If the lists are printed too early, it will be difficult to determine after the conversion whether a difference between the lists was actually caused by an error in the conversion, or whether it results from transactions executed after the lists were printed and is consequently uncritical. On the other hand, printing the lists may take fairly long, so that it is not possible to print the lists immediately before the conversion. As a consequence, we recommend that you print the lists for past fiscal years and closed posting periods during the week before the conversion and print only the lists for open posting periods during the system lock. It makes sense to choose an alternative output currency when printing the lists before the conversion. Financials Lists Account balance for customers (RFDSLD00) Balances before and after conversion must match Account balance for vendors (RFKSLD00) Balances before and after conversion must match Account balance for G/L accounts (RFSSLD00) Balances before and after conversion must match

Currency Conversions
List of open items for customers (RFDOPO00) Open items before and after conversion must match List of open items for vendors (RFKOPO00) Open items before and after conversion must match List of open items for G/L accounts (RFSOPO00) Open items before and after conversion must match Asset history sheet (RAGITT01) and List of stock values for assets (RABEST01) Values before and after conversion must match List of inventory management for inventory account (RM07MBST, as of Release 3.0F) Amounts before and after conversion must match Special Ledger (RGUCOMP1 up to Release 3.1H, RGUCOMP4 as of Release 3.1I) Totals records for ledgers before and after conversion must match

Line item report for cost centers (plan, actual, commitment), internal orders, business processes, profit centers Profit centers: open items, payables

Controlling Lists

Master data reports on: Cost centers, cost elements, internal orders, business processes, statistical key figures, activity types Test CO document flow, e. g. using transaction KSB5 (controlling documents for actual costs) Comparison reports for cost centers (actual/actual, plan/actual, target/actual), business processes, profit centers Planning reports for cost centers, activity types, internal orders business processes Activity prices, price reports for business processes

SAP Deutschland AG & Co. KG Neurottstrae 15 D-69190 Walldorf Germany T +49/6227/74 37 84 F +49/6227/7 82 89 58 www.sap.com http://service.sap.com/slo

2006 by SAP AG. All rights reserved. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (SAP Group) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.