Application Help Asset Accounting Multiple Calendar Tool 102014 FV 1.2

7/21/2019 Application Help Asset Accounting Multiple Calendar Tool 102014 FV 1.2

1/24

Application Help

Document Version: 1.2 Final

Date: October 20, 2014

CUSTOMER

Asset Accounting Multiple Calendar Tool 1.0

Application Help


2/24

Application Help CUSTOMER


User Guide Version: 1.2 Final

October 20, 2014

2014 SAP SE or an SAP affiliate company. All rights reserved. 2

Typographic Conventions

Type Style Description

Example Words or characters quoted from the screen. These include field names, screen titles,

pushbuttons labels, menu names, menu paths, and menu options.

Textual cross-references to other documents.

Example Emphasized words or expressions.

EXAMPLE Technical names of system objects. These include report names, program names, transaction

codes, table names, and key concepts of a programming language when they are surroundedby body text, for example, SELECT and INCLUDE.

Exampl e Output on the screen. This includes file and directory names and their paths, messages,

names of variables and parameters, source text, and names of installation, upgrade and

database tools.

Example Exact user entry. These are words or characters that you enter in the system exactly as they

appear in the documentation.

Variable user entry. Angle brackets indicate that you replace these words and characters with

appropriate entries to make entries in the system.

EXAMPLE Keys on the keyboard, for example, F 2 or ENTER.


3/24




October 20, 2014


Document History

Version Status Date Change

1.2 Final October 20, 2014 Application help updated for Support Package 02


4/24




October 20, 2014


Table of Contents

1 Using the Asset Accounting Multiple Calendar Tool ......................................................... 6

1.1 Benefits of Using the Tool............................................................................................................................ 6

1.2 Integration with Standard Components ........................................................................................................ 7

1.3 Feature Overview ........................................................................................................................................ 8

2 Mirroring of Data............................................................................................................. 10

2.1 Process Overview ..................................................................................................................................... 10

2.2 Prerequisites ............................................................................................................................................. 10

2.3 Mirroring Asset Master Data and Transactions ........................................................................................... 112.4 Displaying Mirrored Objects ....................................................................................................................... 13

2.5 Dealing with Exceptions ............................................................................................................................ 14

2.6 Checking the Consistency Between Original Company Code and Mirror Company Code ............................ 16

2.7 Resetting the Company Code in the Test System ....................................................................................... 16

3 Transferring Balances from the Mirror Company Code to the Original Company

Code ............................................................................................................................... 17

3.1 Process Overview ..................................................................................................................................... 17

3.2 Prerequisites ............................................................................................................................................. 19

3.3 Transferring the G/L Balance..................................................................................................................... 20

3.4 Checking the Balance Transfer .................................................................................................................. 21

4 Appendix: Main Transaction Codes................................................................................. 23


5/24




October 20, 2014


Table of Figures

Figure 1: Example of Shifted Fiscal Year Variants .................................................................................................... 6

Figure 2: Integration Scenario using New G/L Accounting ........................................................................................ 8

Figure 3: Handling Exceptions ............................................................................................................................... 15

Figure 4: Result of G/L Balance Transfer ............................................................................................................... 19

Figure 5: Account Mapping Customizing (Example) ............................................................................................... 19

Figure 7: Log of the G/L Balance Transfer Check ................................................................................................... 22


6/24



Application Help Version: 1.2 Final

October 20, 2014


1 Using the Asset Accounting Multiple

Calendar Tool

1.1 Benefits of Using the Tool

Global corporations are often faced with the challenge of addressing different accounting requirements in different

countries. In addition to dealing with different accounting principles, they may also be required to use different fiscal

year variants at group and local level.

Example

According to the regulations at group level (for example, IFRS), a corporation may be required to use a fiscal

year variant that follows the calendar year (January December). However, to report according to local laws,

a fiscal year variant that starts in April is required.

Alternatively, another corporation may be using a fiscal year variant that starts, for example, in February, on

group level. However, local regulations also require use of a fiscal year variant that follows the calendar year.

Figure 1 shows how a posting affects different periods or even fiscal years depending on the fiscal year variant in

use:

