
SAP und DSGVO = SAP ILM
Der Spagat zwischen den Anforderungen der DSGVO und den Bedürfnissen der Fachbereiche nach Datentransparenz ist nicht einfach zu bewältigen. SAP ILM kann helfen.
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.
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.
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.
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.
Hierzu wurde bei SPIRIT/21 folgender Prozessablauf zur sogenannten “Zwangsarchivierung” konzipiert und bei dem Kunden implementiert:
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.
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.
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.
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.
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.
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.
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.
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.
Martin Kreppein, SAP-Senior Berater Logistik
+49 172 629 6793
mkreppein@spirit21.com
Martin ist SAP-Berater im Bereich Vertriebsabwicklung, Materialwirtschaft und Querschnitts-Themen.