A new archiving functionality allows you to view FI line items from the archive, which means you can delete the secondary index data earlier. It reduces the size of your database, and thus speeds up system performance.

I'll show you how to set up this functionality, so that for the first time your FI end users can obtain an entire overview of all periods of all accounts after archiving, even if they do not know anything about archiving. You need one of the following releases to be able to take advantage of the archive line item access: ECC 5.0; R/3 Release 4.70 – Support Package 14; R/3 Release 4.6C – Support Package 45; R/3 Release 4.6B – Support Package 54. The archived FI data will be just as visible to SAP applications via transactions FB03, FBU3, and line item display as the database data (BSIS, BSAS, etc.).

The FI secondary indexes are special database tables designed to allow quick access by account to the FI line items. For example, the FI table BSIS is often one of the biggest and fastest growing tables in R/3 systems. The table contains the line items of G/L accounts—either the open items of accounts with Open item management or just the line items of accounts, which have only the Line item display check box set in the master record (Figure 1).

Figure 1

G/L account with line item display

Until last year, when you removed FI secondary indexes you would lose the overview of your accounts in the line item display, one of the most essential functions in FI. That led to a requirement for a long index lifetime. With the help of SAP note 596865, released in 2003, this is no longer the case. Removing these FI secondary indexes is one way to reduce the size of your database. (See the sidebar, "Methods for Managing Your Database Size.")

The archive access of the line item display now enables a complete overview of your customer, vendor, and G/L accounts even after you delete your FI secondary indexes. You can feed your line item display from the database and from the archive. In addition, a mismatch of transaction figures and the corresponding sums of the line items caused by the deletion of the FI secondary indexes is no longer possible. This functionality also simplifies the introduction of the archiving object FI_DOCUMNT, because you no longer have to decide how long the FI secondary indexes have to stay in the database for this purpose.

The archiving process is split into steps for security reasons. In the first step, the data is selected from the database and written to an archive file. In the second step, the archive files are sequentially read and the found data is deleted from the database. This ensures that only readable data on the archive file can be deleted from the database and no data can be lost. You have one more step for FI_DOCUMNT. You have to delete the redundant data of the FI secondary indexes including data in the BSIS, BSAS, BSAD, and BSAK tables in a follow-up program. The index tables themselves are not deleted. This extra step allows you to keep the secondary indexes in the system longer than the FI documents themselves.

Functionality Prerequisites

To obtain archive access for the line item display, you have to provide the archive files containing the FI documents with an index called an information structure, or info structure. You do this via the SAP Archive Information System. (See the documentation in the application help for transaction SARI.)

Figure 2 shows how indexing by means of the SAP Archive Information System works. In the definition of the info structure on the left side, you can see all the fields that have been chosen for the delivered info structure SAP_FI_DOC_002. On the right side of the definition, you see the remaining fields that you could select when creating an info structure such as SAP_FI_DOC_002. If an info structure has been activated, a corresponding database table is filled during the archiving process. Example entries are shown on the right side of Figure 2.

Figure 2

Principle of indexing with SAP Archive Information System

In addition to the selected fields, the table ZARIXFI1 has the two technical fields ARCHIVEKEY and ARCHIVEOFS, which contain the name of the archive file and the offset within the archive file. These two fields point directly to the position in the archive files where the corresponding FI document is located. If you want to read an archived document, you first select an entry in the table ZARIXFI1 and than access the archive file directly at the position where the desired FI document is located.

In general, an info structure should contain as few fields for indexing the archive as possible, but all fields that are necessary for the desired selections. For the line item access, you can use the SAP standard info structure SAP_FI_DOC_002, which is not only designed to support the line item display, but also the single document display, the Document Relationship Browser, and the search on reference documents. You may need fewer or more fields. For example, for some audits, it might be important for an auditor or your FI users to be able to search for entries in the fields Main Asset Number (BSEG-ANLN1) and Asset Subnumber (BSEG-ANLN2) in the archives. (Refer to SAP note 737425 for more information about those two fields.)

If the standard info structure does not satisfy your requirements, you have to create your own containing the required fields for the line item display and the fields of your own choice. If you use your own info structure, do not forget to provide the needed database indexes, as described in the SAP note 596865, to obtain adequate performance. The info structure relates to a database table, which can become very large. Only requests that are supported by an additional database index on this table have reasonable response times. The archived data is accessed with two steps. The first step is a SQL request on the info structure table, for which you need the database index. The second step is a file access with explicit offset, for which the performance depends on the speed of the used file system or storage system where the archive files are located.

To take advantage of the archive access in the line item display transactions FBL1N, FBL3N and FBL5N, an end user does not have to do anything. If the prerequisites for the access are fulfilled via a suitable info structure, the access should be customized for all users. However, a user can overwrite the settings by clicking on the Data Sources button, which launches a pop-up window, as shown in Figure 3 . This would apply only for special purposes, such as searching an account in a certain archive file.

Figure 3

Pop-up window to control access to database and archive

In the pop-up window, you can choose the access to the line items using the database, the archive, or both. Without any customizing, the access using the database is preset. The functionality and performance of the line item displays are exactly the same as before the new functionality was implemented. If the index tables are already deleted, you won't see the data of the deleted entries if you are using only database, which is exactly what happens without the new functionality.

When you select Archive Information System, it performs an indexed access (Figure 3). The system automatically selects all relevant line items out of the archive. If you choose Select Files Manually another pop-up window appears, whereby you have to choose archive files that are read sequentially. All relevant documents are filtered. Expertise is necessary to select the files that contain all the relevant documents. If you want to have a complete selection, you have to know in advance which archive files you have to choose for the selection.

If you use the new archive access functionality with a suitable info structure, the presetting of the Data Sources functionality should always have the Database, Archive, and Archive Information System check boxes set. Therefore, you can access all documents from both from the database and the archive. If the functionality is not used, choose only the database, which is the initial state.

Account Type Life

You can customize the lifetime of table BSIS using transaction OBR7 (Figure 4). For more information about customizing the account lifetime, refer to SAP note 94144. The value according to G/L accounts and FI secondary indexes is in the row with Account Type S and in the column Secondary Index Run Time. In my example, it is 731 days, which means three years. This means that you always have table BSIS entries from at least the last three years in the database.

Figure 4

Account Type Life maintenance example