Prüfung auf das Ende des Verwendungszwecks und ILM-basierte Archivierung

[johannes_gilbert]

Inhaltsverzeichnis

Haftungsausschluss
Executive Summary
Danksagung
Präambel

1 Einstieg und vereinfachter Ermittlungsansatz für das Ende des Verwendungszwecks

• 1.1 Notwendigkeit der Löschung


• 1.2 Sperrung


• 1.3 Ende des Verwendungszwecks


• 1.4 (vereinfachte) Ermittlung des Endes des Verwendungszwecks

2 Erweiterung der Ermittlung des Endes des Verwendungszwecks um Karenzzeiten

• 2.1 Karenzzeiten


• 2.2 Kriterien für die Definition von Karenzzeiten


• 2.3 Ende des Verwendungszwecks für Stamm- und Bewegungsdaten

3 Karenzzeiten im Detail

• 3.1 Übersicht über Karenzzeiten


• 3.2 Abweichende Definition der Karenzzeiten K₁ und K_2.2


• 3.3 Anwendungsspezifische Karenzzeit bei der Archivierung - K_2.1


• 3.4 Rechnungslegungsvorschriften für Unternehmen

Haftungsausschluss

Der nachfolgende Artikel befasst sich mit einer Mischung aus rechtlichen und betriebswirtschaftlichen Anforderungen. Dadurch ist es in der Regel nahezu unmöglich für alle erdenklichen Anwendungsfälle allgemeingültige, korrekte sowie juristisch einwandfreie Aussagen zu treffen. Dieser Artikel möchte keinesfalls Rechtsberatung bieten noch sollte er so interpretiert werden.

Executive Summary

Dieser Artikel dient dem Verständniszuwachs und ggf. als Nachschlagewerk für den Themenkomplex Ermittlung des Endes des Verwendungszwecks und SAP Information Lifecycle Management (ILM)-basierter Archivierung. Die Begriffe Verwendung, Sperrung, Löschung, Karenzzeit und Aufbewahrungsfirst werden erläutert und in einen Zusammenhang gebracht. Dabei werden verschiedene Konfigurationen ebendieser Zeiträume betrachtet und kritisch analysiert.

Danksagung

Meinen Kollegen Reinhard Scheid, Manuel Brand und Paul Townsend möchte ich besonderen Dank aussprechen. Durch ihre Kommentare und Rezensionen konnte dieser Artikel korrigiert, verbessert und abgerundet werden.

Präambel

Zugegeben sind die nun folgenden einleitenden Worte mit einer guten Portion Humor zu verstehen. Der in diesem Artikel betrachtete Themenkomplex ist vor allem komplex. Einsteiger sollten diesen Artikel keinesfalls in einem Zuge durchlesen. Gönnen Sie sich Pausen. Konsumieren Sie die einzelnen Kapitel mit zeitlichem Abstand. Verzweifeln Sie nicht, sollten Sie sich bereits nach kurzem verloren vorkommen.

1 Einstieg und vereinfachter Ermittlungsansatz für das Ende des Verwendungszwecks

1.1 Notwendigkeit der Löschung

Kapitel 2 der Datenschutzgrundverordnung (DSGVO) sieht Grundsätze für die Verarbeitung personenbezogener Daten vor. ''Personenbezogene Daten müssen [...] für festgelegte, eindeutige und legitime Zwecke erhoben werden und dürfen nicht in einer mit diesen Zwecken nicht zu vereinbarenden Weise weiterverarbeitet werden'' (Art. 5 Abs.1 DSGVO). Aus diesen Grundsätzen ergibt sich in der Regel die Notwendigkeit personenbezogene Daten zu löschen, wenn der sog. Verwendungszweck erloschen ist. Ein Beispiel:

Kunde Miller tätig eine Bestellung. Drei Tage später, die Bestellung wurde noch nicht bearbeitet, zieht er seine Bestellung zurück. Während dieser drei Tage darf die Bestellung sowie alle zusätzlich notwendigen Daten gespeichert werden. Der primäre Verwendungszweck ''Bestellung-Verkauf-Lieferung'' ist während dieser drei Tage sozusagen aktiv. Nach diesen drei Tagen ist ebendieser primäre Verwendungszweck erloschen. Damit müssen die personenbezogenen Daten (die Bestellung + ggf. zusätzliche erhobene personenbezogene Daten) gelöscht werden.

Abbildung 1.1 Verwendung und Löschung

1.2 Sperrung

