Allgemeine Aufgaben der Datenarchivierung

Die ursprünglichen Aufgaben der Archivierung bestehen darin, die Datenbank insgesamt möglichst klein zu halten – obwohl Plattenplatz inzwischen günstiger ist – und gleichzeitig eine gute Performance der Datenbankfunktionen zu gewährleisten. Man erreicht dies, indem nur noch selten genutzte ältere Daten in andere Speichersysteme (i.d.R. Archivsysteme) ausgelagert werden. Das betrifft sowohl Datensätze aus der Datenbank als auch Anlagen zu Buchungsbelegen, die aber meist aus steuerlichen oder handelsrechtlichen Gründen noch eine bestimmte Zeit aufbewahrt werden müssen. Dabei ist sichergestellt, dass archivierte Belege und Anlagen weiterhin angezeigt und ausgewertet werden können (wenn auch mit gewissen Einschränkungen).

Eine weitere Aufgabe fällt der Archivierung im Kontext des Schutzes personenbezogener Daten zu. Die SAP bietet zur Umsetzung der DSGVO-Anforderungen das auf Archivierungsfunktionen aufbauende „Information Lifecycle Management“ – kurz ILM – an. Dabei werden zu schützende Stammdaten gesperrt sowie Bewegungsdaten archiviert und der Zugriff darauf eingeschränkt. Zum ILM später mehr.

Auch im Zuge der Migration oder Konvertierung von SAP ECC Systemen nach S/4-HANA spielt die
Archivierung eine Rolle. Durch konsequente Reduktion des Datenvolumens von großen Datenbanken im Vorfeld, können die benötigten Zeiten – insbesondere Downtimes – erheblich reduziert werden.

Welche Werkzeuge stellt SAP für die Archivierung zur Verfügung?

Ein altbewährtes und zuverlässiges Werkzeug für die Archivierung ist das „Archive Development KIT“ (ADK). Im ADK werden mehrere inhaltlich zusammengehörige Datenbanktabellen zu sogenannten Archivierungsobjekten zusammengefasst und mit einem standardisierten Set von Programmen (Aktionen) bearbeitet. Als Beispiel dient hier das Archivierungsobjekt für Finanzbuchhaltungsbelege FI_DOCUMNT in der Transaktion SARA:

(Vgl. Grafik 1)

Die wichtigsten bei jedem Archivierungsobjekt vorhandenen Aktionen sind Schreiben, Löschen und das Verschieben ins Ablagesystem (Archiv).

Beim Schreiben wird jeder Datensatz auf Archivierbarkeit geprüft und nur wenn er archivierbar ist, in eine Archivdatei geschrieben. Die Aktion Löschen liest jeden archivierbaren Datensatz aus der Archivdatei und löscht ihn danach aus der Datenbank. Anschließend können die Archivdateien in das angeschlossene Ablagesystem (Archiv) verschoben werden.

Neuer und moderner ist das „Information LifeCycle Management“ (ILM) als Nachfolger des ADK. Das ILM nutzt die Aktionen und Dateistrukturen des ADK als Basis, wurde aber um wichtige Funktionen ergänzt. So tragen die Archivierungsobjekte des ILM oftmals die gleichen Namen wie im ADK, sind aber mit weiter entwickelten Aktionen und Programmen verknüpft.

Die Archivierbarkeitsprüfung wurde durch ein umfassendes Regelwerk ergänzt, das den Status von Geschäftsprozessen, das Fortbestehen eines „Verwendungszweckes“ sowie minimale und maximale Residenzzeiten von Belegen berücksichtigt. So darf ein Datensatz archiviert werden, sobald der zugrunde liegende Geschäftsprozess abgeschlossen, ein „Verwendungszweck“ nicht mehr gegeben und die minimale Residenzzeit abgelaufen ist. Damit können personenbezogene Daten wesentlich früher aus der Datenbank entfernt werden, als das mit jährlichen ADK-Archivläufen möglich wäre.

Eine weitere Neuerung ist die Definition von maximalen Aufbewahrungsfristen im Archiv und die
Aufteilung und Ablage der Archivdateien nach Aufbewahrungsfristen. So können archivierte Daten nach Ablauf ihrer Aufbewahrungsfrist auch aus dem Archiv gelöscht werden.

Welche Besonderheiten müssen beim Umstieg auf S/4-HANA oder der Ersteinrichtung von S/4-HANA beachtet werden?

Mit S/4-HANA hat SAP ein völlig neues Datenmodell eingeführt. Mit dem Umstieg auf spaltenorientierte Tabellen wurde gleichzeitig versucht, die Anzahl der Hilfs- und Sekundärtabellen drastisch zu reduzieren. Prominente Beispiele dafür sind die neuen Tabellen ADOCA und MATDOC, die jetzt die Daten von gleich mehreren früheren Standardtabellen aufnehmen. Für die Archivierung ergeben sich dadurch mehr und neue Abhängigkeiten zwischen Archivierungsobjekten und neue Abläufe.

Weil die Tabellen von mehreren SAP-Anwendungen und Funktionen parallel genutzt werden, müssen die Einträge nach der Archivierung noch eine Zeit lang in der Datenbank verbleiben. Ein Beispiel ist die Notwendigkeit der korrekten Anzeige von Kontensalden nach der Archivierung von Finanzbelegen aus der Tabelle ADOCA

Wie wurde das Problem für die betroffenen Tabellen gelöst?

Die Abbildung unten als Beispiel für die Tabelle ADOCA zeigt den mehrstufigen Prozess der Archivierung von Finanzbelegen. Jeder Kasten (außer FI Documents) symbolisiert ein Archivierungsobjekt, die Pfeile zeigen die Reihenfolge von Archivierungs- und Kompressionsläufen.

Zusätzlich zur Archivierung der eigentlichen Finanzbelege müssen weitere Einträge aus der Tabelle
ADOCA entweder vorher (z.B. CO-Einzelposten) oder danach (Transaktionszahlen für Debitoren,
Kreditoren und das Hauptbuch) archiviert werden. Alle Belege verbleiben in der Datenbank, werden aber als archiviert gekennzeichnet. Erst zum Schluss folgen so genannte Kompressionsläufe, die die verbliebenen Datensätze aggregieren (zusammenfassen) und damit die Zahl der Datensätze in der Tabelle wirklich reduzieren.

(Vgl. Grafik 2)

Fragen und Kontakt

Haben Sie Rückfragen zur Archivierung mit S/4HANA? Einfach schreiben an sapberatung@inwerken.de. Unser SAP-Beratungs-Team meldet sich bei Ihnen! Leistungen darüber hinaus finden Sie in unserem Portfolio.