SAP–Archivierung: Bereinigung und Archivierung von sehr alten Belegen

Was ist der Sinn von Datenarchivierung und Datenbereinigung?

Die SAP-Datenarchivierung ist ein Entlastungsprozess, der dazu dient, große Datenmengen, die nicht mehr (regelmäßig) benötigt werden, aus der SAP-Datenbank zu entfernen. Dies hilft, das System schlank zu halten und von Altlasten zu befreien. Nach der Datenarchivierung sind die Altdaten noch im Archiv vorhanden und können gelesen, angezeigt und ausgewertet werden.

Welche Hürden gibt es bei einer Datenarchivierung?

Um Belege archivieren zu können, ist eine hohe Datenqualität in der Belegkette notwendig. SAP hat viele Prüfroutinen, welche eine Archivierung nur bei definierten Belegzuständen (insbesondere dem Ziel-Status “abgeschlossen”) innerhalb der Belegkette zulässt. Bei teilweise mehr als 20 Jahre alten Belegen im System gibt es, falls nicht wirklich regelmäßig eine Belegbereinigung erfolgt, zwangsläufig eine hohe Anzahl von Inkonsistenzen und nicht abgeschlossenen Belegen, welche einer Archivierung im Wege stehen, sogenannte „sperrige Belege“. Eine Belegkorrektur über SAP-Standard-Bordmittel führt automatisch die Folgeprozesse aus, wie z.B.

• Verfügbarkeitsprüfung
• Kreditlimit-Prüfung
• Preisfindung
• Unvollständigkeitsprüfung

Das führt ggfs. zu unerwünschten Nebeneffekten, erzeugt neue Änderungsbelege zum Uralt-Beleg und wird nicht immer zielführend bzw. durchführbar sein. Noch schlimmer wird es, wenn zu den zu archivierenden Belegen das Customizing nicht mehr passt oder aktuell implementierte Funktionalitäten in Userexits eine Änderung uralter Belegzustände verhindern und somit eine manuelle Belegkorrektur unmöglich wird. Bei einem unserer Kunden hatten wir die Anforderung, genau solche “sperrigen Belege” zu identifizieren und in einem Archivierungsprojekt zu bereinigen.

Wie können „sperrige Belege“ bereinigt und archiviert werden?

Zunächst müssen die Belegketten und deren Zustände analysiert, gesetzliche Rahmenbedingungen geklärt und Konzepte für die Bereinigung "sperriger Belege“ erarbeitet werden. Hilfsmittel hierzu sind die Protokoll-Dateien aus den Test-Archivierungsläufen sowie diverse Auswertungen (Queries) über die Belegdaten und deren Status-Informationen. Diese Auswertungen zeigen bestimmte Fehlermuster auf, welche dann zu Lösungsvorschlägen zur Bereinigung führen.

In dem angesprochenen Archivierungsprojekt wurde eine technische Lösung zur Umgehung der SAP-Prüfroutinen im Standard-Archivierungsprozess konzipiert und entwickelt. Ziel des Kundenprojektes war es, die “sperrigen” Belege auf möglichst einfache Art und Weise, ohne Belegänderungen durchzuführen, zu archivieren.

Wie kann hier auf unkomplizierte Art und Weise Abhilfe geschaffen werden?

Hierzu wurde bei SPIRIT/21 folgender Prozessablauf zur sogenannten “Zwangsarchivierung” konzipiert und bei dem Kunden implementiert:

1. Seitens der Fachbereiche werden die als nicht manuell bereinigbar identifizierte Belege in eine kundeneigene Tabelle (sogenannte TOMB-Tabelle) geschrieben.
2. Ist zum Zeitpunkt der Belegarchivierung die Belegnummer zum Archivierungsobjekt (Auftrag, Lieferung, Rechnung etc.) in dieser Tabelle vorhanden, erfolgt eine Archivierung des Belegs unabhängig von den Standardregeln der SAP.
3. Dadurch wird eine Belegänderung vor der Archivierung vermieden und die o.g. beispielhaften Folgeaktivitäten kommen nicht zur Wirkung.

Allerdings ist zu beachten, dass diese Vorgehensweise in bestimmten Fällen zu Inkonsistenzen im Datenbestand führen kann, welche dann im Nachgang zu den Archivierungsläufen noch bereinigt werden müssen.

Prinzipieller Ablauf der “Zwangsarchivierung”