Das Löschen von (personenbezogenen) Daten direkt mit dem Erlöschen des primären Verwendungszwecks wird jedoch meist durch andere Gesetze verhindert. Das prominenteste Beispiel für den Rechtsraum Deutschland ist die AO. Die AO definiert Aufbewahrungspflichten und verhindert somit die Löschung ebendieser Daten für einen definierten Zeitraum. Für diesen Fall hat die DSGVO mit Artikel 17 Abs. 3b vorgesorgt. Kann auf Grund anderer gesetzlicher Regelungen nicht gelöscht werden, tritt solange die Verpflichtung der Sperrung der (personenbezogenen) Daten ein. D.h. normalen Anwendern ist der Zugriff auf solche gesperrten Daten zu verwehren. Ausschließlich Anwender mit spezieller Berechtigung (und auf Grund rechtlich zulässiger Gründe) dürfen solche Daten anzeigen (z.B. ein Steuer-/ Wirtschaftsprüfer). Über die Art und Weise bzw. die technische Umsetzung der Sperrung von Daten finden sich im Gesetzestext keine konkreten Bestimmungen. Die zur Sperrung ergriffene Maßnahme muss jedoch real dazu geeignet sein und im konkreten Fall auch angewandt werden. Das Setzen eines Sperrkennzeichens (z.B. ein boolescher Wert) kann dazu geeignet sein. In Kombination mit Berechtigungsprüfungen erwirkt das Sperrkennzeichen eine Zugriffs- und somit auch eine Verarbeitungsbeschränkung.

Die Sperrung tritt folglich nach dem Erlöschen des primären Verwendungszwecks ein und dauert bis zur Löschung der Daten an. Die Aufbewahrungsfrist laut AO umfasst die ebenselbe Dauer.

Abbildung 1.2 Verwendung, Sperrung und Löschung

1.3 Ende des Verwendungszwecks

Bildlich gesprochen ist mit dem Ende des Verwendungszwecks die Pfeilspitze des gelben Pfeils gemeint.

Abbildung 1.3 Ende des Geschäftsvorfalls

Genau genommen handelt es sich dabei um die Ermittlung eines (Kalender-)Datums. In unserem Beispiel der stornierten Bestellung ist dies das Stornodatum. Je nach Geschäftsvorfall kann dieses sog. Enddatum des Geschäftsvorfalls (engl. end of business) verschieden sein. Bspw. wird es bei einer nicht stornierten Bestellung kein Stornodatum geben. Vielmehr wird das Lieferdatum herangezogen werden. Sie sollten sich bewusst sein, dass die Ermittlung des Enddatums des Geschäftsvorfalls innerhalb von SAP Software nicht nur Produkt-spezifisch, sondern auch Modul-spezifisch, Belegtyp-spezifisch etc. ist und damit maximal individuell.

Während die Ermittlung des Enddatums des Geschäftsvorfalls für transaktionale Daten (bspw. Bestellungen, Fakturen, ...) prozessspezifisch ist, ist die Ermittlung des Enddatums des Geschäftsvorfalls für Stammdaten in der Regel noch komplexer. Bereits die Terminologie weist darauf hin, dass ein einfacher Übertrag nicht möglich ist. Bei Stammdaten bietet es sich daher an vom sog. Ende des Verwendungszwecks (engl. end of purpose) zu sprechen.

Stammdaten ist immanent, dass sie gerade keine von einem Prozess oder anderweitig vorgegebene ''Haltbarkeitszeit'' aufweisen. Nehmen wir das Beispiel eines Kunden (KNA1-Satz). Ein solcher Kunde existiert. Bis wann? Ohne Datenschutzgesetzgebung oder etwaige andere gesetzliche Vorschriften für immer. Es gibt nicht zwangsläufig einen Prozess oder eine organisatorische Maßnahme, die die Verwendung von Kundenstammsätzen zeitlich begrenzt (und ggf. löscht). Auf Grund der DSGVO ist ein solches Gebaren allerdings nicht möglich. Ein Kunde darf nur solange existieren, wie es nicht erloschene, primäre Verwendungszwecke gibt. Das Ende des Verwendungszwecks für einen (personenbezogenen) Stammsatz (blaugepunktete Linie) ergibt sich daher im Allgemeinen ausschließlich aus den Endedatümern aller mit diesem Stammsatz verknüpften Geschäftsvorfällen (gelbe Pfeile).

Abbildung 1.4 Ende des Verwendungszwecks

Mathematisch betrachtet lässt sich das Ende des Verwendungszwecks eines (personenbezogenen) Stammsatzes wie folgt beschreiben:

EoB_Partner = max( EoB_{Gesch.Prozess1}, EoB_{Gesch.Prozess2}, ..., EoB_{Gesch.ProzessN})

In Prosa: Das Enddatum des Verwendungszwecks für einen Geschäftspartner (Partner bzw. Geschäftspartner steht hier gleichbedeutend für SAP Geschäftspartner (BUT000), Kunden (KNA1), Lieferanten (LFA1), Kontaktpersonen (KNVK))) ergibt sich aus der Menge der Geschäftsvorfälle dieses Partners und zwar aus dem maximalen Enddatum all dieser Geschäftsvorfälle.

1.4 (vereinfachte) Ermittlung des Endes des Verwendungszwecks

