PROJECT CONSULT ECM DRT DMS KM ILM
Logo PROJECT CONSULT - Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH  
 Contentmanager - Magazin
 Tipps für die DMS-Einführung
 Bereits bei der Auswahl der Dokumenten M
 Contentmanager - Magazin
 Relevante AdWords-Anzeigen mit Platzhalt
 Mit Platzhaltern können Werbetreibende i
 XING - Information & Documen
 [DE] Jobangebot: IT-Spezialist / IT-Proj
 Sehr geehrte Damen und Herren, mein Name
 XING - Information & Documen
 [DE] Jobangebot: IT-Spezialist / IT-Proj
 Sehr geehrte Damen und Herren, mein Name
Home  Englisch  Newsletter  Intern Hilfe  Kontakt  Impressum  Rechtshinweis 
  Detailsuche
PROJECT CONSULT Dr. Ulrich Kampffmeyer
Unternehmen
  Vision
  Grundsätze
  Leistungen
  Methoden
  Qualität
  Mitgliedschaft
  Slide-Show
  Mitarbeiter
  Auszeichnungen
  Unternehmensinfo
  Adresse
  AGB
Beratungsangebot
  Fachberatung
  Coaching
  Projekt-Management
  Workshops
  Anfrage
Seminarangebot
  Seminare
  Vorträge
  Seminartermine
  Handouts
  Anmeldung
Projekte
  Branchen
  Lösungen
Karriere
  Perspektive
  Stellenangebot
  Stellenmarkt
  Markt-Regeln
Presse
  Pressemitteilung
  Interview
  Artikelangebot
  Autorenrechte
  Akkreditierung
Website
  Sitemap
  Site-Info
  Aktualisierte Seiten
