FI AA periodic processing

Periodic processing

Cross Company Code Depreciation Postings

Cross-Company Code Depreciation Postings with RAPOST2000Author: D033258

IMS Financials, SAP AG

Common Abbreviations

CoD = Chart of Depreciation

CC = Company Code

TCODE = Transaction Code

G/L = General Ledger

Occuring Issues

Customer upgrades from release prior to R/3 Enterprise (4.70) and detects differences between cross-company

postings done by the old depreciation program (RABUCH00) vs. the new depreciation program (RAPOST2000).

Often the Cost Center has a different company code assigned, RABUCH00 did not post the depreciation to this foreign

company code (= cross-company), but RAPOST2000 ends with error message KI 223 (Cost center &/& can only be

assigned to in company code &).

In some cases customer complains that other G/L transactions (FB01, etc.) allow posting to TCODE used in this

transaction without errors, even if the cost center has a different company code assigned, but RAPOST2000 ends with

error message KI 223 (Cost center &/& can only be assigned to in company code &).

In seldom cases the customer does not know the document number determination for these postings, because it

changed also from RABUCH00 to RAPOST2000

Basic Functionality

IMG

Asset Accounting

Master Data

Specify Cost Center Check Across Company Codes

IMG Documentation Specify Cost Center Check Across Company Codes

Activate this functionality if

cost accounting extends across company codes (several company codes belong to one controlling area) and

account assignment of cost accounting depreciation from Asset Accounting to cost centers that are in different company

codes than the asset.

When you enter a cost center in the asset master record, the standard system checks if this cost center exists in the

same company code as the asset. You are not allowed to enter a cost center in a different company code.

In this step, you can make this check less strict. The system then only checks whether the cost center exists in the

given controlling area.

Example

Asset: 30051 -> Company code of the asset: 0001 -> Cost center in the asset: SAP-DUMMY -> Company code of cost

center SAP-DUMMY: 1000

Excursus CO

Company Code Maintenance in Cost Center Master Record only when Cross-Company Code Cost Accounting is active

in Controlling Area (OX06)

Excursus RABUCH00 vs. RAPOST2000

Old depreciation run RABUCH00 did not check the cost center initially. RABUCH00 interpreted IMG activation flag in FI-

AA customizing (T093C-BKRAKT). If not set to active, only sending CC was posted - even if cost center had different

CC assigned.

This is the first pitfall when upgrading to RAPOST2000. New depreciation report initially uses cost center information.

As additional check T093C-BKRAKT is checked. If inconsistent information is determined, RAPOST2000 will end with

errors

Asset Master Record Maintenance

IMG Setting not active, trying to assign Cost Center with different company code:

Exception

If the company code check is deactivated for 'Activate components' in the Controlling IMG under 'Controlling -> General

Controlling -> Organization -> Maintain Controlling Area', then a cost center can be assigned to the asset master record

without having activated it in IMG FI-AA!

Second Pitfall: these cases will lead to KI 223 in RAPOST2000!!!

Important note:

Deactivating the company code check has an effect on all postings in external FI since CO objects from other company

codes can generally be assigned to an account as a result. A reconciliation between G/L and cost accounting is no

longer possible.

Deactivate the company code check is only possible if the reconciliation ledger is not active (Deactivate Reconciliation

Ledger: Transaction KALB).

Basic Intention

If depreciation is posted in company code X for the cost-accounting depreciation area "fixed assets" that points at a cost

center K in another company code Y, two documents are created (one for each account

assignment):

Document 1 (relevant for CO):

=============================

Debits/credits Account Company code Cost center

D depr. account Y K

C clearing acc. Y -

Document 2:

============================

Debits/credits Account Company code Cost center

D clearing acc. X -

C depr. clearing acc. X -

Cross-Company Code Document Type Customizing with RABUCH00

Described in note 51860

All company codes "X1, X2 ..." with fixed assets use same doc type for depreciation posting (e.g. AF). Corresponding

number ranges over company codes "X1, X2 ..." may have no overlaps. In addition, the number range for document

type AF must be maintained in company code Y of the cost centers and all number ranges for document type AF must

be across company codes "X1, X2 ..." or chosen internally.

Example: company code X1: number range for AF = (10000, 19999)

company code X2: number range for AF = (20000, 29999)

company code Y: number range for AF = (10000, 29999)

or other internal number range

If fixed assets are also contained in company code Y, then in Y a document type other than the AF document type for

the "X1, X2, ..." company codes (e.g. AG) must be chosen as document type for the depreciation posting runs. The