Für die Ermittlung des Endes des Verwendungszwecks für einen Geschäftspartner ergibt sich somit folgender Ablauf:

1. Ermittlung aller Geschäftsvorfälle dieses Geschäftspartners.


2. Ermittlung des Enddatums je Geschäftsvorfall.


3. Maximalwertbestimmung über alle Enddatümer (= Ende des Verwendungszwecks)

Dieser Ermittlungablauf weist einen erheblichen Nachteil auf. Es besteht eine starre und unmittelbare Kopplung zwischen den Enddatümern der Geschäftsvorfälle und dem Ende des Verwendungszwecks des Geschäftspartners. Insbesondere besteht bei diesem vereinfachten Ansatz keine Möglichkeit irgendeine Form einer Karenzzeit zu berücksichtigen. Aus diesem Grund findet dieser Ansatz auch keine direkte Umsetzung in SAP Produkten.

Gleichwohl dieser Ermittlungsansatz zu stark vereinfacht ist, so stellt er doch das Grundprinzip der Ermittlung des Endes des Verwendungszwecks ohne Umschweife und ohne allzu komplexe Details dar und sollte verstanden sein, bevor die nachfolgenden (komplexen) Details erörtert werden.

Zeit für eine Kaffee- oder Teepause

2 Erweiterung der Ermittlung des Endes des Verwendungszwecks um Karenzzeiten

2.1 Karenzzeiten

Findige Leser werden mit dem Begriff Karenzzeit gleich die sog. ILM Verweilfristen (auch Residenzzeiten oder engl. residence period) in Verbindung bringen. Für ''unbelastete'' Leser und solche, die sich mit der ILM Nomenklatur bereits überworfen haben, und im Übrigen auch für alle anderen Leser, ist es aus didaktischen Gründen jedoch ratsam bis auf weiteres von einer Karenzzeit zu sprechen. Genaugenommen ist auch die ILM Verweilfrist nur eine Ausprägung einer Karenzzeit bei der Ermittlung des Endes des Verwendungszwecks.

Das Paretoprinzip (80-20-Regel) trifft auch bei der Ermittlung des Endes des Verwendungszwecks zu. Der oben geschilderte vereinfachte Ermittlungsansatz bedarf maximal 20% des Kognitiven- und auch des Implementierungsaufwands, um bereits 80% der Gesamtlösung zu erzielen. Nun wollen wir uns mit den restlichen 20% der Lösung beschäftigen, die allerdings 80% oder mehr des geistigen und Arbeitsaufwands benötigen.

Aus technischer Sicht ist das Nichtvorhandensein einer Karenzzeit beim Ermittlungsvorgang vollständig in Ordnung. Aus betrieblicher Sicht kann eine Karenzzeit jedoch notwendig sein. Gründe für die Notwendigkeit einer Karenzzeit sind insbesondere:

• Betriebsinterne Abläufe, z.B. jährliche Revision


• Rückläufer, Reklamationen, Widerrufsfristen


• Garantiezeiten


• ...

Durch die unterschiedlichen Beweggründe für eine Karenzzeit ergeben sich meist unterschiedliche Dauern einer Karenzzeit z.B. je nach betrachtetem Prozess. Mehr noch, eine Karenzzeit muss anhand verschiedener Kriterien definiert werden können und mehrere, sich überlagernde Karenzzeiten sind ebenfalls nicht von der Hand zu weisen. Zur Veranschaulichung ziehen wir wieder das eingangs erwähnte Beispiel heran:

Kunde Miller gibt eine Bestellung auf, die dieses Mal nicht nach drei Tagen storniert, sondern wie üblich bearbeitet und beliefert wird. Mit der Lieferung erfolgt die Rechnungsstellung. Kunde Miller zahlt einige Tage nach Erhalt der Ware.

Abbildung 2.5 Geschäftsvorfälle Bestellung, Lieferung und Faktura

Unter der Annahme, dass die Faktura der abschließende Geschäftsvorfall des Kunden Miller ist (also insbesondere ignorieren wir an dieser Stelle zur Vereinfachung Buchhaltungsprozesse und ähnliche), so ergibt sich nach dem vereinfachten Ermittlungsansatz ein Ende des Verwendungszwecks, das gleich dem Ende der Faktura ist. Aus oben genannten Gründen werden nun aber Karenzzeiten hinzugezogen. Wir definieren an dieser Stelle folgende Karenzzeiten:

Tabelle 2.1 Karenzzeiten

Typ des Geschäftsvorfalls	Karenzzeit
Bestellung	1 Woche
Lieferung	8 Wochen
Faktura	4 Wochen

Die schematische Darstellung der Geschäftsvorfälle ändert sich wie folgt: An der direkten Aufeinanderfolge der Geschäftsvorfälle ändert sich nichts. Sie bleibt erhalten. Jedoch werden bei der Ermittlung des Endes des Verwendungszwecks ebendiese Karenzzeiten berücksichtigt.

