Data Aging for SAP Simple Finance

How to use Data Aging for SAP Simple Finance and especially the Journal Entry?

Introduction

To reduce the main memory consumption of the system aging has partly replaced archiving. Aging in contrast to archiving moves data from one (current) partition into another (historical) partition, which writes into an archive and helps the data to get deleted in the database.

Afterwards, using SQL the data is accessible, but from the application server it is typically hidden. For the reports that have to access historical data this default can be overwritten, which is already done.

The following topics are handled:

Can I access existing archives?

By the known reports already existing archive files can be still accessed. The audit information system (AIS) and the DART are especially supported. For operational analysis from archived data new applications that are intended are not enabled to read.

Access to archived data and data in the historical part of the database

To archive some objects as of SAP Simple Finance it is no longer possible, but already archived data is something that we support reading. In the database, data in the historical part of the database and archived data as a result we have a coexistence of current data. Therefore, when we access historical data, the question arises.

In previous releases old data stored in the archive (for e.g. auditing) should be considered as SAP enabled several reports. To provide an access to the complete data set again as of SAP Simple Finance these reports are enabled to also consider the old data that are stored in the historical part of the database. Using the same selection criteria (see e.g. 2076652 for adapting customer code in GL) from archive by enabling the code reading this is typically done and in addition the historical part of the database is also considered.

The archive access is an integral part of the report for some use cases, like access via the logical database BRF. We adapted the query to the (current area of the) database in these cases and the historical part of the database is also consider. To transparently read from the complete database furthermore, for SAP HANA the line item browsers (e.g. transaction FAGLL03H) implemented are also enabled. Based on the selection criteria automatically a decision when to access the historical part is done and in the historical part (based on some status table) which data is present. The full potential of the SQL can be leveraged for accessing the historical part of the database.

Which archiving objects are replaced or affected by SAP Data Aging and the changes to the data model?

By the corresponding aging object Journal Entry (FI_DOCUMENT) the replacement of the archiving object of FI-Documents (FI_DOCUMNT) are done. In the sense of table entries and rules to determine this aging object has a very similar scope as the archiving object from an FI-GL perspective which entry is moved from the (current area) of the database. The aging object handles table ACDOCA additionally as of SAP Simple Finance 1503 and from other applications the corresponding information.

The following archiving objects are obsolete in SAP Simple Finance due to the elimination of totals:

FI_TF_GLC (Classic GL Transaction Figures)
FI_TF_GLN (NewGL Transaction Figures)
FI_TF_DEB (AP Transaction Figures)
FI_TF_CRE (AR Transaction Figures)
CO_TOTAL (CO - Totals)
CO_TOTAL_AO (CO Total Records for Reconciliation Objects)

The following archiving objects are obsolete and the data volume is handled by the aging object In table ACDOCA in application dependent tables due to persisting information that were persisted before SAP Simple Finance:

CO_ITEM (CO Line Items)

Some more archiving objects are partly affected for the same reason. By writing a copy of the data now they still work into the archive (after transformation to the old structure), but in ACDOCA the corresponding table entry is not deleted, as for a different application the entry might be needed. This helps the archived data to remain self-contained. In ACDOCA the entries that are not stored get deleted. To the historical part of the database afterwards, by the aging object this entry is moved. The archiving objects that are affected include:

All archiving objects based on archiving class K_COSTS (e.g. SD_VBAK) : CO documents and totals, Actuals (value type 04)

AM_ASSET (Asset Management): AA Document and part of the totals
CO_ML_BEL (Material Ledger Document): ML documents in some scenarios are stored in ACDOCA
CO_ML_IDX (ML Index): Indices posted after migration to SAP Simple Finance are calculated out of ACDOCA
CO_ALLO_ST (Fully Reversed Documents)
All other archiving objects, like FI-SL document, are not affected.
Handling of Financials data moved to Journal Entry