number range of document type AG across company code Y may not overlap with the number ranges of document type

AF across company codes "X1, X2, ...".

Example: company code X1: number range for AF = (10000, 19999)

company code X2: number range for AF = (20000, 29999)

company code Y: number range for AF = (10000, 29999)

or other internal number range

number range for AG = (50000, 59999)

Cross-Company Code Document Type Customizing with RAPOST2000

Assumption: standard document type AF is used for depreciation posting

IMG Asset Accounting -> Integration with G/L -> Post Depreciation to G/L -> Document Type for Cross-Company Code

Cost Accounting in External Company Code

Logic before release ECC 6.0:

AF must have external number range assignment

Document type for cross-company code depreciation posting must meet the following conditions:

It must be a document type different from AF (e.g. AZ)

It must be defined with internal document number assignment.

Enhancement: only 2 document types needed, AF used for depreciation postings in all company codes, AZ will always

be used for cross-company postings!

Logic as of release ECC 6.0:

AF must have internal number range assignment

Document type for cross-company code depreciation posting must meet the following conditions:

It needs not to be different from AF, can be the same as the regular depr. document type

It must be defined with internal document number assignment.

Enhancement : only 1 document types needed for any number determination

Depreciation document without cross-company code posting

G/L Depreciation Document

Depreciation document without cross-company code posting

G/L Depreciation documents

->Offset Accounts balance to zero!!!

Maintenance of clearing accounts - standard functionality

IMG Financial Accounting -> General Ledger Accounting -> Business Transactions -> Prepare Cross-Company Code

transactions

If no clearing accounts are maintained, error message is given out.

Maintenance of clearing accounts - individual functionality

As the standard functionality is used mainly for cross-company code functionality for component accounts payable and

accounts receivable, these accounts are regularly open item managed accounts.

Many customers do not want to use open item managed accounts in their local GAAP for postings from the CO-only

depreciation area (e.g. area 20) ... this is a conflict, because is only one IMG step for any purposes

Assumption: Accounting Interface creates automated cross-company postings only if balance per document per

company code is not balancing.

Solution: Asset Accounting line item generator enriches created document, so that in each affected company code

balance zero is given before passing the document to Accounting Interface.

Use of method ADD_DOC_LINES in Business Add-In BADI_FIAA_DOCLINES for Asset Accounting line item generator.

Coding Template released in note 723611 (RAPOST2000: Cross-company code postings in calc. Area)

Functionality: take depreciation line item for sending company code (offset account) and

Duplicate entry with twisted posting indicator and twisted posting amount in sending company code to identical account

Duplicate entry with an identical posting in receiving company code to identical account

-> G/L document balances in all company codes before passing the document to Accounting Interface

Schedule Monitor Assistance

With the change from external to internal document number usage, Schedule Monitor integration was enhanced.

Internal AA document numbers are stored as well as all generated G/L document numbers

Useful Notes

1079708 RAPOST2000: Deactivate cross-company code postings

723611 RAPOST2000: Cross-company code postings in calc. area

702210 RAPOST2000: Unwanted cross-company code postings

683313 Diffs in depreciation runs RAPOST2000 vs RABUCH00

666225 RAPOST2000: Incorrect cross-company-code clearings

648606 RAPOST2000: Cross-company code cost accounting

51860 Cross company code depreciat. posting runs > F5152 (> for RABUCH00)

How we can verify the asset posting logs

Skip to end of metadata Page restrictions apply Attachments:4 Added by Thaiane Treis, last edited by Thaiane Treis on Oct 01, 2013

Go to start of metadata

PurposeThe purpose of this page is to help users to verify system log after run periodic posting or depreciation posting in test

mode.

Overview

When we run periodic posting or depreciation posting, as best practice, we should run them as test mode first and verify

the system log to ensure that posting will occur without errors.

The most used transaction codes to verify periodic and depreciation posting logs are SCMO and ARMO.

Transaction codes to verify log:

The most used transaction codes to verify periodic and depreciation posting logs are SCMO and ARMO.

Go to transaction code SCMO:

Or go to transaction code ARMO directly:

By both transaction codes you will able to verify monitor below:

Also, if you want to know if there have been errors in the "direct posting", you can check it by transaction code ARAL:

Related Content

Related Documents

Year-End-Closing in Asset Accounting

Related SAP Notes/KBAs

SAP Note 625204: RAPOST2000: Displaying errors, spool lists

Running Depreciation using RABUCH00