Abbildung 2.6 Geschäftsvorfälle ohne und mit Karenzzeiten

Es ist zu beachten, dass je nach (ggf. unsinnigen) Karenzzeiten auch ein anderer Geschäftsvorfall der letztlich maßgebliche für das Ende des Verwendungszwecks sein kann.

Abbildung 2.7 Variierung der Karenzzeiten für Geschäftsvorfälle

Zeit für eine Entspannungsübung

2.2 Kriterien für die Definition von Karenzzeiten

Bisher haben wir die Karenzzeit nur anhand des Typs des Geschäftsvorfalls unterschieden. Prinzipiell spricht (außer der enormen Komplexitätssteigerung) nichts dagegen, auch innerhalb eines solchen Typs weitere Differenzierungen vorzunehmen. Beispielsweise könnte die Karenzzeit der Lieferung von der Lieferart abhängen. Je nach Typ des Geschäftsvorfalls werden sehr spezielle Kriterien, die nur dieser Typ aufweist, potentiell in Frage kommen. Es kann aber auch Kriterien geben, die bei mehreren Typen von Geschäftsvorfällen relevant sind. Zur Verdeutlichung betrachten wir einige Konkrete Beispiele:

Kriterien für die Definition von Karenzzeiten für Bestellungen:

• Auftragsart


• Verkaufsbelegtyp


• Verkaufsorganisation

Kriterien für die Definition von Karenzzeiten für Lieferungen:

• Lieferart


• Verkaufs- bzw. Kundenbezirk


• Verkaufsbelegtyp


• Verkaufsorganisation

Kriterien für die Definition von Karenzzeiten für Fakturen:

• Fakturaart


• Verkaufsorganisation

In diesem Beispiel weisen alle drei Typen von Geschäftsvorfällen das Kriterium Verkaufsorganisation auf. Ähnlichkeiten bestehen offenbar beim Verkaufsbelegtyp. Ein Kriterium, der Verkaufs- bzw. Kundenbezirk, ist lediglich bei Lieferungen vorzufinden. Wir erweitern die Tabelle zur Definition von Karenzzeiten wie folgt:

Tabelle 2.2 Karenzzeiten in Abhängigkeit von Kriterien

Typ des Geschäfts- vorfalls	Auftragsart	Verkaufs- belegtyp	Verkaufs- organisation	Lieferart	Verk.-/ Kundenbezirk	...	Karenzzeit
Bestellung	*	*	DE	-	-	...	1 Woche
Bestellung	*	*	FR	-	-	...	2 Wochen
Lieferung	-	*	DE	*	*	...	8 Wochen
Lieferung	-	*	FR	*	*	...	9 Wochen
Faktura	-	-	DE	-	-	...	4 Wochen
Faktura	-	-	FR	-	-	...	5 Wochen

Legende: Kriterium nicht vorhanden ⬄ -
Kriterium irrelevant ⬄ *

Durch die zusätzlichen Kriterien ist es möglich - wie die Wertbelegung in der oberen Tabelle zeigt - die Karenzzeit verkaufsorganisationsspezifisch auszuprägen. Die ursprünglich drei Karenzzeiten werden nun nach Land (DE, FR) unterschieden. Zudem ist die Karenzzeit für Land FR stets eine Woche länger, wie die jeweilige Karenzzeit für Land DE.