Figure 1: Differing Fiscal Year Variants

In the example above, an asset acquisition is posted on January 18, 2014. In the group fiscal year, which does not

correspond with the calendar year, the posting falls into period 12 of fiscal year 2013. In contrast, in the local fiscal

year, which is identical with the calendar year, the posting falls into period 01 of fiscal year 2014.


7/24




October 20, 2014


When different fiscal year variants are used for global and local reporting purposes, system restrictions may apply

that limit the business processes supported, particularly as they relate to the valuation of fixed assets and their

presentation in the asset history sheet.

In standard SAP Asset Accounting, each document can only be assigned to one fiscal year. From the second fiscal

year variants perspective, both the reporting (for example, asset history sheet) and certain values (for example,

depreciation amounts) are maybe incorrect. Thus, the values posted to the general ledger are also wrong.

The reason for the wrong posted values according to the different, second fiscal year variant is that the standard SAP

ERP Asset Accounting component (FI-AA) does not allow you to use different fiscal year variants in different

depreciation areas if the start and end dates of the fiscal years differ. The asset accounting mult iple calendar tool,

an SAP Custom Development solution, supports you in bridging this gap in the standard SAP ERP Asset

Accounting com ponent (see also SAP Note 844029).

To use the asset accounting multiple calendar tool, you first create a second company code, referred to as the

mirror company code. The different fiscal year variant is assigned to the mirror company code. The tool posts

certain asset master data and FI-AA values from the original company code to the mirror company code. Other

posting data that does not contain asset information is not needed in the mirror company code and is therefore not

mirrored by the tool.

The correct asset accounting values according to the different fiscal year variant are available in the mirror company

code. The correct values for all non-asset accounting accounts are available in the original company code.

Note that you must create a mirror company code for every original company code.

Optionally, you can post the balance of all relevant asset accounts back from the mirror company code to the original

company code. As a result, the general ledger data for these relevant accounts is available in the original company

code.

1.2 Integration with Standard Components

The asset accounting multiple calendar tool is based on SAP ERP 6.0, up to and including enhancement package 7.

The tool supports both classic General Ledger Accounting and new General Ledger Accounting.

Note

If you have activated business functions that enhance the FI - GLorFI - AAfunctions (for example, business

function FI N_AA_PARALLEL_ VAL) and you want to use the asset accounting multiple calendar tool, this

could result in additional development effort that is subject to a fee. In this case, please contact your SAP

consultant.

Before using the tool, make sure that the Financial Accounting (FI ) component is active, including the following

subcomponents:

o Asset Accounting (FI - AA)

o General Ledger Accounting (FI - GL)

Figure 2 illustrates the integration scenario.


8/24




October 20, 2014


Figure 2: Integration Scenario using New G/L Accounting

1.3 Feature Overview

Mirroring Data from Original Company Code to Mirror Company Code

Using new General Ledger Accounting and the ledger approach (that is, using different new G/L ledgers to represent

parallel accounting), the basic assumption is that there is at least one non-leading ledger with a different fiscal year

variant assigned. Thus, the general ledger data originating in Asset Accounting (FI - AA) is not correct.

The asset accounting multiple calendar tool allows you to copy nearly all master data and most asset documents

from the original company code to a mirror company code. In the mirror company code, all postings are correct from

the second fiscal year variants perspective.

The system posts the data using the same dates as in the original company code. After the mirroring of asset

transactions, the results in the mirror company code will be different from the results in the original company code. Of

course, this is the desired effect of the underlying differing fiscal year variant.

Limitations

There are certain limitations to using the tool. The mirror company code does not include all values to create

a complete balance sheet. Only asset accounting data is posted and stored in the mirror company code. So,

in the mirror company code all standard FI - AA reports can be executed. The system calculates the values

based on the different fiscal year variant.

For more information, please see SAP Note 1175751 (Sections "Scope of functions" and Note also).

For more detailed information about this feature, please see Section Mirroring of Datain this document.


9/24




October 20, 2014


Transferring Balances to the General Ledger (G/L)

After the system has copied the relevant data to the mirror company code, the correct asset accounting values are

available in the mirror company code. The correct values for all non-asset accounting accounts are available in the

