SAP archiving

Cleaning up and archiving old documents in SAP systems

SAP data archiving is a relief process that is used to remove large amounts of data that are no longer (regularly) required from the SAP database. This helps to keep the system lean and free it from legacy data. After data archiving, the old data is still available in the archive and can be read, displayed and analyzed.

What are the obstacles to data archiving in SAP systems?

In order to be able to archive documents, a high level of data quality is required in the document chain. SAP has many check routines that only allow archiving for defined document statuses (in particular the target status “completed”) within the document chain. With documents in the system that are sometimes more than 20 years old, there is inevitably a high number of inconsistencies and unfinished documents that stand in the way of archiving, so-called “bulky documents”, unless document cleansing is carried out regularly. A document correction via SAP standard on-board resources automatically executes the subsequent processes, such as

• Availability check
• Credit limit check
• Pricing
• Incompleteness check

This may lead to undesirable side effects, generate new change documents for the original document and will not always be expedient or feasible. It gets even worse if the customizing no longer matches the documents to be archived or if currently implemented functionalities in user exits prevent a change to old document statuses, making manual document correction impossible. For one of our customers, we had the requirement to identify precisely such “bulky documents” and to clean them up in an archiving project.

How can “bulky” documents be cleaned up and archived?

The first step is to analyze the document chains and their status, clarify the legal framework and develop concepts for cleaning up “bulky documents”. The log files from the test archiving runs and various evaluations (queries) of the document data and their status information are helpful tools for this. These evaluations reveal certain error patterns, which then lead to suggested solutions for rectification.

In the archiving project in question, a technical solution was designed and developed to bypass the SAP check routines in the standard archiving process. The aim of the customer project was to archive the “bulky” documents in the simplest possible way, without having to make any document changes.

How can document archiving in SAP systems be remedied in an uncomplicated way?

For this purpose, SPIRIT/21 designed the following process flow for so-called “forced archiving” and implemented it for the customer:

On the part of the specialist departments, the documents identified as not manually purgeable are written to a customer-specific table (so-called TOMB table).
If the document number for the archiving object (order, delivery, invoice, etc.) exists in this table at the time of document archiving, the document is archived independently of the standard SAP rules.
This avoids a document change before archiving and the above-mentioned exemplary follow-up activities do not take effect.
However, it should be noted that in certain cases this procedure can lead to inconsistencies in the database, which then have to be corrected after the archiving runs.

Procedure for archiving documents in SAP systems

In the archiving run, a user exit or customer function is run through for almost every archiving object, in which customer-specific coding can be implemented again. It is precisely this point that can be used to implement a process for the forced archiving of documents. Conversely, customer-specific checks can also lead to document archiving being prevented via a customer-specific set of rules. Both options are possible.

Design and development of an SAP archiving project

Development of the user exits for the respective archiving objects:

When the user exit is reached, there are two options for further processing:

1. the document was recognized as archivable by the standard checks: A document can now be excluded from archiving again using customer-specific exclusion conditions.
2. the document was recognized by the standard checks as not suitable for archiving: Now the forced archiving takes effect via the entry of the document in the TOMB table and the archiving switch is set to “True”. This means that after the user exit, the document is archived in exactly the same state as it is in the database, without any further manipulation of status values.

How is the TOMB table filled?
In principle, the responsibility for filling the TOMB table with “bulky” documents lies with the departments to which the respective archiving object is assigned. Based on an Excel table in a defined format, the TOMB table is filled as a trigger for the next archiving run.

Execution of data archiving in the SAP system

During the following document archiving, the user exits for the respective archiving objects are run through. The process described above takes effect in the respective user exit of the archiving object and documents from the TOMB table are forcibly archived.

These documents are then visible as usual in the display transactions with the note: “The document is displayed from archive data”. The status “open” also remains visible in the status screen of a compulsorily archived sales order, as no document changes were made before the compulsory archiving.

The logging of the archiving date in the TOMB table later proves that this document was forcibly archived on purpose. The document flows are also visible as usual in the document flow browser (ALO1).

Rework
In the case of open sales orders or deliveries, the requirements elements in MRP are not eliminated or tidied up as a result of forced archiving. For this purpose, the requirements situation must be revised or redetermined after archiving using report SDRQCR21 (see SAP Note 9275 ff). The requirements statements in transaction MD04 are then also consistent again.

Side effects
For all compulsorily archived documents with the error message “There are still costs on the document (CO checks)”, no more data is visible in transaction KVBI after archiving. This side effect must be coordinated or clarified with Controlling during the design phase.

Result of the forced archiving of “bulky” documents in the customer system

No documents have ever been archived in the customer system since it was first used in 1998. A retention period of at least 5 years was defined for SD documents. In the first regular archiving within the project, however, archiving was only carried out until 2015.

Using the forced archiving method via the TOMB table, around 200,000 documents were eliminated from the SD and MM modules by the end of the 2015 financial year. This volume would never have been manageable using regular document cleansing.