Executing Data Archiving for Specific FI Objects

With the universal journal as the central item table in accounting, there are strong dependencies between the various archiving objects. This means that certain objects can only be archived if the preceding object has already been successfully archived.

Example:

By only archiving table ACDOCA without archiving in asset accounting itself, the statistical line item of asset accounting would remain together with asset master data. No valid asset reporting would be possible any longer.

This results in the sequence described in the figure Process Flow of Financial Archiving in GL/AP and AR for archiving data in financial accounting.

In the course, we will focus on the following archiving steps (in FI-GL):

• FI Documents
• FI Transaction Figures
• Compression Run
• Master Data

The specific archiving procedure is scheduled and processed as a background job. The archiving procedure selects data objects from the database and analyzes the constraints that characterize each data object. Then, every data object is checked whether it is archived. If a data object is archived, it is written to the archive file. If the deletion program has been set to run automatically in Customizing, the associated deletion procedure starts automatically once a file is closed.

If the deletion program is not executed automatically, you can schedule the deletion procedure using the settings in object-specific Customizing. In this case, you must select the archive files from which the data objects can be read in the current deletion procedure and then deleted in the database.

To schedule an archiving procedure using transaction code SARA, choose Write.

1. Create an archiving variant:

   The data that is to be archived for the selected archiving object is specified in the archiving variants. As a rule, archiving variants can be reused only if the associated jobs are deleted. The definition of the variant must also include whether a test run or a productive run of the archiving program is involved.

2. Specify the execution user:

   The user under whom the archiving program is started requires at least one suitable authorization for the authorization object. S_ARCHIVE is the most important authorization object for data archiving. To limit the archiving objects to be used, select the corresponding field entries for the authorization object specific to S_ARCHIVE. In addition, corresponding authorizations for the transaction whose data is to be archived are required. As data archiving runs in the background, authorizations for background processing (archiving object S_BTCH_JOB) are also required.

3. Specify the start time:

   The start times for archiving jobs that are to be specified correspond to those of the scheduling of standard jobs.

4. Define the Spool parameters:

   Because job logs can become lengthy, change the settings so that logs are not immediately sent to the output device under the Spool parameter item. The selection options for the archiving procedure correspond to those of the default background printing parameters.

If documents are no longer required in FI after a certain time has elapsed, you can remove them from the database. The system checks certain conditions that are required for the removal of these documents. Archiving is executed by basis support and FI system support in consultation with the FI department.

The desired document type and account type runtimes are specified for each company code in Customizing.

Ensure that only documents that are no longer required are archived from the system. However, a number of conditions must be fulfilled before the documents are archived. To determine whether a document can be archived, the archiving program checks the document header and the line items. If during the checks, one of the prerequisites for the document archiving is found as not met, the whole document is not archived.

• The document type runtime must have been exceeded.
• A document must have been in the system for longer than the minimum number of days (minimum duration).
• Documents with a withholding tax must remain in the system for at least 455 days.
• Recurring, parked, or sample documents are not taken into account.

• The document must not contain open items. The system only takes cleared items or those items without open item management into account.
• The account type runtime must have been exceeded.

A key date is used as a reference date for the runtimes. The key date can be specified for every program run. If no explicit key date is provided, it is set to the current execution date.

Archiving Object and Programs for FI Documents

Accounting documents (FI-GL, FI-AP and FI-AR) are archived using the object FI_DOCUMNT. In addition to the accounting documents, their change documents, SAPscript texts, and ArchiveLink entries are also archived.

The following programs are delivered for the archiving object FI_DOCUMNT:

Program	Purpose
FI_DOCUMNT_WRI	Write
FI_DOCUMNT_DEL	Delete
FI_DOCUMNT_PST	Postprocessing

The program FI_DOCUMNT_WRI (Write) generates the archive files for all tables of the FI accounting document, such as BKPF (document header), BSEG (line item), ACDOCA (universal journal), and so on.

With the report FI_DOCUMNT_DEL (Delete), table entries (for example, BSEG, BKPF) are deleted. Important: However, no entries are deleted from table ACDOCA. Finally, the table field ACDOCA-BSTAT (Document Status) will be updated with the value "C".

Note

With the value "C" in the ACDOCA-BSTAT field, the system knows that these are archived entries and only total relevant, and therefore they won’t be shown in the line item reporting (for example, FAGLL03) or document display transaction (for example, FB03).

A main goal of FI document archiving is to reduce the data volume of the ACDOCA table. But, the accounting department is still interested in a high-performance line items reporting. However, reading FI documents from the archive could have a negative effect on this performance. For this reason, for example, in SAP ERP, the line item information is kept in the secondary indexes tables for a longer time to ensure a high-performance reporting.

