Die Alternative zum SAP-Standard
Gastbeitrag von Renato Herrmann (email: Renato.Herrmann@gisa.de), Bereichsleiter Informationssysteme und Leiter Competence Center GDPdU bei der GISA GmbH ( http://www.gisa.de ) Obwohl die GDPdU bereits seit 01.01.2002 rechtskräftig ist und die digitale Betriebsprüfung von der Finanzverwaltung schon praktiziert wird, wissen viele Unternehmen nicht was genau zu tun ist und wie sie sich vorbereiten können.
Auch viele SAP Anwender sind noch verunsichert. In den letzten Wochen trugen die Diskussionen um die DART- GDPdU- Konformität immer wieder zu einer verstärkten Verunsicherung vieler SAP R/3 - Anwender. Das hat dazu geführt, das einige Unternehmen ihre Aktivitäten wieder eingestellt oder erst gar nicht begonnen haben. Ein erstes klärendes Gespräch mit Vertretern des BMF, des BfF, der Länderfinanzverwaltung, der SAP AG und Mitgliedern der DSAG fand am 08.12.2003 statt. Anlass dieser von der DSAG-Arbeitsgruppe GDPdU initiierten Veranstaltung war die Klärung bestehender Kritikpunkte und Missverständnisse. Ein Kritikpunkt der Finanzverwaltung war, dass bei Betriebsprüfung einige Unternehmen die DSAG- Vorschläge als umfassend und abschließend dargestellt haben. Das wurde vermutlich von diesen Unternehmen offensichtlich falsch verstanden oder bewusst so ausgelegt. Die DSAG (Deutsche SAP Anwendergruppe e.V.) bemüht sich bereits seit 2001 in speziellen Arbeitskreisen und in enger Zusammenarbeit mit SAP um eine gesetzeskonforme Umsetzung der GDPdU-Anforderungen. Ziel dieser Arbeitsgruppe ist es, nach amerikanischen Muster, den deutschen SAP-Nutzern eine vordefinierte Auswahl der im DART -Extrakt enthaltenen Daten (Datenkatalog) zur Verfügung zu stellen, um sie in der Verpflichtung „steuerrelevante Daten“ von den Anderen abzugrenzen und zu unterstützen. Obwohl einige DSAG Mitglieder diese Vorschläge gerne als rechtverbindlich ansehen möchten, handelt es sich hierbei lediglich um eine Startbasis. Jedes steuerpflichtige Unternehmen ist nach eigenem Ermessen dazu verpflichtet, den Datenumfang und das Berechtigungskonzept auf die individuelle Unternehmenssituation anzupassen. In der aktuellen jetzt verfügbaren Version DART 2.2 wurden auch wieder neue Extraktionsmöglichkeiten wie z.B. Reisekostenabrechnungen, Anwendungsdaten aus CFM/Treasury und offene Posten mit eingebaut. In der Zukunft wird dieser Datenumfang aber noch erweitert werden müssen. Hierbei ist auch für die Unternehmen besonders zu berücksichtigen, dass kundenspezifische Tabellen in diesen Datenumfang noch mit eingebunden werden müssen. Die Finanzverwaltung machte auch deutlich, das DART und das Berechtigungskonzept den Anforderungen des Datenzugriffes nur genügt, wenn auch bei späteren Außenprüfungen (also auch kumulativ) alle steuerlich relevanten Daten mit den dazugehörigen Strukturinformationen maschinell auswertbar zur Verfügung gestellt werden können. Um z.B. die Stammdatenänderungen nachvollziehen zu können, sollte der DART- Extraktionslauf möglichst zeitnah durchgeführt werden (empfohlen sind alle 4 Wochen). Das hat zur Folge, dass weitere Daten parallel zum Produktivsystem erstellt und vorgehalten werden müssen. Besonders dieser Sachverhalt stößt bei vielen SAP- Anwendern auf Unverständnis. Obwohl es heute bereits kostengünstige Alternativ- Lösungsmöglichkeiten gibt, hat sich der Arbeitskreis GDPdU des DSAG zum Ziel gesetzt, die GDPdU-Anforderungen mit SAP- Standard- on Bord-Mitteln umzusetzen.
Die Anforderungen der Kunden waren klar: die Umsetzung der GDPdU darf nichts kosten!
Als zertifiziertes SAP Customer Competence Center und SAP Hosting Partner standen auch wir vor der Frage, wie die Anforderungen der GDPdU für die Kunden von GISA umgesetzt werden können. Ziel war es Anfangs, die Anforderungen aus den GDPdU im SAP Umfeld mit den Standard-on Bord-Mitteln umzusetzen. Es wurde schnell deutlich, das kein Unternehmen gerne Geld in die Hand nimmt, um gesetzliche Anforderungen umzusetzen. Aus diesem Grunde wird bei der Umsetzung klar der Fokus auf Kostenoptimierung, Mehrwerte und Optimierung der Geschäftsprozesse gelegt. Erste interne Untersuchungen ergaben auch sehr schnell, dass ein Vorhalten von Daten über einen Zeitraum von 10 Jahren in einem Produktivsystem weder technisch noch wirtschaftlich realistisch wäre. Dazu kommen noch die Kosten für die Erzeugung, Aufbewahrung und Verwaltung von Datenextrakten.
Das Problem 10 Jahre online vorzuhalten!
Moderne Datenverarbeitungssysteme schaffen die technischen Möglichkeiten, in ihren Datenbanksystemen Daten im Umfang mehrerer Terabyte vorzuhalten. Bei stark steigenden Datenvolumina ist im Betrieb eines solchen Systems mit proportional steigendem Aufwand und entsprechenden Kosten zu rechnen. Dies betrifft nicht nur Anschaffung und Vorhalten benötigter Massenspeicher, sondern auch die Administration des laufenden Betriebs. Neben dem Produktionssystem müssen auch Spiegelungen und Kopien in Entwicklungs-, QA- und Testsysteme berücksichtigt werden. Die Anforderungen an Antwortzeiten und Zeitbedarf der Datensicherung bzw. eines Desaster Recoveries setzen dabei einem Datenbankwachstum Grenzen. Dies gilt auch für die Anforderungen zum Zeitbedarf der Durchführung von Releasewechseln (z.B. auf SAP R/3 Enterprise).
Um das kontinuierliche Wachstum und die Gesamtgröße der Datenbank und somit auch die Kosten, im Griff zu behalten, ist ein rechtzeitig initiiertes und umfassend angelegtes Datenarchivierungskonzept für die vorhandenen Anwendungsdaten erforderlich. Hierbei müssen auch besonders die Anforderungen der GDPdU Berücksichtigung finden. Diese fordern eine zehnjährige Vorhaltung steuerrelevanter Daten für eine Online-Auswertbarkeit bzw. die Möglichkeit zur Erstellung von Datenextrakten.
Datenarchivierung im SAP Standard
Im SAP R/3 System ist ein umfangreiches Werkzeug zur Archivierung von Anwendungsdaten enthalten, das Archive Development Kit (ADK). Mittels ADK-basierten Programmen können Daten zu abgeschlossenen Geschäftsvorfällen, die nur noch zu Auskunfts- oder Auswertungszwecken benötigt werden, aus der Datenbank entfernt werden. Diese Daten werden komprimiert und unveränderbar als Archivdateien im Dateisystem des Servers bzw. direkt in einem mittels ArchiveLink angebundenen Ablagesystem gespeichert. Struktur und Inhalt der so generierten Archivdateien gewährleisten, dass diese über Releasegrenzen hinweg gelesen und mit diesem System ausgewertet werden können. Ein Rückladen dieser Archivdateien ist jedoch nicht möglich. Als Folge einer durchgeführten Archivierung stehen dem Anwender die aus der Datenbank entfernten Daten meist auch nur eingeschränkt über seine gewohnten Transaktionen zur Anzeige und Auswertung zur Verfügung.
Datenzugriff auf Archivdateien mit SAP Standardmitteln
Um auch im Fall von Massendaten einen praxisnahen Archivzugriff zu erlangen, ist die Erzeugung spezieller Indexinformationen, die einen direkten Zugriff auf die archivierten Daten ermöglichen, notwendig. Zur Erstellung dieser Indizes könnte das SAP Archivinformationssystem (SAP AS) verwendet werden. Es handelt sich um ein generisches Werkzeug, auf dessen Basis Anwendungsprogramme und der Document Relationship Browser (DRB) über die erzeugten Indizes auf archivierte Daten zugreifen können. Damit können die Archivdaten prinzipiell direkt angezeigt oder ausgewertet werden. Interne Untersuchungen ergaben jedoch sehr schnell, dass die Umsetzung mit erheblichen Projektierungskosten verbunden wäre.
Innerhalb von SAP R/3 Enterprise wurde die Funktionalität zur Verwaltung und Anzeige von Archivdaten zum Teil erweitert. Für die wesentlichen SAP Module können archivierte Anwendungsdaten in einigen Anwendungstransaktionen weitgehend analog zu den Datenbankdaten mit Original-Anzeigetransaktionen angezeigt werden. Bei der Anzeige von Archivdaten bestehen aber zum Teil Funktionseinschränkungen, die z.B. die Anzeige von Langtexten und die direkte Verzweigung in verknüpfte Belege anderer Anwendungsmodule für die angezeigten Daten nicht gestatten. Auch werden nicht alle zu einer Anwendung gehörenden Transaktionen für den Zugriff auf archivierte Daten angeboten.
Zur Anzeige von verknüpften Belegen und zur Verzweigung in Belegketten kann der Document Relationship Browser (DRB) verwendet werden. Dieser ermöglicht, im Belegfluss der Anwendungsdaten zu navigieren und bezieht sowohl Archivdaten als auch Daten der Datenbank in die Recherche mit ein. Die Anzeige archivierter Daten kann aber von der originalen Belegflussanzeige der Datenbankdaten abweichen und im Funktionsumfang eingeschränkt sein. Derzeit haben nur wenige unserer Mandanten bereits auf Enterprise migriert. Eine Kosten/Nutzen Analyse und der noch eingeschränkte Funktionsumfang lies uns weiter nach Alternativen Ausschau halten.
Eine Alternative: Archivdatenzugriff mit PBS archive add ons
Hierbei stießen wir Anfang 2003 auf die PBS archive add ons für SAP. Mit dieser Lösung wird das Anzeigen und Auswerten von Archivdaten über erweiterte SAP-Standardtransaktionen und -Auswertungen zusätzlich zu den Datenbankzugriffen ermöglicht. Die Archivdaten können insbesondere in Listanzeigen gemeinsam mit Anwendungsdaten, die aus der Datenbank gelesen wurden, angezeigt werden. Die archive add ons sind als Standardlösungen modulweise passend zu den wichtigsten SAP-Komponenten verfügbar (FI, CO, MM, SD, PP, PS, HR, ....). Wichtig für uns war, dass diese komplett mit Standardwerkzeugen der SAP Entwicklungsumgebung (ABAP) realisiert werden.
Die Darstellung und die Handhabung dieser Transaktionen erfolgt analog zu entsprechenden SAP-Transaktionen, wodurch eine hohe Akzeptanz bei unseren Kunden erreicht wurde und nahezu kein Schulungsaufwand notwendig war.
Technische Realisierung des Archivzugriffs
Zur Realisierung eines solchen direkten Archivzugriffs sind zunächst passende Indexinformationen aufzubauen. Die hierzu verwendeten Indexgenerierungsprogramme lesen die zugehörigen Archivdaten (ADK) sequentiell ein und erzeugen die benötigen Indizes. Die Indexdaten für den Archivzugriff werden – anders als bei SAP AS – komprimiert in sequentiellen Dateien (flat files) im Dateisystem des SAP-Servers und somit außerhalb der Datenbank gespeichert. Hierdurch wird einerseits der schnelle Direktzugriff auf die Archivdaten gewährleistet ohne die Datenbank, deren Datenvolumen durch den Archivierungsprozess ja reduziert werden soll, zu belasten. Lediglich einige Zugriffsinformationen, analog zum Inhaltsverzeichnis eines Buches, müssen bei der Aktivierung der Indizes in der Datenbank abgelegt werden.
Die Archivdaten stehen nun für den direkten Zugriff über spezielle Anzeigetransaktionen zur Verfügung. Mit einem Auswahlparameter kann der Anwender jeweils entscheiden, ob er auf Datenbank und Archiv simultan, nur auf die Datenbank oder nur auf das Archiv zugreift.
Dieser zusätzliche Parameter ist übrigens der einzige Unterschied, den ein Anwender am Selektionsbild einer Anzeigetransaktion im Vergleich zu dem entsprechenden SAP-Original bemerken kann. Bei den Ergebnisanzeigen werden die gelesenen Archivdaten durch einen Asterisk gekennzeichnet, um dem Anwender die Herkunft der selektierten Daten (DB oder Archiv) zu kennzeichnen. Durch die Analogie dieser Anzeigetransaktionen zu den entsprechenden SAP-Pendants stehen dem Anwender alle für die Datenbankdaten vorhandenen Optionen, Menüs und Verzweigungsmöglichkeiten (Drill-down, Belegfluss) analog für die Verarbeitung der Archivdaten zur Verfügung.
So kann per Mausklick innerhalb von Belegketten zu Vorgänger- und Nachfolgebelegen navigiert werden. Dabei ist es unerheblich, ob der Beleg noch in der Datenbank vorliegt oder bereits archiviert wurde. Über die SAP ArchiveLink Schnittstelle werden auch eventuell vorhandene Originaldokumente (z.B. eingescannte Eingangsrechnungen) angezeigt. Durch diesen Komfort ist eine komplette Verfügbarkeit der Archivdaten für Anzeige und Auswertung gewährleistet. Der Prüfer bzw. die jeweiligen Fachabteilungen können die archivierten Belege mit diesen Transaktionen jederzeit zur Anzeige bringen. Die jeweiligen add ons decken auch die standardmäßig für Datenbankdaten vorhandenen Reporting-Funktionalitäten für die Archivdaten ab. Analog zu den Anzeigetransaktionen werden die jeweiligen Reports um den notwendigen effektiven Archivzugriff über die erzeugten Indizes erweitert und liefert diese in den jeweiligen Modulen aus. Für unsere Kunden ist ferner die Option wichtig, kundenspezifische Programme oder Reports an den Archivzugriff mit anzupassen.
Durch diese Vorgehensweise ist ein effektiver Archivdatenzugriff auf archivierte Daten ohne jeglichen Informationsverlust für den Anwender innerhalb seiner gewohnten Arbeitsweise möglich. Ein Vorhalten der archivierten Anwendungsdaten für Online-Zugriffe auch für lange Zeiträume (Z1+Z2) und eine zeitnahe Archivierung abgeschlossener Geschäftsvorgänge ist mit dieser Lösung problemlos möglich.
Die Datenextraktion
Wie im oberen Abschnitt beschrieben, werden durch die Datenextraktion mittels DART im Snapshot –Verfahren Daten des Produktivsystems kopiert. Dieser DART-Lauf sollte möglichst alle 4 Wochen erzeugt werden. Das hätte zur Folge, für alle SAP- Systeme unseres RZ zusätzliche Ressourcen und Kosten für die Erzeugung, Verwaltung und Ablage dieser Extrakte zu produzieren. Da DART auch derzeit nicht sämtliche steuerlich relevanten Daten eines SAP-Systems extrahieren kann, kämen noch weitere Daten z.B. aus den Modulen HR (Toolbox) oder IS-U (Abrechnungssystem für Energieversorger) hinzu. Für das IS-U wurden in Zusammenarbeit mit der DSAG AK GDPdU/IS-U (in dem auch der Autor mitwirkt) und SAP bereits spezielle Extraktoren entwickelt. Diese sollen nach Auffassung der SAP in einem zusätzlichem R/3 Enterprise 4.71 Auswerte-System mit den DART- Extraktoren ausgewertet werden. Hier gibt es jedoch generell einige Schönheitsfehler:
| | | |
| | · | Daten, die bei der Festlegung des Extraktumfanges nicht berücksichtigt wurden, können auch nicht ausgewertet werden. Hier ergibt sich auch ein Risiko für kommende Prüfungen |
| | · | Ein separates Auswertesystem 4.71 nur für die Auswertung der Extraktoren ist weder wirtschaftlich, noch durchsetzbar (entspricht auch nicht Z1) |
| | · | Neben dem Produktivsystem muss ein paralleler Datenbestand aufgebaut werden (Es entstehen hohe zusätzliche Kosten) |
Interne Versuche ergaben, das bei einer ca.580 GB großen Datenbank eine DART-Laufzeit für einen Mandanten, pro Monat (AM, FI, CO) von ca. 20 Stunden benötigt werden. Hierbei wurden noch nicht die Aufwände für die notwendige DART-View-Erstellung und weiterer Extraktionsläufe aus IS-U und HR berücksichtig. Die erzeugten DART Extrakte hatten eine Dateigröße von ca. 4-5 GB.
Diese Kosten sind nicht akzeptabel, sodass wir auch für die Datenträgerüberlassung (Z3) eine Alternativlösung benötigten.
Die DART-Alternative
Ein wesentlicher Vorteil dieser Lösung ist, das die Daten erst extrahiert werden, wenn Sie benötigt werden. Das Anhäufen von parallelen Datenbeständen neben dem Produktivsystem entfällt. Die Kosten- und Ressourcenersparnis ist somit erheblich. Die Datenextrakte berücksichtigen sowohl die Daten der produktiven Datenbank wie auch die Archivdaten. Über die Standard-SAP-ALV-Technik, wird der Anwender in die Lage versetzt, beliebige Felder hinzuzufügen oder herauszunehmen. Es ist somit möglich „on demand“ bestimmte Daten für den Prüfer zu selektieren. Fehlt ein Feld, kann es jederzeit in den Extraktionslauf einbezogen werden. Selbstverständlich können somit auch beliebige Datenbanktabellen und Views (auch Kundeneigene) berücksichtigt werden. Vordefinierte Extrakte von Stamm-, Beleg- und Customizing-Tabellen, der eingearbeitete DSAG Feldkatalog, die Stichtags- oder zeitraumbezogene Variante und Extrakte für offene Posten machen diese Lösung sehr komfortabel. Die Ausgabe der Extrakte erfolgt im SAP-AIS Format. Zusätzlich erzeugt ein XML-Generator die XML-Index Datei, nach dem von Audicon und dem BMF festgelegten Beschreibungsstandard. Als Partner beider Tools konnten wir nun gemeinsam mit den Herstellern diese Lösung vorantreiben. Es ist somit möglich, individuelle SAP-Datenextrakte festzulegen und komfortabel „on demand“ zu erzeugen. Hierbei lassen sich auch leicht Extraktionsvarianten z.B. für die interne Revision oder das Controlling hinterlegen. Diese Daten können dann in einem Auswertungsprogramm wie Idea ausgewertet werden. Es ist somit auch möglich, SAP-Daten, die entweder aus Non-SAP- Systemen stammen oder Tabellen, die in einem SAP-System nicht ohne weiteres verknüpft werden können, auszuwerten. Als neuestes Highlight unterstützt diese Lösung auch bereits per Knopfdruck einige der in AISTaxAudit* hinterlegten Prüfungsmakros der Finanzverwaltung.
Summa-Summarum stellen die Funktionalitäten dieser GISA- GDPdU- Lösungen für unsere Kunden nicht nur einen besonderen Mehrwert dar, sondern auch eine hohe Kostenersparnis gegenüber den Standard-Lösungen. Die notwendigen Investitionen für die Zusatzsoftware stehen in keinem Verhältnis zu den Kosten, die entstehen würden, wenn die Datenextrakte permanent erzeugt, verwaltet und abgelegt werden müssten. Auch die Anforderung die Daten 10 Jahre im Zugriff zu haben, ohne die Hardware ständig aufrüsten zu müssen ist hiermit erfüllt. Selbstverständlich muss jedes Unternehmen für sich entscheiden, mit welchen Mitteln sie die GDPdU-Anforderungen umsetzen. Wer sich 2001/2002 z.B. auf DART festgelegt hat, hat zum damaligen Zeitpunkt richtig gehandelt. Zwischen-zeitlich hat sich aber einiges getan, sodass es sich auch lohnt über Alternativen nachzudenken.
Eins steht jedoch fest, die GDPdU ist Realität und wird auch praktiziert, wer jetzt nicht handelt und seine IT-Landschaft auf diese Anforderungen anpasst, erhöht sein steuerliches Risiko, denn die nächste Betriebsprüfung ist digital.
Hinweis der Red.: Gastbeiträge stellen die Meinung des jeweiligen Autors dar.
Metadata