Gastbeitrag von Siegfried Mack (smack2000@t-online.de). Herr Mack ist Entwickler des Tools GoBScape. PROJECT CONSULT und Siegfried Mack arbeiten in Kundenprojekten bei der Erstellung von Verfahrensdokumentationen zusammen. Seit 1995 gelten die GoBS, die Grundsätze ordnungsmäßiger dv-gestützter Buchführungssysteme; sie schreiben dem Buchführungspflichtigen eine umfassende Dokumentation des DV-Systemeinsatzes vor. Seit dem 1. Januar 2002 sind die GDPdU (GDPdU, Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Daten, BMF-Schreiben vom 16.07.2001.) in Kraft und verlangen die Aufbewahrung originär digitaler Daten in maschinell auswertbarer Form. Die mit den GoBS vorgeschriebene Dokumentation, bestimmt zur Orientierung der Prüfer, umfasst auch die GDPdU-relevanten Daten und bekommt dadurch neues Gewicht. GoBScape bildet die GoBS in eine Intranet-Anwendung ab und zerlegt die Verfahrensdokumentation in eine Hierarchie von Dokumentationsobjekten, die fachspezifisch arbeitsteilig bearbeitet werden können.
Überblick
Die GoBS schreiben bei elektronischer Buchführung die Dokumentation des „Verfahrens“ vor: System, Organisation, Geschäftsvorfälle, Daten, Systemereignisse etc. Diese Dokumentation soll dem Außenprüfer ein schnell fassbares Bild der DV-Buchführung des Unternehmens verschaffen und den Geschäftsvorfall nachvollziehbar machen.
Die GDPdU verlangen, alle steuerrelevanten originär-digitalen Daten aus Anlagen-, Lohn- und Finanzbuchhaltung in maschinell auswertbarer Form vorzuhalten. Die Prüfbarkeit im Sinne der GDPdU kann aber nur gewährleistet werden, wenn die Bedeutung jeder Tabelle und jeden Feldes und die Beziehungen zwischen diesen klar doku-mentiert sind wie von den GoBS verlangt.
Für die Unternehmen ergibt sich eine ungewohnte Situation. Die Buchhaltung muss sich plötzlich mit Technologie, die IT-Mannschaft mit Gesetzestexten, das Controlling mit bestehenden oder neuen, durch die GoBS/GDPdU induzierten Geschäftsvorfällen befassen und ERP-, Archivierungs- und Dokumentenmanage-mentsysteme müssen auf GDPdU-„Konformität“ abgeklopft werden. Die Schwierigkeit der interdisziplinären Kooperation zwischen den Abteilungen und der schwer verdauliche Text der GoBS führen dazu, dass die Umsetzung von GoBS und GDPdU mit deutlichen Unsicherheiten behaftet ist.
Der Kern des Ansatzes besteht darin, die GoBS in eine Hierarchie von verknüpften Dokumentationsobjekten zu zerlegen und hierbei ein „dokumentationsfreundliches“ Modell des Geschäftsvorfalls – dem Kernthema der GoBS – zu nutzen. Damit wird das Problem der interdisziplinären Kommunikation durch die klare Zuständigkeit für die jeweiligen Beiträge zur Dokumentation gelöst. Die allgemein gefassten Anforderungen der GoBS werden durch generische Vereinbarungen auf die individuelle Situation projiziert. Die von einem Mitarbeiter erzeugten Dokumentationsobjekte stehen den anderen – unter Vermeidung überflüssiger Schreibarbeit – als referenzierbare Elemente in dynamisch versorgten Auswahllisten zur Verfügung. Die Dokumentation schließt die GDPdU-relevanten Daten ein und wird damit zu einem effizienten Instrument für die GDPdU-Datenerhebung.
GoBS und Geschäftsvorfall
Das Objekt der GoBS sind die elektronisch geführten Handels- und Geschäftsbücher; eine Teilmenge davon bildet die DV-gestützte Buchhaltung mit Anlagen-, Lohn- und Finanzbuchhaltung – den Zielobjekten der GDPdU. Die GoBS verlangen zentral, den Geschäftsvorfall für einen Dritten nachvollziehbar zu machen und seine retrograde und progressive Prüfbar-keit zu gewährleisten. Um diese progressive und retrograde Prüfung zu erlauben, muss die Aufzeichnung der Geschäftsvorfälle lückenlos sein und eine eindeutige Beziehung zu den involvierten Geschäftsobjekten wie Stammdaten, Belegen, Dokumenten, Buchungssätzen, Journalen und Konten nachweisen.
Ausgehend vom Beleg, über den Buchungssatz, und das Konto bis zur Bilanz bzw. GuV muss der Weg der Beträge durch die Geschäftsvorfälle verfolgbar sein, bzw. bei der retrograden Prüfung von den Angaben in der Steuererklärung bis zum Einzelbeleg.
Das verdeutlicht den Zusammenhang zwischen der Aufzeichnung des Geschäftsvorfalls und seiner Nachvollziehbarkeit; dabei werden „sonstige“ für das Verständnis wichtige Dokumente mit eingeschlossen.
Nach den verschiedenen Verwendungen des Begriffs „Geschäftsvorfall“ in den GoBS gelangen wir durch eine Analyse des Textes der GoBS zu einem dokumentationsfähigen „Modell“ für den Geschäftsvorfall. Als häufigster Begriff tritt in den GoBS der „Geschäftsvorfall“ auf; er kommt 28 Mal vor – in unterschiedlichen Kontexten, aber ohne geschlossene Definition, ohne Modell. Im Kontext des Geschäftsvorfalles finden sich die Begriffe Unterlage, Dokument (geht es in den Handelsbüchern allgemein um Dokumente, sprechen wir in der Buchhaltung durchweg von speziellen Dokumenten, den Belegen), Beleg, Daten, Informationen, Aufzeichnung, Wiedergabe usw. Nachfolgend wird aus der Kombination der verscheiden Kontextaussagen ein allgemeines Modell (Metamodell) des Geschäftsvorfalls vorgestellt, das aus der Verwendung des Begriffs in den GoBS als bester Kompromiss abgeleitet wurde.
Modell Geschäftsvorfall
Zur Modellbildung des Geschäftsvorfalles werden also die verschieden Kontexte des Begriffs „Geschäftsvorfall“ überdeckt und die Grundforderung der GoBS einbezogen: Die „Aufzeichnung des Geschäftsvorfalls“ soll so erfolgen, dass dieser anhand der Daten und der Dokumentation „rekonstruiert“ werden kann.
Danach erscheint der Geschäftsvorfall als das kleinste abgeschlossene (atomare) Unternehmensereignis mit wahrnehmbarem und definiertem Ergebnis - im Gegensatz zum übergeordneten Geschäftsprozess: Akteure, d.h. Mitarbeiter oder Systeme, führen Aktionen nach den Regeln des Geschäftsvorfalles durch, interagieren hierbei mit Systemen und arbeiten mit Geschäftsobjekten wie Daten, Belegen, Dokumenten, Konten usw.
Dieses Meta-Modell erlaubt eine „lokale“ Betrachtung und eine stets übersichtliche Darstellung und einfache Konstruktion des Modells für einen spezifischen Geschäftsvorfall.
GoBScape
Aufbau: Zur Darstellung einer unternehmensspezifischen Verfahrensdokumentation werden folgende Ansätze verfolgt:
| | | |
| | · | Zerlegung der GoBS in Dokumentations-Objekte (Attribute und Parameter) |
| | · | Zusammensetzung von Komplex-Objekten aus einfachen Objekten über dynamisch versorgte Auswahllisten |
| | · | Schwache Datenbindung zwischen Objekten durch reine Textbezüge |
| | · | Funktionstrennung für IT, Buchhaltung, Organisation, Controlling etc. beim Dokumentieren |
| | · | Modellierung des Geschäftsvorfalls als Komplex-Objekt |
| | · | Orientierung an der TÜVit-Gliederung |
| | · | Unternehmensspezifische generische Definition von Methoden |
Geschäftsvorfall: Aus dem Meta-Modell des „allgemeinen“ Geschäftsvorfalls wird das Beschreibungsmodell für einen „speziellen“ Typ von Geschäftsvorfall nach klassischer Objekt-Attribut-Sicht konstruiert. Rund um den Geschäftsvorfall werden Regeln, Akteure, Aktion, Input-/Output-Daten bzw. Geschäftsobjekte angeordnet. Auf einen Blick sind hier die Akteure (Rollen oder Systeme), die gültigen Regeln und die Input-/Output-Daten fassbar. Ein Klick auf die Lupe des jeweiligen Tabelleneintrages gibt weitere Hinweise. Vorfälle mit mehreren beteiligten „Geschäftsobjekten“ wie z. B. beim Scannen, Indizes erzeugen gemäß Ablageplan, Ablage des digitalisierten Dokuments im System und/oder Archiv, DMS etc. lassen sich ohne weiteres darstellen.Die bereits erzeugten „einfachen“ Objekte wie Dokumente, Journale, Systeme etc. werden zur Erstellung des Modells eines Geschäftsvorfalls per Auswahlliste angeboten.
Generizität: Dieses Konzept der generischen Auswahllisten wird auch bei der Definition spezifischer Methoden wie Zugriff, Export, Ordnung, Ablage, Signatur usw. angewendet. Die Definition der Methoden ist im Sinne der Funktionstrennung nur den Fach- oder Systemadministratoren zugänglich.
Verfahrensdokumentation: Für die Erstellung der Verfahrensdokumentation wurde vom TÜVit Essen eine detaillierte Gliederung entwickelt. Die Vorteile dieser Gliederung bestehen in ihrem „Quasi-Standard-Charakter“ und der Vollständigkeit der Gliederungspunkte; die Nachteile sind darin zu sehen, dass hier unter teilweise abstrakten Stichpunkten, die als Attribute aufzufassen sind, typische Beschreibungen oder Listen anzuhängen sind. Die Orientierung in einer solchen sequentiellen Darstellung ist äußerst aufwändig und die Fortschreibung durchaus problematisch.
Jedes zu beschreibende System – Hardware, Software bzw. Host und Anwendungssoftware – wird als eigenes Objekt mit den spezifischen Stichpunkten nach der TÜVit-Gliederung als Attributen beschrieben. Mehrere Systeme lassen sich zu einem „virtuellen System“ zusammenfassen, um insbesondere bei System-Aufgaben zu kompakten und zeitsparenden Darstellungen zu kommen.
Diese Dokumentations-Objekt-Hierarchie weicht von der Hierarchie der Gliederung „Verfahrensstruktur nach TÜVit“ in der Objektsicht ab, wird aber durch GoBScape mit den Stichpunkten dieser Gliederung durch die Dokumentationsobjekte „verheiratet“ bzw. verflochten. Mit dem Dokumentieren der Objekte in der Pyramide von unten nach oben entstehen Sammlungen, die in der Ebene darüber automatisch als Auswahllisten auftreten. Das z.B. unter „Systeme“ elementar dokumentierte Gerät erscheint mit allen Attributen bzw. Stichpunkten der „Verfahrensdokumentation nach TÜVit“. Die Struktur des Standards bleibt erhalten und gleichzeitig wird die Dokumentation um die fehlenden Elemente und chronologische Einträge erweitert.
Beim Erstellen der Dokumentation werden das Hauptmenü von links nach rechts und die einzelnen Untermenüpunkte von oben nach unten durchlaufen - vom Einfachen zum Komplexen. Die Folge der Schritte ergibt sich aus der Hierarchie der Do-kumentationsobjekte und geht auf-bauend von unten nach oben. Objekte werden bereits durch den Namen definiert und Attribute können jederzeit ergänzt werden.
Intranet: Alle Objekte und Strukturen werden in eine Intranet-Anwendung eingebettet. Das erlaubt ein ko-operatives Arbeiten im Mehrbenutzermodus. Dem Betriebsprüfer wird die gesamte Dokumentation unter einer vertrauten Browser-Oberfläche angeboten - – mit intuitiver Navigation, umfangreichen Suchfunktionen und schnellem Zugriff auf die gewünschte Do-kumentation. Der Gesamtinhalt der Intranet-Anwendung kann gedruckt werden.
Archivierung (nach Abrechnungsperioden): Die Sicherung erfolgt als Export in XML. Alle Daten, Datenbeziehungen und funktionalen Elemente (Combo-Boxen, Eingabefelder, Links etc.) werden komplett in XML exportiert. Damit wird das Dokumentationsabbild zum Ende einer Abrechnungsperiode in höchstem Maße programmunabhängig gesichert und archiviert.
Versionierung und Historisierung: Je nach Typ sind Dokumentations-Objekte chronologisch (inline) fortschreibbar, versionierbar oder historisierbar. Die Historisierung schließt die automatische Versionierung ein. Die Historisierung wird für die Organisation, die Rollen und alle Dokumente genutzt. Die anderen Objekte sind per se chronologisch (z.B. Sytemjournal) oder werden wie z.B. Richtlinieren als aktuell oder obsolet gekennzeichnet, aber niemals innerhalb einer Abrechnungsperiode gelöscht.
Fazit
Die Nutzung der Internettechnologie zur Erstellung und Pflege der Dokumentation der IT-gestützten Buchführung hebt das Verfahren der Dokumentation auf ein neues Niveau und bringt eine enorme Kosten- und Zeitersparnis. Schon die Vorbereitung des Themas verschlingt normalerweise mehrere Arbeitstage der Be-teiligten oder einige Beratertage zu den üblichen Sätzen. Durch das kooperative Arbeiten in GoBScape kommt es zu einer quasi-auto-matischen Abstimmung der Beteiligten bei entsprechender Funktionstren-nung.
Im Vergleich zu Organisation von Word- oder HTML-Dokumenten in einem Explorer-Baum bringt GoBScape einen deutlichen Gewinn an Transparenz, Ordnung und Effizienz bei der Erstellung und Fortschreibung.
Die Arbeit der Prüfer wird schon im Vorfeld der Bereitstellung der Dokumentation wesentlich beschleunigt. Das Unternehmen profitiert durch die Nutzung von GoBScape als Wissenbasis bei der Orientierung neuer Mitarbeiter – ein nicht zu unterschätzender Mehrwert.
Metadata