With SAP S/4HANA, secondary indexes are determined from the FI documents at runtime. If you want to keep the secondary indexes longer than the FI document in the system, you can use the BAdI FI_DOCUMNT_IDX_DEL. In relation with the corresponding runtime settings for the secondary indexes in Customizing, entries are created in the auxiliary tables *_BCK during archiving (for example, table BSIS_BCK, table BSAS_BCK for G/L accounts). For further information, please refer to SAP Note 2519099.

The transaction figures for customer and vendor accounts are determined at runtime on the basis of document table BSEG. Since entries in BSEG are deleted during document archiving, this would no longer be possible. For this reason, the delete job generates totals values for the archived documents in the auxiliary tables KNCX_DIF (Customer) / LFCX_DIF (Vendors).

Transaction figures is the total number of  credit and debit postings on an account. In the SAP system, two transaction figures – one for credit and one for debit are maintained for each account.

The transaction figures of the customer and vendor accounts result from the data of the document item table BSEG / document header table BKPF that has not yet been archived in connection with the totals records from the two auxiliary tables LFCX_DIF (vendors) and KNCX_DIF (customers).

The transaction figures of General Ledger Accounting are determined from the item information of ACDOCA in connection with items of ACDOCA that contain the value BSTAT = C.

Transaction figures remain in the SAP system for at least two years.

Transaction figures can only be archived if periods open for posting are no longer in the period to be archived. Ensure that the periods for posting are closed for the entire period to be archived. Transaction Figures archiving is not a pre-requisite for compression run. It is needed to fulfill Data Privacy & Protection requirements.

The following objects are available for archiving transaction figures in FI-GL, FI-AP, and FI-AR:

The corresponding transaction figures are archived with the programs FI_TF_CRE_WRI / FI_TF_CRE_DEL (write/delete for vendors) and FI_TF_DEB_WRI / FI_TF_DEB_DEL (write/delete for customers).

The programs FI_TF_GLF_WRI (Write) and FI_TF_GLF_DEL (Delete) are available in General Ledger Accounting for archiving transaction figures. With the write program/job, the ACDOCA records are copied to the archive file.

The delete program/job creates a new record which corresponds to the archived total record but has the value with inverted sign. Based on this, the application will interpret both total records (that is, BSTAT = C) / the total amount as 0 and therefore does not want to show any result.

With document archiving in FI, the data of ACDOCA is only changed (keyword BSTAT = C). When transaction figures are archived, entries are also added. For this reason, there is a compression run that:

• Reduces the data volume of ACDOCA
• Facilitates the fulfillment of requirements from the Data Privacy & Protection area

The compression run has no impact on the business view/access of end-users in SAP S/4HANA financials.

If entries in ACDOCA qualify for compression (for example, related documents have already been archived – for more details, see SAP Note 2346296), these entries are created using a compression run (transaction FINS_ARC or FINS_ARC_Monitor) with an aggregate in ACDOCA. That’s the first time ACDOCA entries will be technically reduced.

The aggregate is determined based on the defined granularity of the balance carryforward in connection with the posting period. You can find the settings for the balance carryforward in Customizing under Financial Accounting→General Ledger Accounting→Periodic Processing→Carry Forward→Enter Detail Specifications for Balance Sheet Accounts / Enter Detail Specifications for P&L Accounts.

By implementing SAP Note 2518769, the compression run updates ACDOCA-SGTXT with its run identification. So you can distinguish which ACDOCA record is created by the compression run.

If these aggregated entries balance to zero, the compression run will delete the old entries and no aggregated entries will be created (that is, all documents and transaction figures are already archived).

In case the compression run is executed after document archiving, the effect is mainly a memory footprint reduction. In case it is executed after the archiving of transaction figures, the Data Privacy & Protection requirements of deleting privacy relevant data is fulfilled.

The SAP Universal Journal Detailed Analysis Service supports customers to determine the underlying causes of the data content in their ACDOCA table and options to reduce the data. Using DVM Cloud Solutions for SAP S/4HANA and with the guidance of an SAP consultant, the customer learns more about the required steps and sequencing.

You can archive G/L accounts, customers, vendors, and bank data in FI if the business agrees and if you have fulfilled the legal requirements.

If the business no longer requires a master record for postings, a posting block is set as a first step. If this master record is not required until some point in the distant future, the deletion flag is set manually.

The presence of a deletion flag is one of the requirements that the system checks before archiving the master data. This ensures that the department has no objections against archiving the master data. Therefore only responsible employees should be considered when issuing authorizations for setting deletion flags.

With SAP S/4HANA, customer and vendor master data is maintained using the business partner. For this reason, the customer/vendor master data must be archived before business partner data (archiving object CA_BUPA) can be archived.

• Archiving reduces data volume and fulfills data privacy requirements.
• Archived data remains accessible for audits and evaluations.
• FI documents, transaction figures, and master data can be archived.
• Compression run aggregates data and reduces ACDOCA table size.