Asset Closing:

1. Check Last Closed Fiscal Year in FI and FI-AA • First close the fiscal year in Asset Accounting and then in FI • Make sure that, at the most, two years are open for posting in FI-AA • Once the fiscal year is closed, you can no longer post or change values within

Asset Accounting (for example, by recalculating depreciation). • The fiscal year that is closed is always the year following the last closed fiscal

year. You cannot close the current fiscal year

For e.g current fiscal year (current date): March 19xx

last closed fiscal year: 19xx - 2

you can close fiscal year 19xx -

2. Run program RACHECK1 to eliminate inconsistencies between company code and

asset management account data

Errors in Customizing of depreciation areas, transaction types and period rules. • These can cause the following problems:

o Inexplicable error messages are issued when adjustment postings are made, although nothing was changed in Customizing. A typical example of these error messages is AAPO 176 “Transaction type XY cannot be used for activity Z.”

• Transfer postings cannot be carried out.

• Differences occur due to missing account assignments.

• When depreciation is recalculated, there are inexplicable error messages

3. Check Incomplete Assets (T code AUVA)

o Need to find and process incomplete assets before the year-end closing using

report RAUNVA00

o There are two different types of incomplete assets: 1. The asset is incomplete, but can be posted 2. The asset is incomplete and cannot be posted. We need to correct both types.

For example, when the user lacks authorization for master data fields that are required entry fields, but these are not so critical that the asset cannot be created at all. The system sets an indicator showing that assets are incomplete. For assets that are still incomplete when the report is run, We can go directly from the report to their asset master records and correct them, as long as this is allowed by your authorization profile

4. Check Indexes We should enter the indexes for:

• determining replacement values or • for updating the base insurable value, • Use transaction AYLS

It is important to carry out a recalculation of depreciation after the index series have been maintained

5. Recalculate Depreciation (AFAR)

This might be necessary if:

• Have changed a depreciation key.

• Have made mass changes that you programmed yourself, and these changes affected data relevant to depreciation.

• Values are not calculated correctly. This results in an incorrect display in the asset value display transaction.

• Differences between the general ledger and subsidiary ledger are possible.

• In the new fiscal year, there are assets with the message “Depreciation values not completely calculated for this asset“ (error message AA510). Recalculation at this point often does not correct the error.

• Assets with indexed depreciation areas are possibly not deactivated in the case of a complete retirement, if the calculation of replacement values was not up-to-date.

• You want to calculate subsequent revaluation (after the legacy data transfer is closed) using current index figures. In order to correctly calculate replacement values, however, you can only use index series that calculate historically.

• Start the depreciation recalculation program for the whole company code, for which the year-end closing is to be carried out. Execute AFAR test mode with the List assets and Execute in Background options

• When you run AFAR, a statistical log is issued. The log contains any error messages. Correct the errors leading to any error messages you receive, and start an update run of AFAR for these assets

Note: Up to and including this step, you can repeat all activities as often as necessary to ensure that the system is up-to-date

6. Execute Depreciation Posting Run(AFAB)

Every asset transaction in the Asset Accounting (FI-AA) component immediately causes a change of the forecasted depreciation. However, an asset transaction does not immediately cause an update of the depreciation and value adjustment accounts for the financial statements. The planned depreciation is posted directly to Financial Accounting (FI) when you run the periodic depreciation posting run. This posting run posts the planned depreciation for each posting level for each asset as a lump sum amount.

o Perform the depreciation posting run for the last period of the year (usually

period 12 of the fiscal year being closed).

o Recommend that start report RAPOST2000 first in the Background and in test mode, and then carefully consider the log. If error messages are issued in the test run, then correct the errors (usually these are in account determination or Customizing of cost centers), before starting RAPOST2000 in update mode, since the report cannot be reversed

• Planned posting run We post to the next period that is specified according to the posting cycle. As long as the last normal period was already posted, it is possible to post to special periods in FI. The system does not allow for limiting the run to particular assets. Thus, we need to run for full company code

• Repeat posting run A repeat run might be necessary, for example, if the depreciation terms were changed for individual assets in connection with the year-end closing. During a repeat posting run, the system only posts the differences that resulted between the first posting run and the repeat posting run (no double posting) You can limit the run to particular assets

• Restart Using the restart mode ensures that all system activities are repeated that were not completed in the run containing the errors. In a restart run, only those assets are processed and displayed in the logs that were not processed successfully in the prior run.

• Unplanned posting run If we want to skip over one or more posting periods, specify an unplanned posting run. The system then posts for all periods that were skipped, as well as for the period entered