original company code.

You can use a report to post the balances of all relevant accounts from the mirror company code back to the original

company code to make the correct asset accounting G/L data available in the original company code.

For more detailed information about this feature, please see Section Transferring Balances from Mirror Company

Code to Original Company Codein this document.


10/24




October 20, 2014


2 Mirroring of Data

2.1 Process Overview

The asset accounting multiple calendar tool allows you to mirror asset master data records and asset transactions

from the original company code to a mirror company code. During a mirroring run, the system only copies the

relevant master data and transaction data fields.

The overall mirroring process could run as follows:

1. You start the mirroring run by executing the Mirroring Asset Master Data and Transactions in AAreport. To do

so, you use transaction code/MTO/MIRRORTOOL.

2. The system mirrors all relevant asset master data (new and changed data) to the mirror company code.

3. The system mirrors all relevant asset transactions (that were performed in the given time period) to the mirror

company code.

4. You check the results of the mirroring run using transaction code/MTO/OBJ_LIST.

5. You display all exceptions that have occurred during the run using transaction code/MTO/EXC_LIST. If

necessary and possible, you edit these exceptions manually.

6. You check the consistency between the original company code and the mirror company code using transaction

code/MTO/RECON.

As a result, all relevant data is copied to the mirror company code. You can now do the following:

Trigger a depreciation (posting) run for the original and the mirror company code

Extract the asset history sheet for the original and the mirror company code

In a next (optional) step, you can transfer the G/L balances from the mirror company code to the original company

code. For more detailed information, see the following sections.

2.2 Prerequisites

All FI settings and objects, for example, G/L accounts, need to be present in the mirror company code before youuse the asset accounting multiple calendar tool for the first time.

Note

Make sure to transfer legacy data (using standard procedures) to the mirror company code before the first

productive run of the asset accounting multiple calendar tool. The tool does not support the migration of

legacy data.

You need to perform the required Customizing activities in the system (transaction code/MTO/CONFIG2).

o Before starting the mirroring process for the first time, make settings in the following activities:

o Maintain Settings for Company Code

o Maintain Time Stamp for First Productive Run


11/24




October 20, 2014


o Configure the mirroring process according to your requirements by making settings in the following activities:

o Maintain Name of Table and Fields Not to Be Copied

o Maintain an Asset Class Different to the Mirror Company Code

o Map Transaction Types for Acquisitions and Post-Capitalizations

o Map Transaction Types for Transfers

o Map Transaction Types for Retirements and Other Transactions

Note

For more information on how to configure the asset accounting multiple calendar tool, see the Customizing

documentation in the system. In addition, see the configuration guide available on SAP Service Marketplace

at http://service.sap.com/swdc Installations and UpgradesA Z IndexASSET ACCTG MULTI

CALENDAR.

2.3 Mirroring Asset Master Data and Transactions

During a mirroring run, the system first mirrors all new asset master data and changes to asset master data, followed

by all asset transactions that were performed in the given time period. After the mirroring run has finished, you can

display a list of mirrored objects.

You start the mirroring process by running the Mirroring Asset Master Data and Transactions in AAreport. The

system automatically determines the original company code that corresponds to the mirror company code you

specified and selects all relevant changes or transactions made since the last mirroring run or in a given time period.

Features

Mirroring the Creation and Change of Master Data

The asset accounting multiple calendar tool creates each asset with the status that the asset has at the moment of

mirroring. The tool does not take into account any changes that may have been applied to the asset before the first

mirroring run. Any changes that are applied to the asset after the mirror program has run for the first time are mirrored

in the subsequent runs of the program.

Example

o On January 10, 2015, you create asset no. 4711 with the description Original Asset Name in theoriginal company code. An acquisition is posted with posting date January 11, 2015.

o On June 20, 2015, you change the asset description to New Asset Name.

o On June 30, 2015, you trigger the first mirroring run.

The system creates the asset in the mirror company code with the master data that is valid at the time of the

mirroring run. Therefore, in the mirror company code, the asset description is New Asset Name right from

the start. The acquisition is mirrored with the original posting date of January 11, 2015.

