Periodic processing

Cross Company Code Depreciation Postings Cross-Company Code Depreciation Postings with RAPOST2000
Author: D033258 IMS Financials, SAP AG

Common Abbreviations

CoD CC G/L = Chart of Depreciation = Company Code = General Ledger

TCODE = Transaction Code

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 FIAA 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 C Document 2:

depr. account clearing acc.

Y Y

K -

============================ Debits/credits D C Account Company code Cost center X X clearing acc. depr. clearing acc.

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: company code X2: company code Y: number range for AF = (10000, 19999) number range for AF = (20000, 29999) 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 702210 683313 666225 648606 51860 RAPOST2000: Cross-company code postings in calc. area RAPOST2000: Unwanted cross-company code postings Diffs in depreciation runs RAPOST2000 vs RABUCH00 RAPOST2000: Incorrect cross-company-code clearings RAPOST2000: Cross-company code cost accounting 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

Purpose
The 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 Go to start of metadata

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

1. ERP Financials 2. 6. 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 Go to start of metadata

V2 update error handling

Parallel 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 capitalizacin se puede especificar que ciertas clases de costes no se capitalicen o se capitalicen parcialmente en alguna de las rea de valoracin del inmovilizado en curso. El sistema registra los costes no capitalizados en una cuenta de gastos neutrales.

En la clave de capitalizacin se definen los porcentajes en funcin de una versin de capitalizacin. El numero de versiones no esta limitado. Cada versin se asigna a un rea de valoracin de activos. El sistema utiliza la versin de capitalizacin asignada al rea de valoracin 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

1. ERP Financials 2. 6. 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 Go to start of metadata

V2 update error handling

Parallel 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 capitalizacin se puede especificar que ciertas clases de costes no se capitalicen o se capitalicen parcialmente en alguna de las rea de valoracin del inmovilizado en curso. El sistema registra los costes no capitalizados en una cuenta de gastos neutrales.

En la clave de capitalizacin se definen los porcentajes en funcin de una versin de capitalizacin. El numero de versiones no esta limitado. Cada versin se asigna a un rea de valoracin de activos. El sistema utiliza la versin de capitalizacin asignada al rea de valoracin 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