Tabelle 2.2 zeigt jedoch auch einen klaren Nachteil. Fast alle Spalten (Kriterien) werden nur von einem Geschäftsvorfalltyp verwendet und nur wenige mehrfach. Daher ist die Tabelle dünn besetzt (siehe dazu https://de.wikipedia.org/wiki/Dünnbesetzte_Matrix). Durch Hinzufügen weiterer Typen von Geschäftsvorfällen mit weiteren Kriterien, würde die Tabelle ein gewaltiges Ausmaß annehmen. Gleichzeitig würde Verwendbarkeit der Tabelle gegen Null tendieren. Neben der schlechten Nutzbarkeit gibt es aber auch technische Nachteile einer solchen Tabelle:

• Das Hinzufügen neuer Typen von Geschäftsvorfällen resultiert in der Notwendigkeit neuer Spalten.


• Gleiches gilt für das Hinzufügen neuer Kriterien für einen bestehenden Typ.

Eine Lösungsmöglichkeit für das Problem solcher dünn besetzten Tabellen ist das Aufteilen in mehrere Tabellen. Durch die Andersartigkeit der Typen von Geschäftsvorfällen bietet es sich an, eine Tabelle je Typ zu verwenden. Damit ist auch bereits für die Möglichkeit gesorgt zukünftig weitere Kriterien je Typ zu definieren bzw. Erweiterungsmöglichkeiten je Typ zu realisieren.

Tabelle 2.3 Karenzzeiten für Bestellungen

Auftragsart	Verkaufsbelegtyp	Verkaufsorganisation	Karenzzeit
*	*	DE	1 Woche
*	*	FR	2 Wochen

Legende: Kriterium irrelevant ⬄ *

Tabelle 2.4 Karenzzeiten für Lieferungen

Lieferart	Verk.- bzw. Kundenbezirk	Vertriebsbelegtyp	Verkaufsorganisation	Karenzzeit
*	*	*	DE	8 Wochen
*	*	*	FR	9 Wochen

Legende: Kriterium irrelevant ⬄ *

Tabelle 2.5 Karenzzeiten für Fakturen

Fakturaart	Verkaufsorganisation	Karenzzeit
*	DE	4 Wochen
*	FR	5 Wochen

Legende: Kriterium irrelevant ⬄ *

Für die bisherige Schematik ergibt sich durch die Karenzzeit folgende Änderung:

Abbildung 2.8 Verwendung, Karenzzeit, Sperrung und Löschung

Die Karenzzeit wird von der Dauer der Sperrung abgezweigt. Das mag manchen überraschen. Die Erklärung ergibt wie folgt: Erstens kann die Karenzzeit nicht Bestandteil der Dauer der Verwendung sein, da diese mit einem dem Geschäftsvorfall immanenten Datum endet. Zweitens besteht laut §147 AO kein Zusammenhang zwischen der Aufbewahrungsfrist und einer Karenzzeit . Die Aufbewahrungsfrist richtet sich (in Deutschland) ausschließlich nach dem Erstellungsdatum (siehe §147 Abs. 4 AO).

2.3 Ende des Verwendungszwecks für Stamm- und Bewegungsdaten

Einigen Lesern mag bereits aufgefallen sein, dass der Zusammenhang zwischen Stamm- und Bewegungsdaten in den bisherigen Abbildungen nicht mit ausreichender Deutlichkeit differenziert wurde. Die nachfolgende Abbildung stellt die Abschnitte Verwendung, Karenzzeit, Sperrung und Löschung für Stamm- und Bewegungsdaten separiert dar. Zunächst betrachten wir nochmals die Bestellung. Für diese ergibt sich folgendes Schaubild:

Abbildung 2.9 Verwendung, Karenzzeit, Sperrung und Löschung für die Bestellung

Wir erweitern diese Abbildung nun um das bisher nicht visualisierte Stammdatum Kunde. Die Verwendungsdauer des Geschäftspartnerstammsatzes (grüner Pfeil) beträgt per Definition die Verwendungsdauer der Bestellung plus deren Karenzzeit. Mit Ablauf der Karenzzeit der Bestellung sind die Bestellung selbst und auch der Geschäftspartnerstammsatz zu sperren.

Abbildung 2.10 Verwendung, Karenzzeit, Sperrung und Löschung für Bestellung und Geschäftspartnerstammsatz

Zum Zwecke der Steuer- und Wirtschaftsprüfung reicht es nicht aus, nur die Bestellung aufzubewahren. Auch der Kundenstamm ist vorzuhalten. Die Dauer der Aufbewahrung des Geschäftspartnerstammsatzes ergibt sich aus dem Datum des Endes des Verwendungszwecks und aus dem Aufbewahrungsfrist der Bestellung. Beide Fristen enden gleichzeitig (bzw. am selben Tag), da der Geschäftspartnerstammsatz keinesfalls vor der Bestellung gelöscht werden kann. Die Sperrung des Geschäftspartnerstammsatzes umfasst in diesem Fall (wir betrachten gerade nur die Bestellung) exakt die gleiche Zeitspanne wie die Sperrung der Bestellung.
Nun sollen auch die Lieferung und die Faktura in das Schaubild aufgenommen werden, um das Gesamtbild herzustellen. Die Abbildung wird zunächst um die Lieferung erweitert.

Abbildung 2.11 Verwendung, Karenzzeit, Sperrung und Löschung für Bestellung, Lieferung und Geschäftspartnerstammsatz

Wie der Unterschied zur vorherigen Abbildung zeigt, hat sich durch die zusätzliche Betrachtung der Lieferung das Ende des Verwendungszwecks des Geschäftspartnerstammsatzes geändert. Es liegt nun weiter in der Zukunft. Zudem ist die Aufbewahrungsfrist für den Geschäftspartnerstammsatz nun geändert. Sie beginnt mit dem Ende des Verwendungszwecks, das sich aus Bestellung und Lieferung ergibt und endet mit dem maximalen Aufbewahrungsenddatum von Bestellung und Lieferung. Und nun kommt die Faktura noch hinzu.

Abbildung 2.12 Verwendung, Karenzzeit, Sperrung und Löschung für Bestellung, Lieferung, Faktura und Geschäftspartnerstammsatz

Wieder hat sich das Ende des Verwendungszwecks für den Geschäftspartnerstammsatz geändert. Es ergibt sich nun aus den Datümern aller drei Geschäftsvorfälle (Bestellung, Lieferung, Faktura). Die Aufbewahrungsfrist des Geschäftspartnerstammsatzes richtet sich ebenfalls nach dem maximalen Enddatum aller drei Aufbewahrungsfristen von Bestellung, Lieferung und Faktura.

3 Karenzzeiten im Detail

3.1 Übersicht über Karenzzeiten

Die bisherige Betrachtung der Karenzzeit ist leider nicht ausreichend differenziert. Denn neben der bisher betrachteten Ermittlung des Endes des Verwendungszwecks kann auch bei der Archivierung eine Karenzzeit ins Spiel kommen. Insgesamt sprechen wir von folgenden Karenzzeiten:

• Karenzzeit bei der Ermittlung des Endes des Verwendungszwecks (K₁)


• Karenzzeit bei der Archivierung von Belegen (K₂)
  
  
  
  • Anwendungsspezifische Karenzzeit bei der Archivierung (K_2.1)
  
  
  • ILM-basierte Karenzzeit bei der Archivierung (K_2.2)
  
  
  
  

In der nachfolgenden Tabelle ist für alle drei Karenzzeiten der Ort der Definition, Details zur Definition und das gängige Synonym angegeben.

Tabelle 3.6 Details zur Definition der Karenzzeiten sowie gängige Synonyme

Karenzzeit	Ort der Definition	Details zur Definition	Gängiges Synonym	Verwendung
K1	ILM	• Transaktion IRMPOL • Regelwerkkategorie Verweilfristen (RST) • Prüfgebiet (immer) BUPA_DP • Beliebiger Policyname • ILM Objekte für SAP Business Partner (CA_BUPA), Kunde (FI_ACCRECV), Lieferant (FI_ACCPAYB), Kontaktperson (FI_ACCKNVK)	Verweilfrist, engl. residence period	Verweilregeln in Prüfgebiet BUPA_DP: steuern die Karenzzeit beim EoP-check
K2.1	Customizingtabelle der Anwendung	• Via Customizingleitfaden oder SM30 • Anwendungsspezifische Tabelle	Residenzzeit, engl. residence period	steuern die Karenzzeit bei der Archivierung
K2.2	ILM	• Transaktion IRMPOL • Regelwerkkategorie Verweilfristen (RST) • Prüfgebiet (immer) ARCHIVING • Beliebiger Policyname • ILM Objekte für Bestellung (SD_VBAK), Lieferung (RV_LIKP), Faktura (SD_VBRK)	Verweilfrist, engl. residence period	Verweilregeln in anderen Prüfgebieten: steuern die Karenzzeit bei der Archivierung

Es ist direkt ersichtlich, dass ein häufiger Grund für Missverständnisse aber auch für allgemeine Verständnisprobleme die Verwendung des Begriffs ''Verweilfrist'' für alle drei Karenzzeiten ist. Dabei bewirken alle drei Karenzzeiten unterschiedliches und sollten individuell und unabhängig voneinander betrachtet werden. Zudem sollte im Allgemeinen entweder Karenzzeit K_2.1 oder K_2.2 aber nicht beide zugleich verwendet werden. Im Folgenden wird daher zunächst nur die auf ILM basierende Alternative K_2.2 betrachtet.

3.2 Abweichende Definition der Karenzzeiten K₁ und K_2.2

Technisch besteht kein Zwang alle drei Karenzzeiten nicht gleich zu setzen. Man könnte definieren, dass die Karenzzeit der Bestellung für die Berechnung des Endes des Verwendungszwecks des Geschäftspartnerstammsatzes (K₁) 1 Woche beträgt und gleichzeitig die Karenzzeit für die Archivierung von Bestellungen (K_2.2) 1,5 Wochen beträgt. Die zugehörige Abbildung gestaltet sich wie folgt:

Abbildung 3.13 Karenzzeit K₁ kleiner wie K_2.2

Problematisch an dieser Konfiguration ist das Vorhandensein des pink gefärbten Zeitraums. Innerhalb dieses Zeitraums gilt:

• Der Geschäftspartnerstammsatz ist gesperrt und kann (von normalen Benutzern) nicht mehr eingesehen werden und nicht mehr für neue Geschäftsvorfälle verwendet werden.


• Die Bestellung ist noch nicht gesperrt (noch nicht archiviert), da die Karenzzeit K_2.2 noch nicht abgelaufen ist. Karenzzeit K_2.2 wurde aus betriebswirtschaftlichen Gründen so definiert, um bspw. Rückläufer bei Bestellungen bearbeiten zu können, bevor die Bestellung nicht mehr zugreifbar bzw. änderbar ist.


• Eine Änderung der Bestellung (in jeglicher inhaltlicher Form) ist allerdings ausgeschlossen, da der zugehörige Geschäftspartnerstammsatz bereits gesperrt ist und das System Änderungen an Geschäftsvorfällen dieses (gesperrten) Kunden verhindert.


• Folglich ist diese Konfiguration nicht konsistent.


• Es lässt sich verallgemeinern, dass (im Allgemeinen) die Karenzzeit bei der Archivierung (K_2.2) nie größer wie die Karenzzeit bei der Ermittlung des Endes des Verwendungszwecks (K₁) sein sollte. Oder mathematisch ausgesprochen:

K_2.2 ≤ K₁

Nun betrachten wir den umgekehrten Fall. Es wird definiert, dass die Karenzzeit der Bestellung für die Berechnung des Endes des Verwendungszwecks des Geschäftspartnerstammsatzes (K₁) 1,5 Wochen beträgt und gleichzeitig die Karenzzeit für die Archivierung von Bestellungen (K_2.2) nur 1 Woche beträgt. Die zugehörige Abbildung gestaltet sich wie folgt:

Abbildung 3.14 Karenzzeit K₁ größer wie K_2.2

Problematisch an dieser Konfiguration ist ebenfalls das Vorhandensein des pink gefärbten Zeitraums. Innerhalb dieses Zeitraums gilt:

• Der Geschäftspartnerstammsatz ist wie gewohnt verwendbar.


• Die Bestellung ist bereits gesperrt (archiviert), da die Karenzzeit K_2.2 bereits abgelaufen ist.


• Eine Änderung der Bestellung (in jeglicher inhaltlicher Form) ist ausgeschlossen, da sie bereits archiviert ist.


• Betrieblich gibt es daher keinen Grund den Geschäftspartnerstammsatz nicht zu sperren. Alle Geschäftsvorfälle (hier nur die Bestellung) sind bereits (inkl. Karenzzeit) abgeschlossen. Bei einem Blick ins System würde man lediglich den Geschäftspartnerstammsatz aber gar keine Geschäftsvorfälle für diesen mehr vorfinden. Das Ende des Verwendungszwecks tritt zu spät ein.


• Folglich ist diese Konfiguration nicht konsistent.


• Es lässt sich verallgemeinern, dass (im Allgemeinen) K_2.2 nie kleiner wie K₁ sein sollte.


• Zusätzlich zum oben betrachteten Fall ergibt sich daraus, dass K₁ und K_2.2 (im Allgemeinen) stets gleich sein sollten.

K_2.2 ≥ K₁

K_2.2 = K₁

Die schematische Darstellung für K₁ = K_2.2 ist wie folgt:

Abbildung 3.15 Karenzzeiten K₁ und K_2.2 gleich

3.3 Anwendungsspezifische Karenzzeit bei der Archivierung - K_2.1

SD Kundenauftrag

Bisher wurde Karenzzeit K_2.1 nicht in die Betrachtung aufgenommen. Der Grund dafür liegt in der Eigenschaft dieser Karenzzeit. Per Definition ist sie anwendungsspezifisch und wird (potentiell) uneinheitlich interpretiert. Nehmen wir als Beispiele den SD Verkaufsauftrag und den CRM Kundenauftrag. Die zugehörigen Archivierungsprozesse kennen (bereits seit Jahrzehnten) die Karenzzeit K_2.1. Allerdings unterscheiden sich beide Archivierungsprozesse bei der technischen Prüfung zur Archivierbarkeit.

Für den SD Kundenauftrag werden technische und betriebliche Prüfungen sowie die Prüfung auf den Ablauf der Karenzzeit K_2.1 innerhalb eines Prozessschritts (Gemeint ist hier das sog. Archivierungsschreibprogramm) durchgeführt. Dieser Prozessschritt prüft außerdem (sofern definiert) die Karenzzeit K_2.2. Bei erfolgreicher Prüfung wird sofort archiviert.

Abbildung 3.16 Karenzzeiten K_2.1 und K_2.2 beim SD Kundenauftrag

Folgende mögliche Konstellationen ergeben sich:

• K_2.1 = K_2.2
  Kein abweichendes Verhalten im Vergleich zu K₁=K_2.2 (siehe Kapitel 2.1).


• K_2.1 < K_2.2
  Da sowohl K_2.1 als auch K_2.2 berücksichtigt werden, ist lediglich K_2.2 maßgeblich. Ergo ergibt sich kein abweichendes Verhalten zu K₁ = K_2.2.


• K_2.1 > K_2.2
  Da sowohl K_2.1 als auch K_2.2 berücksichtigt werden, ist lediglich K_2.1 maßgeblich.

Nach Betrachtung aller Konstellationen lässt sich zusammenfassen, dass im Falle des SD Kundenauftrags entweder K_2.1 oder K_2.2 aber nicht beide Karenzzeiten gleichzeitig verwendet werden sollten. Sie haben zudem den gleichen Effekt und sind daher equivalent.

CRM Verkaufsauftrag

Bei der Archivierung von CRM-Geschäftsprozessen gibt es verschiedene Möglichkeiten. Bei Alternative A werden beim CRM Verkaufsauftrag technische und betriebliche Prüfungen sowie die Prüfung auf den Ablauf der Karenzzeit K_2.1 ebenfalls innerhalb eines Prozessschritts durchgeführt. Dieser ist jedoch vorgelagert (Gemeint ist hier das sog. Archivierungsvorlaufprogramm). Die erfolgreiche Prüfung führt zu einer Statusänderung am Verkaufsauftrag (archivierbar (siehe Transaktion BS23 und Status I1100)). Der Geschäftsvorfall wird allerdings nicht automatisch archiviert. Vielmehr ist ein weiterer Prozesschritt notwendig, der die Archivierung abschließt. Dieser zweite Prozessschritt prüft Karenzzeit K_2.2.

Abbildung 3.17 Karenzzeiten K_2.1 und K_2.2 beim CRM Verkaufsauftrag

Im Unterschied zum SD Kundenauftrag sind die Karenzzeiten K_2.1 und K_2.2 nicht equivalent, sondern unterschiedlich und kumulativ. Hinzu kommt, dass der CRM Verkaufsauftrag während Karenzzeit K_2.1 nicht mehr änderbar ist und K_2.1 mindestens einen Tag betragen muss (kann nicht Null sein). Der SD Kundenauftrag hingegen ist bis zum Beginn seiner Aufbewahrungsfrist änderbar. Daraus folgt, dass sich Karenzzeiten K_2.1 und K_2.2 im Falle vieler CRM-Geschäftsprozesse gegenseitig ausschließen (Gemeint sind hier One-Order-basierte Geschäftsprozesse. Nicht One-Order-basierte Geschäftsprozesse folgen mithin anderen Regeln bei der Archivierung.). Aus betrieblicher Sicht bedienen beide die gleichen Anforderungen. Daher könnte man folgern, K_2.1 und K_2.2 gleichlang zu definieren. Durch ihre technische Umsetzung und der daraus resultierenden Abfolge beider Karenzzeiten nacheinander sollte, falls möglich, auf die Karenzzeit K_2.1 verzichtet werden (K_2.1 = 1 Tag).

Alternative B umgeht die anwendungsspezifische Karenzzeit K_2.1 vollständig. Dazu wird ein anderer, alternativer Prozessschritt verwendet, der anstatt des Status archivierbar den Status Archivierung direktes Löschen (siehe Transaktion BS23 und Status I1108) setzt.

Folgende Konstellationen sind möglich:

• K_2.1 = K_2.2
  Das Ende des Geschäftsvorfalls für den Verkaufauftrag ist bereits eingetroffen (entspricht auch dem Vorhandensein von Status I1005 Erledigt am Geschäftsvorfall). Die Aufbewahrungsfrist des Verkaufsauftrags hat noch nicht begonnen, da K_2.1 noch nicht verstrichen ist. Somit ergeben sich die in Kapitel 2.1 beschriebenen problematischen Aspekte.


• K_2.1 < K_2.2
  Diese Konstellation wird weiter unterschieden in:


• K_2.1 = 1 Tag
  Mit dieser Konfiguration sind sowohl Alternative A als auch B adäquat eingestellt. Kein abweichendes Verhalten im Vergleich zu K₁=K_2.2 (siehe Kapitel 2.1) mit Ausnahme des einen Tages.


• K_2.1 > 1 Tag
  Für Alternative B ist kein abweichendes Verhalten im Vergleich zu K₁=K_2.2 (siehe Kapitel 2.1) gegeben. Im Gegensatz dazu ergeben sich für Alternative A die in Kapitel 2.1 beschriebenen problematischen Aspekte.


• K_2.1 > K_2.2
  Es ergeben sich die in Kapitel 2.1 beschriebenen problematischen Aspekte.

3.4 Rechnungslegungsvorschriften für Unternehmen

Neben den logischen Implikationen für Karenzzeiten, die in den vorangegangenen Kapiteln erläutert wurden, gibt es rechtliche Rahmenbedingungen für Karenzzeiten. Je nach relevantem Rechtsraum sind für Unternehmen ein oder mehrere Rechnungslegungsvorschriften zu beachten. So könnten beispielweise die IFRS sowie die Vorschriften des HGB für ein Unternehmen maßgeblich sein. In einem solchen Fall wäre es nicht unwahrscheinlich, dass die Karenzzeiten K₁ und K_2.2 vier Jahre betragen. Eine Karenzzeit von dieser Länge ist in der Regel deutlich länger, wie der Zeitraum der aktiven Verwendung eines Geschäftsvorfalls. Dennoch gelten auch bei solch langen Karenzzeiten die logischen Implikationen der vorangegangenen Kapitel.