7. Execute Periodic Posting Program(ASKB) This program posts APC values from depreciation areas designated in the chart of depreciation as posting periodically From an accounting perspective, it is necessary in order to be able to make available the current status of all depreciation areas on a given key date. It is important to keep in mind here that the year-end closing report checks the date of the last periodic posting program run using the system date as a reference. As a result, the year-end closing can only be carried out at a time close to the end of the year. In addition, the periodic balance sheet postings are an important step before the reconciliation of the general ledger and subsidiary ledger for the individual depreciation areas, since this is the only way for them to be in agreement. Therefore RAPER2000 has to be executed at least once in update mode

8. Reconcile General Ledger and Subsidiary Ledger (ABST2)

A. Start report RAABST02. If the report logs differences in table EWUFI_BAL (table FAGLFLEXD if the New G/L functionality is active) , proceed with the following steps. If the report does not find any differences, the general ledger and subsidiary ledger are consistent to each other. B. For the account concerned, compare the last two fiscal years using the account display transaction (FS10N or FAGLB03 in New G/L) in the General Ledger. If the closing balance and opening balance differ, you have to start the balance carryforward program again for the current year. C. Create two asset history sheets for the accounts involved using the following parameters: Limiting the account assignment or the asset class in the dynamic selections

• Sort version 0020

• Group totals

• Report date – fiscal year end of prior year and current year

Setting “Depreciation posted” If the starting and final value of the asset history sheets are different, you should repeat the fiscal year change in asset accounting ( transaction AJRW).

If the starting and final values are still different after you repeat the fiscal year change, then check to see if there is an asset with a capitalization date but without acquisition data. Follow the procedure outlined in SAP Note 194635. D. The asset history sheet for the previous year does not agree within itself when you cross-foot. In this case:

a) Start RAABST01 for accounts with line item management. b) Start RAABST02 for reports without line item management. c) If the balance carry forward is affected, you now have to reset the year-end closing, perform depreciation recalculation, possibly carry out a depreciation posting run, and then run the year-end closing again. E. The starting balance values of the current year do not agree with the value of the balance display. There are various possible causes that then also require different actions on your part. a) The difference arose already during the legacy data transfer. In this case, contact SAP Remote Consulting. b) Missing line items. To see which line items are involved, see the log of RAABST01 or RAABST02. There are two possible scenarios: Missing line items during asset acquisition. These can be created easily using report RACORR05. In the case of multiple account assignments, use report RACORR05A.

Missing line items during asset retirement. These can not be created using report RACORR05. In this case, contact SAP R/3 Support, describing the exact parameters of the asset concerned.

c) Line items with incorrect acquisition year. This situation is found at times with postings from invoice verification (transactions MRHR or MIGO). For correcting this problem, there are a number of correction reports that are listed in SAP Note 366848. If you are unsure of how to proceed, contact SAP Support. d) Account determinations that have errors or are incomplete can also cause differences, which cause errors during the euro conversion, if not before. For these errors, you should now, at the latest, consider your results from point 2. e) Manual postings to asset balance sheet accounts. In this case, contact SAP Remote Consulting, with the document numbers involved.

9. Execute Fiscal Year change AJRW

Fiscal year change is the opening of a new fiscal year for a company code

At the fiscal year change, the asset values from the previous fiscal year are carried forward cumulatively into the new fiscal year.

How is it executed?

• As you can see the only selection criteria is the company code. It is not possible to run this program for select assets or depreciation areas... it is run for an entire company code and all active assets and depreciation areas are updated.

• Of course the other field that has to be evaluated is the New fiscal year field. Simply enter in the value for the new fiscal year that you want to open.

• The Fiscal Year Change program has some similarities with some of the other periodic programs in FI-AA. There is a test run indicator which can be useful to uncover an obvious error before committed to a productive run.

• The program must be run in the background when it is run in productive mode.

• The program can be run repeatedly. There is no risk or further changes made if the program is run multiple times. In this way it is very similar to other balance roll forward programs such as SAPFGVTR in the General Ledger. In fact, this is often required for subsequent adjustments made to new assets in the prior fiscal year.

• It is not possible to reverse a Fiscal Year Change using standard methods

• Once the fiscal year change takes place, you can post to assets using value dates in the

new fiscal year. At the same time, you can continue to post in the previous fiscal year. You can continue to post in the old fiscal year, even after the fiscal year change. The system automatically corrects any values that are affected by postings in the past.

• The fiscal year change can only be carried out (even in test mode) for the new fiscal year.

• The system carries out the fiscal year change for all assets, even if the assets have errors.

The system provides statistics per company code for the assets that have been changed.

When can it be executed?

• The program can be run as early as the last regular fiscal period of the current fiscal year. When entering in the new fiscal year it must be only one year in the future. For example, in December of 2007 I can only run the program for 2008, not 2009 or later.