We recommend that you schedule mirroring runs frequently to avoid inconsistencies between the original company

code and the mirror company code.


12/24




October 20, 2014


The asset accounting multiple calendar tools mirrors the FI-AA master data of tables ANLA,ANLB, and, with

restrictions, tablesANLZand ANLBZA. You can find more detailed information about the mirrored database tables in

the configuration guide.

If master data has been changed between two mirroring runs, the system reads the change document(s) and mirrors

the fields found there.

Note that for time-dependent master data fields (FI-AA tablesANLZandANLBZA), the following applies:

You can only mirror time-dependent intervals if the asset master record has already been created in the mirror

company code.

Each change of time-dependent data must be saved individually in the original company code.

In summary, the asset accounting multiple calendar tool requires an individual change document for each master

data change to ensure that mirroring is performed correctly. A correct mirroring process cannot be ensured if several

intervals are created (or changed or deleted) in one step.

However, it is not necessary to trigger a new mirroring run after each change.

Mirroring Transactions

The system determines the transaction type (or transfer variant) to be used in the mirror company code according to

the settings in the tool-specific Customizing.

Note

If you have not made a setting for a transaction type (or transfer variant) in Customizing, the system creates

an exception. For more information about exceptions, see Chapter 2.5 Dealing with Exceptions.

In the case of asset acquisitions, the acquisition costs are mirrored first in the local currency. The conversion into

foreign currency depreciation areas is performed in the same way as the FI-AA standard conversion logic. Exchange

rate deviations in an FI document are therefore not taken into account in the foreign currency depreciation area.

In the original company code, the system uses a transfer variant to post asset transfers. The system derives the

transaction types used based on the transfer variant. Transfer variants are defined in standard FI-AA Customizing. In

addition, to mirror asset transfers, you must also maintain the relevant transfer variants in the tool-specific

Customizing.

In the original company code, the system uses transfer transaction types for settlements of assets under construction

(or, alternatively, of investment measures). To be able to mirror a settlement of an asset under construction, you must

create new, customer-specific (acquisition) transaction types. Please see SAP Note 1924771for more information.

Activities

You can call up the report to start the mirroring run using transaction code/MTO/MIRRORTOOL. You can execute the

report in test mode to simulate the mirroring process. Both modes test mode and productive mode can run in the

background.

For more information, see the report documentation in the system.

Constraints

Master Data That Is Not Mirrored

The asset accounting multiple calendar tool does not mirror any master data from Controlling. This includes cost

centers and internal orders assigned to the asset master record as well as derived profit centers.


13/24




October 20, 2014


Note

If you want to use cost centers or profit centers in the mirror company code, you need to create and, in case

of changes, synchronize them outside of the asset accounting multiple calendar tool. This could result in

additional development effort that is subject to a fee. In this case, please contact your SAP consultant.

The following master data is also not mirrored:

Insurance values (FI-AA tableANLV)

Investment support measures (investment grants)

Master data created with FI-AA legacy data transactions

Assets containing leasing data, a Plant Maintenance (PM) linkage, a Real Estate (RE) linkage

Assets containing a unit of measure

In all the above cases, you must maintain the asset manually in the mirror company code.

Transactions That Are Not Mirrored

The transactions listed here are not taken into account for mirroring. You must re-post these transactions manually in

the mirror company code:

Unplanned depreciation

Write-ups

Settlements of assets under construction to non-FI-AA objects

Down payments (or down payment clearings) for assets under construction

Investment support values

Transfers of (replacement investment) reserves Postings related to the time-independent management of organizational units (tableT093C, field XZORG)

Statistical FI-AA documents posted to enter subsequent revenue or subsequent costs from asset retirement

Asset acquisitions posted using transactions MIGOorMIRO

Further note that some configurations cause the mirroring program to st op processing entirely. In the

following cases, you must change the configuration of the original company code in order to use the asset accounting

multiple calendar tool:

At least one FI-AA depreciation area of the original company code is configured for revaluation.

Joint Venture Accounting (JVA) is active.

Country-specific FI-AA tables are maintained.

The (initial) time stamp dates of the tool precede the FI-AA legacy data transfer date.

