Show TOC

Changes in FI Archiving Summary

Summary

Between releases 2.2 and 3.0, new archiving methods were developed in the R/3 Basis system. These allow, for example, for compressed storage of archived files as well as connection to optical archives. At the same time, a new architecture provides absolute data security, parallel processing and an identical user interface for archiving programs spanning all applications.

The archiving and reloading programs in FI were reworked to take advantage of this new functionality. The following text will go into more detail about these changes, particularly as to how they affect customizing, the user interface and functionality.

You can find non-application-dependent documentation for the architecture as well as for general customizing in the "BC Extended Function Library Applications" and "System Administration" documents.

Further documentation on this topic:

Release note

"Changes in Document Archiving"

Release note

"Archiving and Retrieval of Check Data"

Description

Note: The following program names have only been added to provide more detail. You would normally select the required function directly via the menu, or by using the new transaction SARA:
Accounting->Financial accounting->General ledger,
Periodic processing->Archiving-><Object>

Architecture

Under the previous archiving architecture, objects were sequentially read from the database, checked for suitability for archiving, saved to a file and then deleted from the directory. This "block" processing had the disadvantage that it could not perform these steps simultaneously. There was also the slight danger of data loss in the case of a system crash, if at that point in time the files were not completely saved in the file system (which is why SAP recommended that a database backup should be performed before archiving, a step which has been eliminated in the new FI archiving program).

The new architecture, however, which has already been in use in this form for document archiving, will separate the selection of dataset archiving from the deletion process. Therefore, an archiving program exists for each type of object, which reads the data to be archived from the database and writes it to a file. Finally, a deletion program for each archive file begins, which once again reads the data to be deleted from the file and deletes it from the database. Thus, with this architecture, the deletion and archiving programs can be executed in tandem. Moreover, in SAP's view, complete data security is guaranteed because each archived file is stored in the database before deletion.

Changed Objects

In the following section, an overview of the archiving objects which have been changed in FI, as well as the programs to which they belong, is provided (second name is the old name prior to Release 2.2).

New Objects

Two new objects were added to Archiving in version 3.0. Each of the new objects also has a Release Note.

New Archive Administration and Starting Archiving

The archive administration has been reworked in the course of the latest conversion, one effect of this is that the maintenance transaction F040 has been eliminated. For each object, the new archive administration can be called up by selecting
Accounting->Financial accounting->General ledger,
Periodic processing->Archiving-> <Object>->Administration,
or directly accessed through the SARA transaction. The administration is non-application-dependent and is documented in "BC Extended Function Library Applications" and "System Administration" documents.

In the new version, you always begin archiving and reloading programs via variants. This guarantees that archive administration will be able to store the selection in question. You can start the process either by the menu path mentioned above or directly through the SARA transaction. It is recommended that you avoid calling up these programs via transaction SE38 except for test purposes, or else the selection parameters will not be saved and the deletion programs will not start automatically.

Old Archive Files

The formatting of archive files was converted in Release 3.0. However, compatibility with earlier versions has been maintained, so that any older archived files can still be read. A conversion program transfers old administration data to the new archive administration system.

Background Processing

All archiving programs in a production run should, as far as possible, be run in the background on the database server. If the system is configured for the automatic startup of deletion programs, these will always run in background mode on the server with the capacity to run them at that time. You should therefore use the following path:
Tools->Administration, Jobs->Job overview and "Execute" to check if your deletion programs ended normally. Terminated deletion programs can be manually restarted in restart mode, in order to locate errors or to delete all objects in a file.

System administration changes

Archive Files in the File System

The new archive files are, as before, stored in a file system established under a logical path name. The filename, however, is based on the logical path name. Both can be configured (see below).

If the system's settings specify that archive files should automatically be transported to the optical archive, the files will be deleted after a short period of time (when they are stored in the optical archive).

Connection to the Optical Archive

You can control the transport between the file system and the optical archive centrally, from archive administration. You can find descriptions of the necessary customizing and operation functions in the "BC Extended Function Library Applications" and "System Administration" documents.

Authorizations

The authorization group with the value F_002 is always maintained in the archiving program attributes. This way you can protect the archiving program from being started. To do this, you need to maintain an authorization with value F_002 for the S_PROGRAM authorization object and include it in the user profiles. The SAP_ALL authorization must then be withdrawn from the users.

An authorization check is also carried out on the basis of the data to be archived for particular objects; this way the company code authorization, for example, is taken into consideration in the document archiving.

Change system parameters in customizing

Central Customizing

Central customizing takes place in two areas. On the one hand, it allows you to determine the archiving process.

For further information, see the "General Task Functions" Implementation Guide in the chapter "Define control parameters for archiving sessions".

You also have to define the file names of the archive. Either the path or the name can be assigned. You should, however, bear in mind that the optical archive (if connected) has access to the given path.

For further information refer to the Basis Implementation Guide, chapters "Additional client-dependent filename maintenance" and "Client-independent maintenance of filenames and paths".

Object-Related Customizing

A special object-related configuration within FI is exclusively necessary for document archiving. Modifications to this can be found in release note "Changes in Document Archiving" . Configurations for index management as well as for document type and account life have also been added. All other objects are configured through central archiving customizing (transaction SAR3).

Changes to the interface

Selection Screen Changes

An exact description of each field is provided in the program documentation. The following section deals with the more general subdivision.

Archiving Programs

In the first part of the selection screen, the dataset to be archived can be restricted. Datasets are normally restricted by key concepts such as company code or fiscal year. In some cases, a key date for an archiving run can be entered to which a minimum time period rule applies. In the second part, both known options, test run and detail log, can be selected.

Deletion Programs

The selection screen for deletion programs is identical for all FI objects. Before 3.0, the system would request an archive number, which designated the files whose contents would be removed from the database. This has been eliminated in 3.0 thanks to a new selection popup menu. A manually controlled deletion via transaction SARA must take place for background processing. Finally, there are the known options test run and detail log, as well as the Restart Mode for error situations. The "Hold FI index" field which is additionally offered in document archiving, will be described in release note "Changes in Document Archiving".

Reloading Programs

The first part of the reloading program restricts the dataset to be reloaded. Objects which should or cannot be reloaded are combined in a new remainder file, and the files which were selected are invalidated. The last part of the program consists of the known options test run and detail log.

Changes to the Logs

The logs consist of a detailed list (when activated), a statistical log and a run summary. The old record-by-record logs for transaction figures and bank master data have been eliminated.