The NewGL line item table (e.g. FAGLFLEXA) as of SAP Simple Finance 1503 is obsolete and in table ACDOCA the corresponding information is stored. As a result, by ACDOCA in the object definition the NewGL line item table has been replaced.

Handling of Controlling data moved to Journal Entry

Actuals are stored by the journal entry (table ACDOCA) as of SAP Simple Finance 1503 CO. The aging object FI_DOCUMENT moves the corresponding data as a result into the historical part of the database

This data is handled differently depending on the exact type of data:

By ACDOCA Non-Actuals are not persisted and in COEP and other tables they remain. Based on archiving class K_COSTS by the corresponding archiving object they are archived (and deleted from the database) (like SD documents). Via archiving class K_COSTS Non-Actuals that cannot be archived, e.g. cannot be archived nor aged with costcenter as the CO object.

By ACDOCA (items and totals calculated from the items) actuals (value type 04) are persisted. By the compatibility views the CO items and totals as calculated to the archive based on archiving class K_COSTS are written by corresponding archiving objects. In ACDOCA, their entry is not deleted.

By aging object FI_DOCUMENT in ACDOCA the corresponding data is moved together into the historical part of the database with the corresponding document (e.g. BKPF).

To SAP Simple Finance 1503 in table COEP actuals already posted prior (they were migrated into ACDOCA) are stored. The corresponding archiving object deletes this data on archiving class K_COSTS. Based on K_COSTS data that cannot be archived are not aged or archived.

Handling of Asset Accounting data moved to Journal Entry

To the journal entry Asset Management line items and (some of the) totals are moved as of SAP Simple Finance 1503. To database table ACDOCA (in part leveraging a compatibility view) every query is redirected.

Based on archiving class K_COSTS, the situation for archiving object AM_ASSET as a result of that is quite similar to the situation for the archiving objects. In the archiving object together with the asset a copy of the line items and totals (as calculated by the compatibility view) is stored, such that the is self-contained archive is found. During this process the data in ACDOCA is not deleted, but to the historical part of the database ACDOCA is moved later on with FI_DOCUMENT, the aging object.

Handling of Material Ledger data moved to Journal Entry

Material Ledger documents are written to the journal entry partly (when there are posted after the migration) as of SAP Simple Finance 1503 and from the journal entry in all cases (for documents posted after the migration) the index is calculated. In the ML tables as a result, to apply archiving for all data still persisted is possible, but only the data persisted in Journal Entry will not be considered. By the aging object Journal Entry this data is moved.

FI Application Indices

To the document (tables BKPF, BSEG, BSEG_ADD) application indices store redundant information. As of SAP Simple Finance these application indices are eliminated and creation of new entries is not done.

One has the option of keeping the application indices inside of the database when archiving FI-Documents. The corresponding application indices are not redundant as the document is deleted from the database, and are kept in the database. The data is kept inside the database because this data is only accessed exceptionally, but during the migration to SAP Simple Finance move it to the historical part of the database optionally. This is possible in contrast to archives due to the more flexible access possibilities (full SQL) of the historical part of the database, and can help in reducing the memory footprint.

Totals

On the fly based on the line items totals are calculated. As of SAP Simple Finance the totals are eliminated.

The totals typically remain in the system (and were archived based on archiving objects like FI_TF_GLN in previous releases) when FI documents or CO items (based on CO_ITEM) are archived.

Therefore, during the migration to calculate the original values of the totals in addition to the documents the totals of the archived documents must be stored. In table ACDOCA, this information is stored together with the balance carry forward as of SAP Simple Finance 1503. In ACDOCA all entries have document status (BSTAT) 'C' who are simulating these totals.

With the documents, these entries are not aged together. To the memory footprint, they contribute less than documents and only balance carry forward entries are created in future.

Definition of the residence time

To the journal entry several applications are moved and are aged together, i.e. when all applications agree a document is moved. It is needed to have a common definition of the residence time.

For aging the journal entry we use a slightly simplified residence time customizing. A company code and document type dependent residence time can be specified w.r.t. posting date or fiscal year. As a best practice by specifying a fiscal year based residence time of 2 and no residence time w.r.t. posting date the current and the previous fiscal year in the current area of the database can be kept.