2.4 Displaying Mirrored Objects

After the system has completed the mirroring run, you can display a list of all objects that have been mirrored. For

asset transactions, the system provides the accounting document number of both the original company code and the

mirror company code.


14/24




October 20, 2014


Note

To display information that is not directly related to a specific master data record or transaction, see the

application log. You can access the log using standard transaction codes SLG1orARAL. Enter the followingdata:

o Object: FIAA (Fixed Assets Accounting)

o Subobject: 002 (Fiscal year change and year-end closing)

Activities

To access the List of Mirrored Objectsreport, you use transaction code/MTO/OBJ_LIST. For more information, see

the report documentation in the system.

2.5 Dealing with Exceptions

During a mirror run, whenever the system encounters a problem that is related to asset master data or asset

transactions, it creates an exception. In this case, the system does not copy the data to the mirror company code.

After the system has completed the mirroring run, you can run a report to display a list of all exceptions. This allows

you to analyze the error messages assigned to the exceptions.

Features

The system automatically assigns a status to all exceptions. The following are the most important status codes:

Error

These exceptions can occur, for example, if tool configuration settings are missing. For some examples, see SAP

Note 2030597.

After solving the issue, for example, by making settings in the mirror company code, you can manually deactivate

the exception in the exception list. To do so, select one or more exceptions, choose the Switchpushbutton, and

then the Deactivate pushbutton.

If you do not deactivate the exceptions manually, the system will report them again in the subsequent mirroring

runs.

Note

Depending on the type of issue that caused the exception, it may not be necessary to deactivate the

exception manually after solving the issue. If you solve the issue, for example, by maintaining a missing tool

configuration setting, and trigger another mirroring run, the exception is not reported again when you call up

the exception list using the default settings (Figure 3). By default, theAsset Master, Translations, and Open

Issuescheckboxes are selected. If you select the Deactivated Exceptioncheckbox, the system displays all

exceptions that have been created so far.


15/24




October 20, 2014


Figure 3: Handling Exceptions

Skip asset

You cannot deactivate exceptions with this status manually. All transactions or master data changes pertaining to

a skipped asset must be re-posted manually in the mirror company code. This also applies to all future changes

and transactions, including the reversal of a skipped transaction.

For some examples, see SAP Note 2030597.

Error in predecessor

This status indicates that an error occurred in a transaction preceding the transaction to be mirrored. As a result,

the system cannot mirror the transaction. You must solve the error that occurred in the preceding transaction first

and then re-start the mirroring run.

Note that all exception list entries that refer to the same financial accounting document must be changed together.

Example

There is an unsolved issue related to a transfer from asset number 4711 to asset number 5001. The

exception list for the respective mirroring run contains two entries, one for each asset. You must edit bothentries manually in order to solve the issue. If you have restricted the selection of assets before executing

the report, so that only one asset is displayed in the exception list, the system does not allow you to change

this entry and issues an error message instead.

Activities

To run the Exceptionsreport, you use transaction code /MTO/EXC_LIST. Enter the mirror company code and

optionally the asset number, the asset sub-number, the date and time of the mirroring run, and further selection

criteria (if applicable).


16/24




October 20, 2014


In addition to the exceptions created by the system during a mirroring run, you can create exceptions manually. To do

so, run the Exceptionsreport. When the list of exceptions is displayed, you can manually create a new entry, for

example, an exception with status Skip asset. As a result, the asset is not mirrored in the subsequent mirroring run.


2.6 Checking the Consistency Between Original

Company Code and Mirror Company Code

After the relevant asset data and asset transactions have been mirrored from the original company code to the mirror

company code, you can check the consistency of the data between both company codes. To do so, run the

reconciliation report.

The system checks the following when you run the report:

Whether all assets are present in the original company code and in the mirror company code

Whether the values of FI-AA tablesANLB,ANLZ, andANLBZAare the same in the original company code and in

the mirror company code

Whether the acquisition and production costs (APC) are the same for each asset in the original company code

and the mirror company code

The system displays a list of all inconsistencies. In addition, the system calculates and lists the sum of all assets for

certain categories, shown in the legend of the message log.

Note

