Archiving Financial Accounting

Documents (FI-GL, FI-AR, FI-AP)

Definition
You can archive financial accounting documents (FI documents, journal entries) using
theFI_DOCUMNT archiving object.

To manage memory consumption, you can also use data aging for financial accounting
documents. For more information, refer to Data Aging for Financial Accounting
Documents.

You can access financial accounting documents that have already been archived. For
more information, refer to Displaying Archived Accounting Documents (FI).

Use
When you archive documents, the system writes the archivable documents, including
change documents, SAPscript texts, and ArchiveLink linkage data, to one or more
archive files.

A number of conditions must be met to ensure that only documents, which are no longer
needed in the online system, are archived. The write program checks the document
header and line items to determine whether a document can be archived. For more
information, refer to Checks (FI-GL, FI-AR, FI-AP).

Structure
Tables

Archiving object FI_DOCUMNT is used to archive data from different tables. For more
information about how to display the table names, refer to Tables and Archiving
Objects.

The system copies the structure of line-item tables in the general ledger, such
as FAGLFlEXA, that existed before SAP S/4HANA into the archive because they are
necessary for displaying archived journal entries. This information is calculated using
table ACDOCA and no information is deleted.

In addition, table ACDOCA is archived, but not deleted because this table is also used for
calculating balances (transaction figures). G/L transaction figures are archived using
archiving object FI_TF_GLF. The entries in the table are changed, so that they're no
longer used for line item and journal entry reports. The entries of the table are deleted
when the data is compressed.

For AP/AR transaction figures, which are primarily based on tables BKPF and BSEG,
either table LFCX_DIF or KNCX_DIF is adjusted to the balance of the archived journal
entries is stored. So, the transaction figures in AP/AR are the result of the sum of the
journal entries in the database and these tables. You use the archiving
objects FI_TF_DEB and FI_TF_CRE to archive those tables.

In contrast to other archiving objects, the delete runs of archiving

object FI_DOCUMNT and FI_TF_GLN don’t delete entries in table ACDOCA. Instead,
archiving object FI_DOCUMNT marks these entries as total relevant only. For
example, BSTAT is changed to C in balance carry forward entries to avoid changing
balances during document archiving. Archiving object FI_TF_GLN doesn’t delete
entries, but it inserts entries with the opposite amounts. Later, the archiving
compression run potentially aggregates multiple entries by replacing them (DELETE old
entries INSERT new entries).

If you are using replication, such as SLT-based replication, and this procedure ignores
archiving by ignoring delete statements, please refer to SAP Note 2617971 .

Extended Archive Management

In addition to the management data generated by ADK, archiving

object FI_DOCUMNT writes additional management data to
tables T001_ARCH and ADMI_FI_DOC.

Programs

The following programs are delivered for FI_DOCUMNT.

 Program Function

FI_DOCUMNT_WRI Write

FI_DOCUMNT_DEL Delete

FI_DOCUMNT_PST Postprocessing

SAPF048S Correction: Building of secondary indexes

SAPF048X Correction: Repair of extended archive management

The delete program contains the standard variants SAP&PROD (production mode) and
SAP&TEST (test mode). During the write and delete sessions, regular progress
messages appear in the job log (background processing) and in the status line (dialog).

Integration
Note
You can use archiving object FI_DOCUMNT in Information Lifecycle Management. You
must have activated the corresponding business functions to do this. The system then
also shows the ILM Actions group box. You can use these actions to carry out
archiving, for example, where the retention periods stored in the Information Retention
Manager can be evaluated. Additionally, you can create snapshots (copies) of data or
destroy data that matches the requirements. For more information, see ILM
Enhancements for Data Archiving, ILM Actions in the Write Program.
Secondary Indexes in Financial Accounting

A number of programs in financial accounting do not use journal entries / financial

accounting documents (tables BKPF and BSEG) directly. Instead they use a secondary
index, that is implemented as a view on BKPF and BSEG. BSIP, in contrast, is a data
base table. See also Displaying Archived Accounting Documents (FI).

Since a lot of programs use this data, there is the possibility to keep this data for a
longer period of time in the system even when the journal entry has already been
archived. If you set the run time of the secondary index greater than the account type
life, the system writes, when archiving the journal entries, a redundant copy to the data
base (table BSIS_ BCK, BSAS_ BCK, BSAD_BCK, BSAS_BCK). For more information,
see Secondary Index Life in Financial Accounting (FI).

When the secondary index run time has expired, you can later on remove these entries
from the data base using the Postprocessing Program (FI).

You can use the secondary index build program to reconstruct the secondary indexes
from the archived document data and store them again in the database, if necessary
(except for BSIM entries).

Note
 If you archive data because of reasons of data protection and privacy, note that
secondary indexes may contain personal data. For this reason, secondary
indexes are not allowed to have a greater run time.

 In S/4HANA almost all accounts are managed based on line items. So secondary
indexes might have a bigger data volume than in other SAP products.

 If you use data aging and you want to keep secondary indexes longer in the
system, maintain the partitioning object FI_INDEX in order to create historical
partitions for BSIS_BCK, BSAS_BCK, BSAD_BCK and BSAK_BCK. Then the
secondary indexes that are created during archiving are directly written to the
historical partition. For more information see Data Aging for Financial Accounting
Documents

Archiving Double-Entry Invoicing Data

The double-entry invoicing data (table BSIP) is deleted by the archiving

object FI_DOCUMNT. So that you can store this data in the database longer than the
financial accounting document itself, it is removed from the database together with the
vendor secondary indexes (table BSAK) by the postprocessing program and not by the
delete program.