Than general ledger Asset Management, Material Ledger and Controlling do not have fundamentally different requirements– the previous fiscal year must remain in the current area of the database probably and at least the current fiscal year. Therefore, it is not provided to do separate residence time customizing, but only after archiving the referenced object additional rules ensure that ACDOCA is moved. E.g. after the referenced CO object is archived a CO item that is persisted in ACDOCA can only be aged.

Read here: Service Preparation for SAP S/4HANA Finance Readiness Check

The specific residence time customizing of CO_ITEM object type– from archiving known– does not apply any longer.

You can define the residence time customizing based on the IMG activity Financials Accounting / Financial Accounting Global Settings / Tools / Data Aging / Data Aging for Accounting Documents / Define Life for Account Types respectively document types.

Can I decrease the residence time for aging compared to archiving?

To separate operationally the residence times and additional checks are used from documents that are important no longer important documents (in addition to ensure the visibility of data needed for some processes further rules like for example open item management). When in historical part of the database the documents are moved your memory footprint is decreased, along with the performance of accessing this data.

For archiving a similar statement can be said, so compared to archiving how to set the residence time is the question that arises for aging:

When an access to this part of the database is enabled, the historical part of the database can be accessed with the full flexibility of SQL. For SAP standard coding this has been enabled and can easily be enabled for customer coding. It might be possible to decrease the residence time depending on your requirements that lead to a late archiving. Where we were able to do this is a good example of the application indices the non-redundant part is completely moved to the historical part of the database (the redundant part is eliminated in addition).

Accessing the current area is faster than accessing the historical part of the database is. You might want to increase the residence time of aging compared to archiving to have more data accessible fast enough if the analytical capabilities of SAP HANA also for older data need to be leveraged. Then in fast memory over time you will have access to more data. Depends heavily on the scenario and how much of that part is buffered in main memory is the performance of accessing historical part.

To summarize whether the residence time should increase, decrease or remain the same it depends heavily on the type and performance characteristics and your business requirements and memory of your analytical applications that is available.

Do I have to change customer code?

Operationally from the (current area of) database to either the archive (e.g. prior to SAP Simple Finance) or the historical part of the database no longer needed data is moved. Therefore, whenever you access archived data consider the historical part of the database if you have to additionally. The necessary changes for SAP standard coding has been implemented by SAP already including modules such as central archiving function. On ADK function modules directly when accessing archived data based customers have to change their own coding.

In database table ACDOCA (journal entry) as of SAP Simple Finance also non FI-GL applications persist their transactional information. In the current area of the database (until moved by aging object FI_DOCUMENT) the information persisted in ACDOCA remains when archiving the corresponding objects of the different applications. Therefore, after archiving the corresponding object data like COEP might still be in the database virtually. When accessing together the current and old (historical or archived) data duplicate information has to be avoided.

Reloading

The data model has been changed dramatically as of SAP Simple Finance 1503. When reloading data archived prior to the migration an on the fly migration and transformation from the old data model to the new data model would be needed. From the archive to the database in several cases it is no longer possible to reload data as of SAP Simple Finance.

Reloading is not supported by the following archiving objects:

FI_DOCUMENT (FI-Documents): was not possible prior to SAP Simple Finance
AM_ASSET (Assets)
CO_ML_BEL (ML-Documents)
CO_ML_IDX (ML-Index) still supports reloading, but the archiving object only handles entries posted prior to SAP Simple Finance. All entries posted afterwards, are stored in ACDOCA and aged.

Reloading is still supported by CO-Objects like CO order that archived CO data based on K_COSTS. After archiving this CO object one has to take care that no aging run (aging the corresponding ACDOCA entries) took place. In addition to every potential issue this has to be ensured when reloading data.

In SAP Simple Finance aging is not reversible, i.e. from the historical part of the current area again the data is not possible to be moved.