Impressum
Online-Publikationen
BIT Computer Zeitung
contentmanager.de ComputerWoche
documanager.de Document Management Magazine
DOKmagazin ECM Guide
E-Doc eGovernment Computing
Elektronische Steuerprüfung Information Week
IT-Business IT-Daily
IT Fokus KM World
Kommune21 MiD
MOS nfd
searchstorage.de silicon.de
Speicherguide Wissensmanagement
Google Werbung
Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com
IDEA von Audicon und BMF
Im Rahmen der Außenprüfung nach GDPdU kann die Finanzbehörde verlangen, dass die gespeicherten Unterlagen zur maschinellen Auswertung zur Verfügung gestellt werden. Dieses kann zum Einen durch Prüfung relevanter Daten und Dokumente an den operativen Systemen selbst erfolgen (Z1 und Z2 Zugriffsverfahren) oder durch die Überlassung auswertbarer Datenträger zur Prüfung in der Finanzbehörde (Z3). Laut Vorgaben des Bundesfinanzministeriums erfolgen sämtliche Prüfungen mit der kürzlich ausgewählten Software IDEA von Audicon. Das BMF hat 14.000 Lizenzen gekauft und beabsichtigt diese auch flächendeckend – nach entsprechender Ausbildung der Außenprüfer – einzusetzen. IDEA dient ausschließlich zur Analyse von Daten, die der Steuerprüfung unterliegen können. Der Einsatz wird sich kurzfristig als Standardverfahren, besonders bei der Vorbereitung der eigentlichen Außenprüfung, etablieren. Deutschland ist hier übrigens fast das Schlusslicht in Europa, da die Steuerprüfung mit direktem Datenzugriff bereits europaweit eingeführt ist.
GDPdU
Audicon
IDEA ist für Import, Selektion und Analyse großer Datenmengen ausgelegt. Gerade im Zusammenhang der langfristigen, elektronischen Archivierung der relevanten Daten sind einige Maßnahmen zu beachten um nicht Gefahr zu laufen, die Anwendungen, die diese Informationen originär erzeugt haben, entsprechen der Aufbewahrungsfristen vorhalten zu müssen.
Dieses betrifft im wesentlichen die Datenformate, auf deren Basis IDEA die notwendigen Auswertungen durchführt. Seitens der Softwarehersteller Audicon können mit der Lösung IDEA prinzipiell folgende Formate verarbeitet werden, sofern die zur Auswertung notwendigen Strukturinformationen gleichfalls in maschinell verwertbarer Form vorliegen. Diese erfüllen damit die Voraussetzung der maschinellen Verwertbarkeit im Sinne der GDPdU:
-
ASCII feste Länge
-
ASCII Delimited (einschließlich kommagetrennter Werte)
-
EBCDIC feste Länge
-
EBCDIC Dateien mit variabler Länge
-
Excel (auch ältere Versionen)
-
Access (auch ältere Versionen)
-
dBASE
-
Lotus 123
-
Druckdateien
-
Dateien von SAP/AIS
-
Konvertieren von AS/400 Datensatzbeschreibungen (FDF-Dateien erstellt von PC Support/400) in RDE-Datensatzbeschreibungen
Kommentar aus dem PROJECT CONSULT Newsletter 20020611
Newsletter
Die GDPdU sorgt immer noch für Diskussionen. Zahlreiche Veranstaltungen und Roadshows beschäftigen sich mit den Auswirkungen der Änderungen an der AO Allgemeinen Abgabenordnung und der zugehörigen Verwaltungsrichtlinie GDPdU. Durch die Auswahl des Werkzeuges IDEA von Audicon bekommt die GDPdU eine neue Qualität. Zwar ist weder im Gesetz noch in einer Richtlinie festgehalten, dass gespeicherte Daten verarbeitungsfähig für IDEA vorgehalten werden müssen; trotzdem bekommt IDEA durch die Prüfungspraxis den Status eines deutschlandweit gültigen defacto-Standards. Auch große Softwareanbieter wie SAP oder DATEV, die bisher mit eigenen Bereitstellungsstratgien für steuerrelevante, maschinell auswertbare Dateiformate am Markt agierten, müssen sich auf Druck der Anwender, die sich eine Inkompatibilität ihrer Daten bei einer Außenprüfung nicht leisten können, nun bewegen. Je schneller sich IDEA als Standard etabliert, desto besser für alle Beteiligten und auch den Steuerpflichtigen.
Hinzukommt, dass das BMF im Juli 2002 das Format für die gespeicherten Daten und die dazugehörigen Beschreibungs- und Strukturdateien veröffentlichen wird. Der Entwurf konnte bereits auf der Audicon Webseite besichtigt werden. Betrachtet man diese Definition, werden jedoch auch ein grundlegende Probleme der GDPdU deutlich. Unsaubere Begrifflichkeiten, Vermischung von Daten und Dokumenten, undifferenzierte Behandlung von Eingangs- und Ausgangsformaten einschließlich elektronisch signierter Dokumente sowie unzureichende Differenzierung zwischen Zugriff und maschineller Auswertbarkeit. Mit diesen Unzulänglichkeiten muss man leben, jedoch soll hier einmal der Versuch einer Klärung unternommen werden.
Von einigen Beratern wird versucht, einen Unterschied zwischen Datenverarbeitungs- und Archivsystemen zu postulieren, um hierdurch eine Abgrenzung zu erreichen. Archivsysteme sind jedoch auch EDV Elektronische Datenverarbeitungssysteme, sie transformieren, transportieren, schreiben Daten und haben andere Verarbeitungsfunktionalität. Dieser Versuch der Unterscheidung ist daher wenig hilfreich. Man muss vielmehr beim Datenbegriff selbst ansetzen. Hier hätte auch die Einsichtnahme in DIN-Normen zur Klärung im Vorfeld der Abfassung der GDPdU hilfreich sein können.
Ausgehend von IDEA wird klar, das die maschinell verarbeitbar vorzuhaltenden Daten im wesentlichen Daten aus Buchhaltungs-, ERP- und ähnlichen Systemen sind. Es kann hier nicht dem Archivsystem zur Auflage gemacht werden, die Daten zu erzeugen oder gar ein solches System funktional nachzubilden. Die operativen Systeme haben das Format zu erzeugen und zusammen mit der beschreibenden Profildatei an das Archiv zu übergeben. Dieses speichert lediglich unveränderbar, erlaubt den Zugriff über den Index und exportiert auf Wunsch die Datei auf das von der Finanzverwaltung geforderte Medium (dies werden vorrangig CDs und DVDs sein, jedoch werden auch spezielle Medienformate durch Konvertierungszentren der Finanzbehörden Berücksichtigung finden). Wenn das Archivsystem zusätzlich eine Viewing- oder Auswertungsfunktionalität bietet – schön für den Anwender, die Außenprüfer wollen die Dateien direkt erhalten. Die Notebooks der Außenprüfer sind speziell geschützt, so dass die Installation von Fremdsoftware oder die Nutzung von selbsttragenden Medien mit eigenen Anwendungen nicht möglich ist. Ein Export der Dateien im maschinell verarbeitbaren Format, z.B. als Liste oder gleich im IDEA-Format, ist ausreichend. Damit müssen sich auch die Anbieter selbsttragender Archive, wie z.B. die DATEV (deren heutiges Verfahren, das noch gern vorgeführt wird, bereits veraltet ist) oder die GFT Solutions mit HYPARCHIV etwas Neues einfallen lassen. Denn auch in den Finanzbehörden werden schon aus Lizenz-, Einarbeitungs- und Kompatibilitätsgründen nie die Buchhaltungs- oder Archivsysteme der geprüften Steuerpflichtigen installiert werden.
Geht man auf die ursprüngliche Intention zurück, steuerrelevante Daten (und nicht Dokumente) automatisiert zu prüfen, ist IDEA ausreichend. Nun gehören zu den steuerrelevanten Daten aber auch Eingangsdokumente, die nicht immer vom empfangenden Steuerpflichtigen in Hinblick auf Verarbeitbarkeit und langfristige Reproduzierbarkeit kontrolliert werden können. Zu den Eingangsdokumenten gehören z.B. EDI-Übermittlungen, gescannte Dokumente, digitale Faxübermittlungen, E-Mail mit Attachment und andere Formate. Deren Behandlung in Archivsystemen ist durch die GoBS, zuletzt geändert 1995, mit geregelt, da in der Einleitung der GoBS die Ausdehnung der Anforderungen von buchhalterischen Systemen auf Dokumentenmanagement- und elektronische Archivsysteme ausgeführt ist. Es kann nicht geleugnet werden, dass hier GoBS und GDPdU nicht immer konform sind. Die GoBS ist hinsichtlich der Anforderungen wesentlich deutlicher, allerdings hier und da auch selbst interpretationswürdig (siehe z.B. den Code of Practice „Grundsätze der Verfahrensdokumentation nach GoBS“ des VOI.)
Grundsätzlich sollte man zukünftig zwischen den automatisch verarbeitungsfähigen Daten, sprich strukturierten Informationen, und nur eingeschränkt verarbeitungsfähigen Dokumenten, sprich schwach oder unstrukturierten Informationen, unterscheiden. Besonders das IDEA-Verfahren konzentriert sich in erster Linie auf die strukturierten Daten.
Bevor wir mit den einzelnen Formaten beginnen, eine weitere grundsätzliche Unterscheidung für Eingangsdaten: Manche Formate wie Excel, EDI und andere werden automatisiert in die Buchhaltungs,- Zeiterfassungs- oder ERP-Systeme eingeladen. Hier sollte man die Eingangsdateien archivieren, über einen Index erschließen und in der Verfahrensdokumentation den Prozess der automatischen, verlustfreien und den Inhalt nicht verändernden Übernahme beschreiben. Andere Dateien, die in Image-Formaten wie TIFF oder als Papierdokumente vorliegen und manuell erfasst werden, gehören ebenfalls indiziert und archiviert – jedoch muss dies nicht in maschinell auswertbarer Form oder gar elektronisch vorgenommen werden. Papierdokumente sollten jedoch geordnet und mit der Buchungsnummer versehen abgelegt werden. Hier ändert sich nichts.
Bei EDI-Verfahren erfolgt im empfangenden System eine Verarbeitung auf Basis der Steuerdaten. Vielfach wird diskutiert, ob man die Daten mehrfach, also einmal unverarbeitet und einmal verarbeitet archivieren muss. Entscheidend ist jedoch die Verknüpfung der Eingangsdaten mit den verarbeiteten Daten im Buchhaltungs- oder ERP-System über den Index und die nachvollziehbare Versionierung der Konverter. Ein Zugriff durch den Außenprüfer wird immer zunächst auf die verarbeiteten Daten im Buchhaltungs-, Zahlungsverkehrs- oder ERP-System erfolgen. Erst wenn sich Unstimmigkeiten in den Daten ergeben oder die Daten in einer Weise komprimiert wurden, dass man nicht mehr auf den Einzelbeleg oder den Einzeldatensatz zurückgreifen kann, wird der Zugriff über den Index auf die zu Grunde liegenden Originaldaten erfolgen. Angesichts der Menge von Daten (und der beschränkten Festplattenkapazität der Prüfer-Notebooks) wird dies dann jedoch häufiger als Z1 oder Z2 Zugriff erfolgen. Der Prüfer kann jedoch auch verlangen, dass ihm auch solche Daten im Z3 Verfahren auf einem Datenträger überlassen werden.
Bei eingehendem Papiergut, das gescannt wird, muss nach GoBS im weiteren Verlauf einer Bearbeitung mit dem gescannten Dokument gearbeitet werden. Handelt es sich um einen steuerrelevanten Beleg, so ist auch dieser über den Index, d.h. gleiche primäre Zugriffsdaten im Archivsystem und im, die erfassten Daten verarbeitenden System (z.B. Beleg-Nr., Kundenstammdaten, Datum, Dokumentenklasse etc.), der Zugriff auf genau das gesuchte Dokument sicherzustellen. Eine maschinelle Verarbeitung ist hier nicht gefordert. Gleiches gilt für ein Fax, das digital im System eingeht. Auch hier muss eine adäquate Indizierung erfolgen, um eine eindeutige Referenzierung zum Geschäftsvorfall zu ermöglichen.
Problemfall E-Mails. Einmal sind E-Mails vom Inhalt her zu unterscheiden, ob sie steuerrelevante Informationen beinhalten oder nicht. Hier sind organisatorische Maßnahmen im Anwenderunternehmen gefordert. Zum zweiten kommt ein technisches Problem hinzu, der Kontext von E-Mail und einem Attachment muss gewahrt bleiben. Auch hier gilt: Sind steuerrelevante Informationen in einer E-Mail enthalten, unterliegen diese der Aufbewahrungsforderung nach GoBS. Sie sind ebenfalls mit einem eindeutigen Index zu versehen, der den Zugriff ermöglicht. Die Problematik liegt hier darin begründet, dass dem verarbeitenden Buchführungs- oder ERP-System das Dokument bekannt gemacht werden muss, so dass ein Zugriff von der Buchung auf das zugehörige Dokument möglich ist. Spezielle Archivsysteme, die E-Mails separat verwalten, erfüllen im Zweifelsfall nicht die Anforderung der GDPdU, auch wenn die Aufbewahrung nach GoBS gegeben ist. Hier muss sich in der Praxis noch zeigen, ob dem Außenprüfer eine unabhängige Recherche über die Index-Datenbank des E-Mail-Archives nach einem bestimmten Beleg ohne direkte Verknüpfung von E-Mail und Buchungssatz ausreichend ist. E-Mails gehören aber eigentlich nicht separat archiviert sondern geschäftsvorfallbezogen in das allgemeine elektronische Archivsystem. Für eine Prüfung wird die Beziehung zwischen einem Datum und allen dazugehörigen Dokumenten des gesamten Geschäftsvorfalles immer wichtiger. Dies schließt alle Eingangs-, Verarbeitungs- und Ausgangsbelege ein.
Eine besondere Problemklasse stellen elektronisch signierte Dokumente dar. Auch wenn sich ein Anwenderunternehmen entscheidet, selbst nicht die elektronische Signatur zu verwenden, muss man sich darauf einrichten, solche Dokumente zu erhalten und entsprechend zu speichern. Handelt es sich um einen elektronisch signierten Handelsbrief nach HGB AO, ist dieser entsprechend der vorgegebenen Aufbewahrungsfrist 6 oder 11 Jahre verfügbar zu halten. Dies schließt die datenbankgestützte Wiederauffindbarkeit ebenso wie die Reproduktion auf dem Bildschirm oder einem Drucker ein. Nun gibt es in Europa nicht nur unterschiedliche Qualitäten und technische Formate der elektronischen Signatur, der Empfänger hat außerdem keine Kontrolle über das Eingangsformat, z.B. eine spezielle bei ihm nicht eingesetzte Textverarbeitung. Eine Konvertierung des Dokumentes macht jedoch die Signatur ungültig. Qualifizierte Signaturen besitzen darüber hinaus eine beschränkte Lebensdauer, die wesentlich kürzer als die vorgeschriebene Aufbewahrungsfrist sein kann. Bei der Speicherung eines Dokumentes mit qualifizierter Signatur muss außerdem das zugehörige, abgeprüfte Zertifikat im Zusammenhang mit dem Dokument gespeichert werden. Man kann sich hier derzeit nur damit behelfen, dass man eine ausführliche Journalfunktion beim Dokumenteneingang mit laufen lässt, die Einträge im „elektronischen Posteingangsbuch“ mit den elektronisch signierten Dokumenten (aber auch z.B. anderen E-Mails) durch Referenzierung verknüpft und die Eingangsjournale ebenfalls revisionssicher archiviert. Hierdurch lässt sich zumindest der Nachweis erbringen, wann von wem das Dokument eingegangen ist, wie es weitergeleitet oder verarbeitet wurde, dass zum Zeitpunkt des Einganges das Zertifikat gültig war und das das Dokument zusammen mit dem abgerufenen Zertifikat revisionssicher archiviert wurde. Erst dann sollte man eine Kopie oder Rendition in einem langfristig stabilen, mit gängigen Viewern anzeigbaren Archivformat für die weitere Bearbeitung und Sicherstellung der Reproduzierfähigkeit erstellen und diese Rendition natürlich auch über den Index eindeutig auf das Originaldokument referenzieren. Dies bringt zwar Protokollierungs-, und Referenzierungsaufwände sowie zusätzlichen Speicherbedarf mit sich, ist aber derzeit der einzige Weg revisionssicher elektronisch signierte Dokumente zu archivieren.
Betrachtet man die Ausgangsseite von Informationen aus den Systemen des steuerpflichtigen Anwenders, so sind auch hier mehrere Fälle zu unterscheiden.
Setzt der steuerpflichtige Anwender eine Textverarbeitung ein, um anschließend das Dokument auszudrucken und per Post zu versenden, kann dieser Beleg in Kopie in Papierform geordnet aufbewahrt werden. Versendet er den Beleg, beispielsweise eine Ausgangsrechnung digital, z.B. auf einem Datenträger oder per E-Mail, so muss er die Datei in ein System überführen, das den direkten Zugriff erlaubt und außerdem einen Nachweis erbringt, dass die Datei versendet wurde. Bei der E-Mail-Versendung wäre dies ein recherchierfähiges „elektronisches Postausgangsbuch“ (analog zum elektronischen Posteingangsbuch“), bei der Erzeugung eines Datenträgers ein manueller Eintrag oder eine automatisiert erstelltes Erzeugungsprotokoll. In beiden Fällen ist der Zusammenhang mit den zugehörigen Buchungssätzen und Empfängerstammdaten sicherzustellen.
In größeren Systemen wird der Output häufig vom ERP- oder einem speziellen Druckgenerierungssystem erzeugt. Für diesen Output gilt, auch wenn der Versand später in Papierform erfolgt, dass es sich um originär digitale Daten handelt. Den Steuerprüfer dürfte hier jedoch in erster Linie nicht der einzelne Brief an den Versicherten, Kontoinhaber, Telefonbesitzer oder Stromverbraucher interessieren, wenn er auf die Daten im Verarbeitungssystem mit entsprechendem Einzelnachweis Zugriff erhält. Der Nachweis der durchgeführten Versendung ist in der digitalen Welt dann eher eine Angelegenheit der revisionssicheren Protokollierung, beim Papierausdruck und Versand in der Verfahrensdokumentation zu behandeln. Entscheidend ist beim Output, auf welche Quelle der Außenprüfer zugreifen kann. Liegen alle Daten z.B. schon im IDEA-Format vor, wird er nur im Einzelnachprüfungsfall auf andere Daten zugreifen wollen. In jedem Fall sollten Outputdaten nicht in Bildformate allein gewandelt und archiviert werden, da auch hier die Anforderung des direkten Zugriffs und der maschinellen Auswertbarkeit bestehen kann. Man setzt zu diesem Zweck in der Regel spezielle Listenformate ein. In diesen Listen können sowohl ausgelagerte Daten als auch echte Output-Daten enthalten sein. Professionelle Archivsysteme verwalten und versionieren heute schon Profildateien, die die Struktur der Liste beschreiben (z.B. nach der Empfehlung „Architektur und Grundindex 4.0“ in der Sparkassen-Finanzgruppe). Auf Grund der großen Menge von Listen und Daten erfolgt der Zugriff hier meistens zweistufig. Zunächst wird über den Index auf die Liste zugegriffen und anschließend auf Basis der referenzierten Struktur automatisch in der Liste weitergesucht. So lässt sich auch bei großen Datenmengen ein direkter Zugriff auf einzelne Datensätze oder Komponenten einer Liste erreichen. Solche Verfahren werden häufig auch unter dem Begriff „COLD“-Archivierung (Computer Output on LaserDisk) angeboten.
Schwieriger als bei der reinen Listenarchivierung, die auf auswertbaren ASCII-Zeichen basiert, wird es schon mit proprietären Formaten von Listen, deren Strukturen dem Anwender nicht transparent sind und die Probleme bei der Analyse mit IDEA mit sich bringen können. Hierbei sind besonders Ausgabeformate betroffen, die grafische Elemente des Ausdrucks beinhalten oder nur eine Aneinanderreihung der Ausgabebriefe darstellen. Hier kann der Anwender nur auf Offenlegung und Bereitstellung von Konvertern für die Wandlung in auswertbare Formate dringen. Der Anwender als Steuerpflichtiger kann sich hier nicht aus der Verantwortung stehlen, gegebenenfalls auf eigene Kosten ein auswertbares Format bereitzustellen.
Sind die steuerrelevanten Daten und Belege über das sie ursprünglich erzeugende System oder eine adäquate nachgeordnete Archivierung für die originalen Ursprungsdaten erschließbar, spielt der Zugriff auf Listen und Output-Dateien eine nachgeordnete Rolle.
Aus diesen Ausführungen sollten sechs Punkte für die elektronische Archivierung deutlich geworden sein.
1.
Elektronische Archivsysteme sind nicht so auszulegen, dass sie die Funktionalität des führenden Buchhaltungs- oder ERP-Systems nachbilden. Die Bereitstellung von auswertbaren Daten hat bereits durch die vorgeschalteten Systeme zu erfolgen. Das Archivsystem hat lediglich die Aufgabe, sie revisionssicher zu speichern, sie über den Index wieder auffindbar und sie reproduzierbar zu machen. Zum letzteren gehört auch die Aufgabe, eine Datei in das Filesystem exportieren und auf ein Medium schreiben zu können, damit sie in IDEA eingelesen werden kann.
2.
Ein Dreh- und Angelpunkt für den Zugriff ist die Index-Datenbank. Dies wird in der Diskussion um die GDPdU häufig zu nachrangig behandelt. Die Index-Datenbank muss den direkten Zugriff auf die gespeicherten Objekte und die Referenzierung zum Geschäftsvorfall und gegebenenfalls einzelnen Buchungssatz sicherstellen. Um eine Konsolidierung gestörter Index-Datenbanken zu ermöglichen, sollten die wichtigsten Informationen und Referenzierungen zusammen mit dem archivierten Objekt gespeichert werden und für ein Recovery zur Verfügung stehen. Beim Zugriff wird sich bei großen Datenmengen und bei Listen noch herauskristallisieren müssen, ob ein zweistufiges Verfahren – zuerst Zugriff auf das Objekt, dann im Objekt weitersuchen – zulässig ist. Bei großen Datenmengen ist eine direkte Indizierung nahezu unmöglich.
3.
Die GDPdU fordert keine speziellen Archive für die Speicherung von steuerrelevanten Informationen. Es obliegt dem Anwender und dem Archivsystemanbieter, geeignete Mittel zu schaffen, um den gesetzlich vorgesehen Zugriff zu ermöglichen als auch einzuschränken. Eine besondere Rolle spielen hier Berechtigungssystem und Klassenkonzepte. Werden steuerrelevante Daten und Dokumente, unabhängig von Quelle und erzeugender Anwendung, entsprechenden Dokumentenklassen zugewiesen und ermöglicht das Berechtigungssystem den kontrollierten, vollständigen Zugriff auf die diesen Klassen zugewiesenen Informationen, steht einem einheitlichen, unternehmensweit nutzbaren System, das auch nicht steuerrelevante Daten speichert, nichts im Wege. Archive nur zur Abdeckung der Anforderungen der GDPdU aufzubauen, ist unwirtschaftlich. Archivsysteme sind so auszulegen, dass sie als universelle Wissensbasis der Unternehmen dienen und – quasi nebenbei – auch die Anforderungen des Gesetzgebers erfüllen.
4.
Eine revisionssichere Archivierung von Eingangs-, Ausgangs-, Archivierungs-, Strukturänderungs- und Verarbeitungsprotokollen ist zum Nachweis der Vollständigkeit, Unverändertheit und Ordnungsmäßigkeit heute unerlässlich. Auch solche Protokolle müssen recherchierfähig sein und Referenzierungen auf einzelne Dokumente über einen Unique Identifier sicherstellen.
5.
Originär elektronisch entstandene oder empfangene Daten sind recherchierfähig und auswertbar zu archivieren. Die Konvertierung in TIFF, PDF oder andere Image-Formate ist hier nur als zusätzliche Rendition möglich, die zu dem noch unter dem gleichen Index mit Referenzierung auf das Originalformat gespeichert werden sollte. Originär digitale Dateien sind dabei nicht nur Ausgabeformate aus operativen Systemen, der Buchhaltungs- oder ERP-Software, sondern können auch Excel-Dateien und andere strukturierte Dateiformate sein. Hier ist in erster Linie vom steuerpflichtigen Anwender selbst die Wiederauffindbarkeit, Unverändertheit und Verarbeitungsfähigkeit sicherzustellen.
6.
IDEA wird sich als Standard etablieren. Anwender und Hersteller von Archivsystemen sind gut beraten, dieses Format zu speichern und für die Außenprüfung auf geeignete Medien exportieren zu können. Es ist dabei jedoch zu berücksichtigen, dass IDEA ein Format für einen speziellen Zweck ist und dass darüber hinaus auch andere Formate auswertbar verfügbar gehalten werden müssen. IDEA ist daher nicht die Lösung für das „ultimative Archivierungsformat“, sondern nur Format von vielen, die zukünftig in den Wissensbasen der Unternehmen vorliegen werden.