Skip to end of metadata Page restrictions apply Added by Dasharathi, last edited by Nathan Genez on Dec 10, 2007 (view change) show comment


Running Depreciation using RABUCH00

Background

There are two major programs used to run depreciation in SAP.

All R/3 releases prior to R/3 Enterprise used program RABUCH00. As of R/3 Enterprise, SAP released a new version

of the depreciation program called RAPOST2000 although the older program RABUCH00 is still available and can be

used. This page of the Wiki will discuss RABUCH00 only.

Process Description

Every asset transaction immediately causes a change of the forecasted depreciation. However, it does not immediately

cause an update of the depreciation and value adjustment accounts for the balance sheet and profit and loss

statements. The planned depreciation is posted to the general ledger when you run the periodic depreciation posting

run. This posting run uses a batch-input session to post the planned depreciation for each posting level for each

individual asset as a lump sum amount.

Keys automatically control the calculation and scheduling of depreciation, interest and revaluation in the system, or you

can control them manually using a special posting transaction. In both cases, planned depreciation from Asset

Accounting must be periodically posted to the corresponding asset and expense accounts of the general ledger. You

carry out this posting using a batch-input session. In addition to the various depreciation types, interest and revaluation,

this batch input session also posts the allocation and writing off of special reserves.

When the system posts depreciation, it creates collective documents. It does not create separate documents for each

asset.

Technical Information

Program: RABUCH00

Transaction Code: AFAB

The program creates batch-input sessions for posting depreciation and interest to the G/L accounts in Financial

Accounting and/or to Controlling.

Steps for Running Depreciation:

At the initial screen of the program there are several fields that can be input.

Company code: Enter in the company code that you want to run depreciation for

Fiscal Year: Your fiscal year

Posting period: This is the depreciation period that has to be posted to the G/L

Reason for posting run:

Planned: This is used for all normal depreciation runs and is the default for the program.

Repeat: This can be used to make an additional posting run for a period that has already been run.

Restart: This can be used to restart a depreciation run that has failed for some reason.

Unplanned: Unplanned depreciation runs can be executed without evaluating the Posting Period. This lets you deviate

from SAP's standard requirement to always post for the next available posting period

List assets: You can activate this parameter so that the report output will list individual asset records.

Test run: activate this indicator if you want to run it in test mode

Main asset number: During a test run you can specify certain asset numbers

After populating these values, goto the menu path Program --> Execute in Background. For test run purposes, the

program can be executed in the foreground but will be limited to only evaluating approximately 1000 assets. You

should get this message "Background job was scheduled for program RABUCH00".

To process the depreciation session, goto transaction code SM35. Double click on the BDC session that was created

(most likely RABUCH). Choose the options to [Display Errors Only] and [Dynpro Standard Size]. The session will then

run in the background but will pop into the foreground if it encounters an error.

Steps for Recreating the Depreciation Log:

Using transaction code AFBD or program RABUCH30, you can create recreate the depreciation posting session in

case there are errors that stop the documents from posting.

Available Fields at AFBD:

Company code: Enter your company code

Fiscal year: Enter your fiscal year

Posting period: Enter your posting period

List assets: (tick if you want to see the detail)

Test run: (tick if you run in test mode else Un-tick for production run)

Click the execute button if this is a test run. If this is a productive run, goto the menu path Program --> Execute in

Background. You should get this message "Background job was scheduled for program RABUCH00 and print out the

output".

Tools

o ERP Financials 1. …2. Periodic Processing

V2 update error handling

Skip to end of metadata Page restrictions apply Attachments:8 Added by Guest, last edited by Daniela Wollinger on Nov 04, 2008 (view change) show comment


V2 update error handlingParallel scenario in investment orders / WBS settlements & Direct (V2) Update in parallel areas (Error handling)

Author: I021730, I027688

Parallel scenario in investment orders / WBS settlements

Due to new legal requirements a parallel valuation is necessary in some scenarios.

One common scenario is the capitalization of cost with different criteria depending on the legislation (Local vs IAS).

The use of capitalization keys applies to this scenario and provides a solution to automatically update parallel valuation.

In some cases parallel areas are not updated as expected so a periodic process has to be executed to "catch up"

missing On-line (V2) postings.

Con la clave de capitalización se puede especificar que ciertas clases de costes no se capitalicen o se capitalicen

parcialmente en alguna de las área de valoración del inmovilizado en curso. El sistema registra los costes no

capitalizados en una cuenta de gastos neutrales.

En la clave de capitalización se definen los porcentajes en función de una versión de capitalización. El numero de

