There are a range of activities in Asset Accounting that require intensive system resources. You can improve performance for these activities considerably by taking certain steps. System performance is strongly influenced by the number of master records and depreciation areas being processed. The following formula can be used as a guideline: If the number of master records multiplied by the number of depreciation areas is more than 5 million, then SAP recommends that you use the options outlined below for improving performance.

SAP’s general recommendation is that you should divide large datasets into a number of smaller files of equal size, and use multiple background processing jobs. The options for dividing large datasets into smaller portions is dependent on your hardware. If your CPU is already operating at capacity, then it is not possible to increase its speed further.

 However, make sure that you plan each of the jobs using a different system user, since the legacy data transfer program refers in part to user-dependent set/get parameters.

• If you are transferring more than 10,000 legacy assets, you should use the direct data import RAALTD11. As compared to the batch input procedure (RAALTD01), direct data import improves performance by approximately ten times. (However, you should always use a small number of assets from each asset class for testing. Transfer these test assets using the batch input data transfer program, in order to make sure that the data in the input file is correct.)

• Do not recalculate depreciation (this is very time-intensive).
• The use of different fiscal year variants reduces performance. You avoid this by choosing a fiscal year variant that is not year-dependent, and switching over to the fiscal year variant you want once the legacy data transfer is complete.

Reports for the close of a period or the fiscal-year closing can usually be divided into several background jobs. Instead of running one report on several company codes, for example, it is much more efficient to plan several jobs, one for each company code, and have them run in parallel. It might also make sense to split up a report on one company code into several jobs. For example, a report by cost center can be divided into several reports, each with one cost center or cost center interval.

• Generating reports with a report date during the fiscal year, rather than at the end of the fiscal year, is extremely demanding on system resources. If you nonetheless need this kind of report, try not to choose the report date as a selection criteria. Performance is improved if you limit acquisition and retirement lists by the posting date instead, or limit asset balance lists using the capitalization date.
• Avoid reports based on derived data, such as the profit center. Instead, select using data that is in the asset master record, for example the cost center.
• Do not select using just one criteria, such as the account. Instead use combinations, for instance the asset class with the account group.
• Select group totals.

• If you expect performance problems during depreciation posting (due to having over 100,000 assets), you can use a different program rather than the standard depreciation posting program RABUCH00. This alternate program RAPOST00 offers advantages in improved performance when a large number of assets are involved. However, it has some limitations. For more information about RAPOST00, see the online long text for the report in the R/3 system.

• RAPERB, RASKBU, RAJAWE, RAAFAR00, and RAJABS are unproblematic reports.

When carrying out the fiscal year change or recalculation of depreciation, you can distribute the transactions to several application servers. For more information, see the online help documentation for the Server group field.