Using this function, you can compare data of sub-ledger asset accounting, but not general ledger data.Also note that only APC values are compared. All values related to depreciation are not taken into account.

Use transaction /MTO/RECONto run the report. For more information, see the report documentation in the system.

2.7 Resetting the Company Code in the Test System

In the test system, you can reset the mirrored data in the mirror company code. To do this, you use transaction

/MTO/RESET_CCto access the corresponding report. Once you have run the report and reset the data, it is not

possible to retrieve the deleted data. Therefore, we strongly recommend that you restrict the authorization to execute

the report accordingly.

Note

This function is only available in the test system.



17/24




October 20, 2014


3 Transferring Balances from the Mirror

Company Code to the OriginalCompany Code

3.1 Process Overview

You can transfer asset accounting G/L data from the mirror company code back to the original company code. This

allows you to transfer balances calculated based on the fiscal year variant assigned to the mirror company code back

to the original company code.

Note

The G/L Balance Transferprogram is available for customers using new General Ledger Accounting and

also for customers using the classic General Ledger. However, note that the following explanations mainly

concentrate on the features of the program for new G/L customers.

You run the G/L Balance Transferprogram to execute FI reports, for example, the financial statement for the original

company code, based on the values calculated using the different fiscal year variant of the mirror company code.

However, since the asset accounting multiple calendar tool must sometimes change the character of an asset

transaction, the financial statement of t he original company code might not be entirely correct according to the

different fiscal year variant.

Example

A post-capitalization in the original company code might be posted as a normal asset acquisition in the mirror

company code. As a result, the revenue of the post-capitalization in the original company code is not

balanced by the acquisition posting in the mirror company code and is therefore still visible in the financial

statement created on the basis of the different fiscal year variant.

Moreover, after running the G/L Balance Transferprogram, it is not immediately possible to create a financial

statement for the original company code according to the different fiscal year variant. In addition, you must create a

new financial statement version. This is because the G/L Balance Transferprogram posts to newly defined accounts.

In spite of these limitations, the use of this program is one approach for achieving the best possible results.Note that in order to create a fully correct financial statement, it would be necessary to repost ALL financial

documents twice in a second company code. This option is, of course, not feasible.

Note

Another approach for achieving the best possib le result s is descr ibed in SAP Note 2071077.The note

explains an option for customers using the ledger approach of new General Ledger Accounting. The option

described in the SAP Note is based on existing reporting functionalitiesand offers some advantages in

comparison with the G/L Balance Transferprogram.

When you run the Balance Transferreport for an FI period for the first time, the process may work as follows:


18/24




October 20, 2014


1. If new General Ledger Accounting is active, you start the G/L Balance Transferreport using transaction code

/MTO/TRANSFER.

2. The system reads the G/L account balances in the mirror company code for the selected FI period.

Note that you must specify the respective accounts in Customizing. An example for such a specified account is

an accumulated depreciation account (for example, with the number 011010), which is also a reconciliation

account for assets.

3. The system posts and transfers the G/L balance values to newly defined accounts in the original company code.

These accounts are also specified in Customizing for the asset accounting multiple calendar tool. For example,

MT011010 could be such a newly defined account. This represents an accumulated depreciation account for the

G/L balance transfer and is not a reconciliation account for assets.

Note

The respective FI document is only posted in the non-leading ledger of the original company code you

defined in Customizing.If you run the report for the first time for an FI period, the system creates (only) one FI document. The FI

document consists of several posting lines: for each (newly defined) account, one line is created.

4. You check the result of the G/L balance transfer using transaction code /MTO/CHECK. When you run the

corresponding report, the system compares the balances between the mirror company code and the original

company code.

If you run the Balance Transferreport for the same FI period subsequently, the process may be as follows:

1. The system compares the balances of the newly defined accounts in the original company code with the

balances of the original accounts in the mirror company code.

2. If there are no differences between the accounts, no FI document is posted.

Note

No FI document is posted if the following applies:

o The document type configured for the G/L balance transfer is permitted for negative postings This can

be done in transaction codeOBA7.

o The original company code permits negative postings in tableT001.