© CopyRight PROJECT CONSULT 2002, Autorenrechte Dr. Ulrich Kampffmeyer
Rechtshinweis
Autorenrechte
Top
Seitentitel: Rechtsfragen_IDEA, Zitierung: http://www.pc.qumram-demo.ch/portal.asp?SR=491
Zuletzt aktualisiert am: 15.6.2002
CopyRight © 1992-2012 PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
20251 Hamburg, Breitenfelder Str. 17, Tel.: +49-40-46076220, E-Mail, Rechtshinweis
Optimiert für MS Explorer 5.x, 6.x, 1024x768 Pixel, Cookies(on), JavaScript(on)
Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com
News
  Newsletter
  Newsletter Inhaltsverzeichnis
  Newsletter PDF-Ausgaben
  Newsletter Portal
  Newsletter Probeabo
  Branchen-News
  In der Diskussion
  Zitate
  Veranstaltungen
  Termine
Wissen
  Was ist...
  Archiv
  Artikel
  Pressespiegel
  Bücher
  Studien
  Literatur
  Standards
  Code of Practice
  Rechtsfragen
  Links
  Download
Markt
  Kategorie
  Alle
  PLZ
  Marktübersichten
  Produktvergleich
  Eintrag
  Regeln
Foren
  CDIA+ Forum
  CMS-Forum
  DMS-Forum
  ECMguide
  Speicherguide
  XING-Forum
Spezial-Seiten
  CDIA+
  MoReq
Web Partner
AIIM Europe AIIM International
Benchpark BIT
BITKOM BrainGuide
Coextant CompetenceSite
CompTIA contentmanager.de
DLM-Network DMS Akademie
DMS Expo documanager.de
doxtop.com ECM WORLD
Electronic Office Elektronische Steuerprüfung
GDPdU-Portal GoodNews!
Kossow & Jeggle Results Open Directory Project
Optimila password
Plattform Wissensmanagement silicon.de
SoFind Wikipedia
Wissensmanagement XING
AMAZON
  Dokumenten-Technologien
  Dokumenten-Management
  E-Learning & E-Term
  Enterprise Content Management