The double-entry invoice verification can take place as long as the vendor secondary
index BSIP still exists in the database, even if the corresponding document was already
archived.
In Customizing for account type lives (to archive financial accounting documents) you
should set the secondary indexes for vendors so that the data for the double-entry
invoice verification remains in the system for the required period of time. For more
information about archiving account type lives, see Archiving Account Type Lives in
Customizing for Financial Accounting under Financial Accounting Global
Settings Document Archiving Accounting Documents.

Cross-Company Code Posting Processes (Table BVOR)

The archived documents of a cross-company code posting process are treated in the
following manner:

1. For every document the write program copies not only the data record of the
cross-company code posting process to the archive, but all data records of the
same cross-company code posting process (field BVOR-BVORG) to which the
document to be archived belongs. This ensures that the information about the
cross-company code posting process is completely available for a direct access
to the archive.

2. For every archived document the delete program sets the BVOR-
XARCH indicator. Then for every archived document of a cross-company code
posting process it tries to delete all data records of the complete corresponding
cross-company code posting process. However, a cross-company code posting
process can only be deleted from the database, when all documents of a cross-
company code posting process have been archived (technically this means that
in the database the BVOR-XARCH indicator must be set for all BVOR entries with
the same BVOR-BVORG).

Archiving Bank Communication

Management Using BNKCOM_ARC
You can use archiving object BNKCOM_ARC to archive bank communication
management.

Tables
BNKCOM_ARC archives data from several tables. To check which tables these are, call
up transaction SARA, enter the archiving object, and choose Database Tables. You can
display the relevant tables in the lower part of the screen.

Archiving Classes

BNKCOM_ARC may trigger further archiving classes to write additional data, for example
change documents, into the archive. To check which classes these are, call up
transaction AOBJ, select your archiving object and choose Archiving Classes Used.

Programs

To find out which programs this archiving object offers, call up transaction AOBJ and
double-click on your archiving object.

Prerequisites
The following prerequisites must be fulfilled before a bank communication management
batch can be archived:

 The date of the file generation (field LAUFD_F in the

table BNK_STR_BATCH_HEADER) of the selected batches must be within a
posting period that is closed for postings in financial accounting.

ILM-Related Information for the Archiving

Object
You can use this archiving object with the BNKCOM_ARC ILM object as part of SAP
Information Lifecycle Management. In transaction IRMPOL, you can create policies for
residence or retention rules, depending on the available policy category. Here you can
also see the available time references and which condition fields exist, and decide
which of them shall be used in which order to define your rule structure.

The following condition fields are available:

 BS_COUNTRY_OF_BUKRS (Standard Field Country from Company Code)

 BUKRS (Paying Company Code)

  CRDATE (Created On)

The following time references are available:

 CREATION_DATE (Created On)

Defining Write Variants

When you schedule the archiving run, you must enter an existing variant or create a
new one. You can do so in transaction SARA.

A write variant contains the parameters for the bank communication management that
you want to archive.

SAP delivers the following parameters:

 Processing Options

 Detail Log

 Log Output

 Archiving Session Note

Defining Preprocessing Variants

The preprocessing program for BNKCOM_ARC sets the archive_status field to value 02
(Document set for Archive) of bnk_batch_header (Batch Header) so that bank
communication management can be archived.

You can define variants for this program using the following parameters:

 Processing Options

 Detail Log

 Log Output

Defining Read Program Variants

A read program RBNK_ARC_READ sequentially reads from a given archive and displays
the data. You can define the following selection criteria for this program:

 Batch Number

 Rule ID

 Batch Amount

 Batch Currency

 No. of Payments

 Create Date

Dependencies of BNKCOM_ARC
For information on the archiving session order, see the Network Graphic for your
archiving object in transaction SARA under Goto → Network Graphic.

Authorizations for BNKCOM_ARC

You need the following authorization objects:

Activity Required Authorization Object

READ (read and display batch or batch F_STAT_MON

item)

01 (write, delete, and read) S_ARCHIVE

Displaying Bank Communication Management

Archived with BNKCOM_ARC
Single document display: A read program that RBNK_ARC_READ sequentially reads
from a given archive and displays the data.

Secondary Index in Financial

Accounting (FI)
Formerly it was possible to keep a secondary index in the database when archiving
financial accounting documents. As there may be documents archived already, the
secondary indexes corresponding to archived documents are kept in the system. They
are stored in a database table with the original name followed by _BCK). It is possible to
delete a secondary index after a certain period of time (specified by the secondary index
life time) and it is possible to build up secondary indexes from archived documents.

Postprocessing Program (FI)

Use
The postprocessing program is used to delete the secondary indexes of financial
accounting from the database, according to the secondary index life you entered in
Customizing.

You can start the postprocessing program and enter the necessary selection criteria,
from within Archive Administration by choosing Postprocessing.

Features
The post processing program deletes all secondary indexes whose lives have expired
by the key date. The index life runs from the clearing date (or the posting date in the
case of accounts not managed on an open item basis). The documents belonging to the
secondary index must already have been archived.

The program deletes the secondary indexes from tables BSIS_BCK, BSAS_BCK,
BSAD_BCK, BSAK_BCK, BSIP, FAGLBSIS_BCK, and FAGLBSAS_BCK.

Note
The postprocessing program takes clearing transactions into account, meaning that if
you select both cleared and open items for display, the displayed balance can be
incorrect. In accounting terms no error has occurred, since the balance is equivalent to
the total of open items. You should therefore display balances using the account
balance function and not line item display.