3. If differences exist between the accounts, the system first posts a ledger group-specific clearing document in the

amount of the current account balance as found in the original company code. In a second ledger group-specific

FI document, the new balance amount is posted.

4. Check the result using transaction code /MTO/CHECK.

Note

You can run the G/L Balance Transferreport for several FI periods at once. The system posts a separate

balance transfer document (and a clearing document if necessary) for each FI period.

After the balance transfer, the asset accounting G/L data calculated based on the fiscal year variant assigned to the

mirror company code is also available in the original company code. You can now extract G/L reports with

transferred values from the original company code.

Figure 4 illustrates the result of the G/L balance transfer (with active new General Ledger Accounting and the ledger

approach).


19/24




October 20, 2014


Figure 4: Result of G/L Balance Transfer

3.2 Prerequisites

Before you can start the transfer of balances, make sure that you have configured the balance transfer according to

your requirements. You do this in Customizing for the tool (transaction /MTO/CONFIG) by making the necessary

settings in the Maintain Account Mapping(see Figure 5) and Maintain Mirror Relationshipactivities.

Figure 5: Account Mapping Customizing (Example)


20/24




October 20, 2014


For more information on how to configure balance transfer, see the Customizing documentation in the system. In

addition, see the configuration guide available on SAP Service Marketplace at http://service.sap.com/swdc

Installations and UpgradesA Z IndexASSET ACCTG MULTI CALENDAR.

3.3 Transferring the G/L Balance

You can transfer the relevant account balances from the mirror company code to the original company code using a

report provided for this purpose. If new General Ledger Accounting is active, the transfer and the clearing documents

are ledger group-specific. The system reads the G/L balances in the mirror company code and posts the balance

amounts to the corresponding, new accounts in the original company code.

The system always transfers the complete balance structured by currency and the relevant CO objects (if applicable)

for the selected fiscal year and period. Note that Controlling (CO) must be configured in the mirror company code if

you want to use balances and postings with CO objects. Due to the complexity of this configuration, we recommend

that you contact SAP Custom Development to discuss an additional Custom Development Project (CDP).

Note

The balances are transferred on account level, not on asset level. The aggregation level depends on the new

G/L scenarios that are active in the relevant ledger.

Features

The system transfers the G/L balances in two steps:

Step 1: Clearing of the existing G/L balances in or iginal company code

1. For each entry (FI-AA account of the mirror company code and newly defined account of the original company

code) maintained in the Maintain Account MappingCustomizing activity, the system compares the balance of the

account in the mirror company code with the balance of the respective account of the original company code.

If the balances are the same, no clearing document is posted.

If the balances are different, a clearing document in the amount of the balance in the original company code is

posted.

Note that any ledger of the corresponding accounting principle can be used for checking.

2. After retrieving all balance lines for each account of the original company code, the lines are aggregated. For

every resulting line, a posting line will be created in the FI document.

3. The balance offset account is retrieved from the G/L balance transfer Customizing (activity Maintain Mirror

Relationship) for each document.

4. If the document type and the original company code settings are fitting the clearing documents are created as

real reverse postings, to avoid balance sheet extensions.

5. All G/L balance transfer postings (including the clearing documents) are posted in local currency.

6. All G/L balance transfer postings (including the clearing documents) are only posted in the original company

code.

7. If you use new General Ledger Accounting all G/L balance transfer postings (including the clearing

documents) are ledger group-specific.


21/24




October 20, 2014


Step 2: Transfer of the current G/L balance from mirror company code to original company code

1. For each account of the mirror company code that is specified in the G/L balance transfer Customizing (

activity Maintain Account Mapping), the account balance value is retrieved and posted to the (new) account in

the original company code. The account lines are accumulated. If applicable, the customer fields are mapped

into standard account assignment objects, for example, cost center and profit center.

2. The accounting document is created based on the accumulated account lines. The number of lines you provide

on the reports selection screen determines the number of lines the system uses to create one accounting

document.

3. The balance offset account is retrieved from the G/L balance transfer Customizing (activity Maintain Mirror

Relationship) for each document.

4. The accounting documents are checked for errors. If no errors are found and the report is not being executed in

test mode, the documents are posted in local currency.