versiones no esta limitado.

Cada versión se asigna a un área de valoración de activos. El sistema utiliza la versión de capitalización asignada al

área de valoración en el momento de calcular el porcentaje a capitalizar. De esta manera se pueden asignar valores

distintos a las distintas áreas.

Customizing

Customizing -Investment profile

Customizing - Capitalization key

The calculation of depreciation is based on period intervals instead of calculating depreciation on each single

movement. From this follows that the fields „NAFAB" and „SAFAB" of the table „ANEP" are not updated anymore. This

applies also to already posted movements.

Depreciation parameters in the asset master record can be maintained time-dependent. Dependency on time is

considered when depreciation is calculated.

A method change over is now possible on a period level - during the fiscal year.

The new functionality is available if the Add-On „EA-FIN" is active.

Error handling

When settlement takes place it could be that the parallel area is not updated on-line (V2 update) however no errors are

encountered in the settling transaction (KO88/CJ88).

Log of erroneus V2 update are displayed in transaction ARAL :

Object FIAA

Subobject 006

Errors displayed in the log have to be corrected.

Periodic posting program RAPERB2000 has to be executed to "catch-up" missing postings.

APERB_ITEMS table contains records of all V2 postings correctly updated. In case of an error in the "direct posting" the

record will not be updated in the table.

RAPERB2000 compares ANEP records with APERB_ITEMS records and if there is something missing it will post it.

APERB_ITEMS contains all records between two RAPERB2000 runs. After RAPERB2000 is correctly executed this

table is cleared.

Table APERB_PROT - This table will be updated in case errors have not been completly corrected and RAPERB2000

is executed in real mode.

Tools

o ERP Financials 1. …2. Periodic Processing

V2 update error handling

Skip to end of metadata Page restrictions apply Attachments:8 Added by Guest, last edited by Daniela Wollinger on Nov 04, 2008 (view change) show comment


V2 update error handlingParallel scenario in investment orders / WBS settlements & Direct (V2) Update in parallel areas (Error handling)

Author: I021730, I027688

Parallel scenario in investment orders / WBS settlements

Due to new legal requirements a parallel valuation is necessary in some scenarios.

One common scenario is the capitalization of cost with different criteria depending on the legislation (Local vs IAS).

The use of capitalization keys applies to this scenario and provides a solution to automatically update parallel valuation.

In some cases parallel areas are not updated as expected so a periodic process has to be executed to "catch up"

missing On-line (V2) postings.

Con la clave de capitalización se puede especificar que ciertas clases de costes no se capitalicen o se capitalicen

parcialmente en alguna de las área de valoración del inmovilizado en curso. El sistema registra los costes no

capitalizados en una cuenta de gastos neutrales.

En la clave de capitalización se definen los porcentajes en función de una versión de capitalización. El numero de

versiones no esta limitado.

Cada versión se asigna a un área de valoración de activos. El sistema utiliza la versión de capitalización asignada al

área de valoración en el momento de calcular el porcentaje a capitalizar. De esta manera se pueden asignar valores

distintos a las distintas áreas.

Customizing

Customizing -Investment profile

Customizing - Capitalization key

The calculation of depreciation is based on period intervals instead of calculating depreciation on each single

movement. From this follows that the fields „NAFAB" and „SAFAB" of the table „ANEP" are not updated anymore. This

applies also to already posted movements.

Depreciation parameters in the asset master record can be maintained time-dependent. Dependency on time is

considered when depreciation is calculated.

A method change over is now possible on a period level - during the fiscal year.

The new functionality is available if the Add-On „EA-FIN" is active.

Error handling

When settlement takes place it could be that the parallel area is not updated on-line (V2 update) however no errors are

encountered in the settling transaction (KO88/CJ88).

Log of erroneus V2 update are displayed in transaction ARAL :

Object FIAA

Subobject 006

Errors displayed in the log have to be corrected.

Periodic posting program RAPERB2000 has to be executed to "catch-up" missing postings.

APERB_ITEMS table contains records of all V2 postings correctly updated. In case of an error in the "direct posting" the

record will not be updated in the table.

RAPERB2000 compares ANEP records with APERB_ITEMS records and if there is something missing it will post it.

APERB_ITEMS contains all records between two RAPERB2000 runs. After RAPERB2000 is correctly executed this

table is cleared.

Table APERB_PROT - This table will be updated in case errors have not been completly corrected and RAPERB2000

is executed in real mode.

No labels

FI AA periodic processing

Documents

Transcript of FI AA periodic processing