• By far the most common error that is encountered when running this program is AA761 "Fiscal year change in co. Code &1 possible only after year-end closing &2". You can have only 2 open fiscal years in the FI-AA sub ledger so you'll have to be sure that the prior fiscal year is already closed before running RAJAWE00. If the prior fiscal year is already closed then this error shouldn't appear.

• The earliest that you can carry out a fiscal year change is in the last month of the old fiscal year. You can choose any point in the new fiscal year for carrying out the fiscal year change

• Before you can change to fiscal year YYYY, you must have already closed fiscal year YYYY - 2. You can have a maximum of two fiscal years open for posting at one time

What kind of output is there?

• The first thing that you should notice is the program text displayed at the top of the output list. It gives some basic information about the program and how it relates to the financial closing.

• You should carry out the fiscal year close process in FI-AA before you complete the closing process in the FI-GL... it's logical to close the subledger before finalizing the close of the General Ledger.

• After the text at the top is a table that displays the status of the run by company code as

well as some statistical information.

• The log shown below is an example of how it looks if AJRW is run a second time after new records was posted in the prior year. There are 6 records in the company code but 3 have already been rolled forward to 2008. Of the remaining 3 records, 1 is deactivated and another has no value. In both cases there are no values that need to be brought into the new year so they will be skipped by the program. The other asset is active and has a value so it needs to be updated for 2008 (the To change column) but it has an error with it so it causes the program to output a record in the Incorrect column.

An asset is marked as incorrect during the execution o AJRW because there is an error in the asset's depreciation calculation. Unlike some of the other asset periodic programs, there is a section to display messages at the bottom of the screen but no messages will actually be displayed there. The only indication that there is a problem is because the Incorrect column has a value. At this point, you'll have to click on the Error Log button to see more.

You're now looking at the Application Log in SAP which will display the error messages for the program. The log will display each asset that is in error. You'll then have to investigate elsewhere to figure out what the error is and how to fix it.

What happens if I don't run it?

If the Fiscal Year Change is not executed, all asset reporting becomes inoperable once you cross over into the new year (as determined by the system date). Regardless of what report date you choose on the asset report... whether it's the end of the prior year or current year, or whether it's a year-end date or period-end date won't matter... the reports will all terminate with message AB059 "Fiscal year change not yet made for company code XXXX". The second limitation is that you won't be able to make any asset postings in the new year. If you try, the transactions will terminate with error AA347 "You cannot post to asset in company code XXXX fiscal year YYYY". For those situations where the program is not run in advance, I'd bet that this error is what reminds at least half of the SAP customer base that they have to execute this program. Third, you won't be able to run any of the asset periodic programs in the new year such as posting depreciation or posting periodic values.

What does it do (technically)?

There are three tables that are updated by RAJAWE00. • The configuration table T093C gets a small update. The new fiscal year is entered in

LGJAHR. The field label is "Current Fiscal Year" but the description of the data element is "Last fiscal year opened by the fiscal year change" which tells you all you need to know about what the field represents.

• ANLB is also updated. Similar to T093C the new fiscal year of the asset is entered in field LGJAN "Last fiscal year". This represents the highest fiscal year that the asset can be posted to. T093C-LGJAHR serves a similar purpose.

• The most important table that is updated is ANLC. ANLC is the core table for most all asset reporting and is keyed by fiscal year. By executing this program new entries are created for the new fiscal year in this table.

10. Year End Closing AJAB

• Assets Under construction- At the year-end closing, the system checks that there are no assets that have been posted (that is, they have an acquisition date), but have not yet been capitalized (the capitalization date is not set). These assets are then identified as having errors. This check does not make sense for assets under construction, since it is normal for them to have acquisition postings but not be capitalized. Therefore, we can limit the selection for the asset class here, so that assets under construction are not included in this check.

• We use the year-end closing program to close the fiscal year for one or more company codes from an accounting perspective. Once the fiscal year is closed, we can no longer post or change values within Asset accounting (for example, by recalculating depreciation)

• The fiscal year that is closed is always the year following the last closed fiscal

year. For. e.g. Current fiscal year (current date): March 19xx Last closed fiscal year: 19xx - 2 We can close fiscal year 19xx - 1 • You have to carry out the year-end closing as background processing for

performance reasons

• Reversing Year End Closing

We closed a fiscal year too soon, and still need to make corrections, you can reset the last closed fiscal year ( t code OAAQ)

• You do this by changing the field for the last closed fiscal year • Using this function, you can re-open the last closed fiscal year, either for selected

depreciation areas in a company code, or for all depreciation areas in a company code. (T code OAAR)