The application log lists the information related to the G/L documents created for the account balance transferred in

each period.

Activities

You start the G/L Balance Transferreport using transaction code/MTO/TRANSFER(if you are working with new

General Ledger Accounting) or/MTO/TRANSFER_SLCL2(if you are working with classic General Ledger

Accounting).

The system automatically determines the original company code and the relevant ledger that corresponds to the

mirror company code and mirror ledger that you specified.

You can run the report in test mode to simulate the transfer process.


3.4 Checking the Balance Transfer

After the G/L balances have been transferred back to the original company code, you can check whether the

respective balances in the original company code and in the mirror company code are really the same. A report is

provided for this purpose.

For each entry in the Maintain Account MappingCustomizing activity (FI-AA account of the mirror company code

and newly defined account of the original company code), the system compares the values of the debit and the creditside. If applicable, the system also compares the account values at the level of profit center and cost center.

Features

The system checks all ledgers in the original company code that belong to the accounting principle assigned to the

combination of mirror company code and mirror ledger.

Note

You can check the existing combinations in Customizing under Maintain Mirror Relationship.


22/24




October 20, 2014


If no differences exist, the log displays the balance amount only in the company code currency. If the system finds

differences for an entry, they are displayed in the log in all relevant currencies.

Figure 6 shows several sample log entries displayed by the system after running the transfer check report.

Figure 6: Log of the G/L Balance Transfer Check

In this example, the new account MT011010 has a balance of EUR 1,888.16 on the credit side of in the original

company code. The amount is the same for the corresponding account 011010 in the mirror company code.

Therefore, a green traffic light is displayed and the amount is only shown in the company code currency.

In the original company code, EUR 2,000 are missing on the debit side in the new account MT011000. The report

recognizes the difference by comparing it with the corresponding account 011000 in the mirror company code.

Therefore, a red traffic light is displayed and the amount is shown in both the document currency and the hard

currency.

Activities

You execute the G/L Balance Transfer Checkreport using transaction code /MTO/CHECK(if you are working with

new General Ledger Accounting) or/MTO/CHECK_SLCL2(if you are working with classic General Ledger

Accounting).

The system automatically determines the original company code and the relevant ledger corresponding to the mirror

company code and mirror ledger that you specified.



23/24




October 20, 2014


4 Appendix: Main Transaction Codes

These are the most important transaction codes available for working with the asset accounting multiple calendar

tool:

Transaction Code Purpose

/MTO/CONFIG2 Accesses the Customizing structure used to configure the mirroring process

/MTO/CONFIG Accesses the Customizing structure used to configure the balance transfer process

/MTO/MIRRORTOOL Starts the mirroring of objects (master data and transactions) from the original

company code to the mirror company code

/MTO/OBJ_LIST Displays a list of objects that have been mirrored within a given time period

/MTO/EXC_LIST Displays all exceptions that require manual post-processing and to create and

change exceptions manually

/MTO/RECON Checks the consistency of data and display inconsistencies

/MTO/TRANSFER Starts the transfer of the G/L balances from the mirror company code to the original

company code when new General Ledger Accounting is active

/MTO/CHECK Checks the G/L balances between the mirror company code and the original

company code when new General Ledger Accounting is active

/MTO/TRANSFER_SLCL2 Starts the transfer of the G/L balances from the mirror company code to the original

company code when new General Ledger Accounting is not active

/MTO/CHECK_SLCL2 Checks the G/L balances between the mirror company code and the original

company code when new General Ledger Accounting is not active

/MTO/RESET_CC Resets the time stamps needed to determine the objects (master data and

transactions) to be mirrored

Deletes all entries in the exception list

Deletes all entries in the list of mirrored objects

Deletes all entries in table/ MTO/ TRF_ STATUS

Note

When you execute this transaction, the system creates an entry in the

system log (transaction SM21). We strongly recommend that you use this

transaction code for testing purposes only.


24/24

www.sap.com/contactsap

Application Help Asset Accounting Multiple Calendar Tool 102014 FV 1.2

Documents

Transcript of Application Help Asset Accounting Multiple Calendar Tool 102014 FV 1.2