Im Archivierungslauf wird bei so gut wie jedem Archivierungsobjekt ein Userexit bzw. Customer-Function durchlaufen, in der nochmals kundenindividuelles Coding implementiert werden kann. Genau diese Stelle kann man sich zu Nutze machen, um hier einen Prozess zur Zwangsarchivierung von Belegen zu implementieren. Hier können im Umkehrschluss aber auch kundenindividuelle Prüfungen dazu führen, dass eine Belegarchivierung über ein kundenindividuelles Regelwerk verhindert wird. Beide Ausprägungen sind möglich.

Design und Entwicklung

Ausprägung der User-Exits zu den jeweiligen Archivierungsobjekten:

Beim Erreichen des Userexits gibt es zwei Möglichkeiten zur weiteren Verarbeitung:

a) Der Beleg wurde von den Standard-Prüfungen als archivierungsfähig erkannt:
Jetzt kann über kundenspezifische Ausschlussbedingungen nochmals ein Beleg von der Archivierung ausgeschlossen werden.

b) Der Beleg wurde von den Standard-Prüfungen als nicht archivierungsfähig erkannt:
Jetzt greift die Zwangsarchivierung über den Eintrag des Belegs in der TOMB-Tabelle und der Archivierungs-Schalter wird auf „True“ gesetzt. Somit erfolgt dann nach Ende des Userexits die Archivierung des Belegs in genau dem Zustand, welcher auf der Datenbank vorzufinden ist, ohne weitere Manipulation von Statuswerten.

Wie wird die TOMB-Tabelle befüllt?

Prinzipiell liegt die Verantwortung zur Befüllung der TOMB-Tabelle mit “sperrigen” Belegen in der Hoheit der Fachbereiche, denen das jeweilige Archivierungsobjekt zugeordnet ist. Auf Basis einer Excel-Tabelle in einem definierten Format wird die TOMB-Tabelle als Trigger für den nächsten Archivierungslauf befüllt.

Durchführung der Datenarchivierung

Bei der nun folgenden Belegarchivierung werden die Userexits zu den jeweiligen Archivierungsobjekten durchlaufen. Hier kommt der oben beschriebene Ablauf in dem jeweiligen Userexit des Archivierungobjekts zur Wirkung und Belege aus der TOMB-Tabelle werden zwangsarchiviert.

Diese Belege sind anschließend wie gewohnt in den Anzeigetransaktionen sichtbar mit dem Hinweis: “Anzeige des Belegs erfolgt aus Archivdaten”. Im Status-Bild eines zwangsarchivierten Kundenauftrags bleibt auch der Status “offen” sichtbar, da keine Belegänderungen vor der Zwangsarchivierung durchgeführt wurden. 

Die Protokollierung des Archivierungsdatums in der TOMB-Tabelle beweist später, dass dieser Beleg absichtlich zwangsarchiviert wurde. Im Belegfluss-Browser (ALO1) sind die Belegflüsse dazu ebenfalls wie gewohnt sichtbar.

Nacharbeiten

Bei offenen Kundenaufträgen bzw. Lieferungen werden die Bedarfselemente in der Disposition durch die Zwangsarchivierung nicht eliminiert bzw. aufgeräumt. Hierzu muss dann im Nachgang zur Archivierung über den Report SDRQCR21 (Siehe SAP-Hinweis 9275 ff) die Bedarfs-Situation überarbeitet bzw. neu ermittelt werden. Danach sind auch die Bedarfsaussagen in der Transaktion MD04 wieder konsistent.

Nebeneffekte

Bei allen zwangsarchivierten Belegen mit der Fehlermeldung „Es sind noch Kosten auf dem Beleg vorhanden (CO-Prüfungen)“ sind nach der Archivierung keine Daten mehr in der Transaktion KVBI sichtbar. Dieser Nebeneffekt muss in der Konzeptionsphase mit dem Controlling abgestimmt bzw. geklärt werden.

Ergebnis der Zwangs-Archivierung von “sperrigen” Belegen im Kundensystem

Im Kundensystem wurde von Beginn der Nutzung 1998 bis heute noch nie archiviert. Für SD-Belege wurde eine Residenzzeit von mindestens 5 Jahren festgelegt. In der ersten Regel-Archivierung innerhalb des Projekts wurde allerdings nur bis zum Jahr 2015 archiviert.

Über die Methode der Zwangsarchivierung via TOMB-Tabelle wurden bis zum Ende des Geschäftsjahres 2015 ca. 200.000 Belege aus den Modulen SD und MM eliminiert. Dieses Volumen wäre über eine reguläre Beleg-Bereinigung niemals zu bewältigen gewesen.

Haben Sie noch Fragen oder ein konkretes Thema in Ihrem SAP-System, bei dem Ihnen der Schuh drückt? Sprechen Sie uns gerne an.