Revisionssicheres Archivsystem

[eddie11]

Hi allerseits,

in unserer Firma soll ein Archivierungssystem für e-Mails, Ein- und Ausgangsrechnungen eingesetzt werden. Unsere Warenwirtschaft kann Rechnungen als PDF erzeugen und per E-Mail versenden. Wegen der gesetzlichen Vorschriften werden die Rechnungen aber nach wie vor in Papierform versendet. Per Mail verschicken wir sie nur, wenn ein Kunde vorab ein Avis haben möchte. Eingangsrechnungen akzeptieren wir momentan ebenfalls nur in Papierform.

Jetzt wird die Anzahl der Kunden und Lieferanten, die die Rechnungen nur noch per Mail versenden bzw. empfangen möchten, immer mehr. Voraussetzung dafür ist ein "revisionssicheres elektronisches Archiv". Da wir eine eigene Software-Entwicklungsabteilung haben, hat unsere Geschäftsleitung die Anfrage an uns gestellt, ob wir so ein Archivierungssystem selbst entwickeln könnten. PDFs und andere Dokumente könnten als Blobs in einer Datenbank gespeichert werden, drumherum wird eine Verwaltungs- und Suchumgebung programmiert. Technisch ist das kein Problem und auch der Entwicklungsaufwand scheint nicht allzu groß zu sein. Wie aber kriegen wir das mit der "Revisionssicherheit" hin? Und vor allem, wir kriegen wir hin, dass dieses Archiv den Vorschriften der GoBD und dem Anspruch einer Steuerprüfung gerecht wird? Dürfen wir das überhaupt selbst machen? Immerhin könnten wir als Programmierer ja nachträglich eingreifen...

Wer hat da Erfahrungen bzw. ein ähnliches Projekt bereits realisiert? Oder setzt Ihr Standard-Software dafür ein - wenn ja, welche?

Vielen Dank für Eure Antworten schon im voraus.

[hhcm]

Ich würde mir mal das bitfarm Archiv anschauen. 1) OpenSource 2) in Delphi geschrieben ;)

[Sir Rufo]

Mein Favorit:

ELOprofessional/ELOenterprise

[Der schöne Günther]

Der Kram den ich über Datenschutzrecht und den ganzen juristischen Kram gelernt habe ist zwar schon etwas her, aber ich meine es gibt mal wieder die rechtliche Vorgabe im HGB, die Dinge "revisionssicher" aufzubewahren ohne aber genau darauf einzugehen, wie diese denn umzusetzen ist, tut es dann natürlich nicht :thumb:

Die Aufbewahrung muss natürlich "elektronisch signiert" (auf dieses Buzzword fahren die Juristen nach ihrem 3-Tage Kurs EDV echt ab) stattfinden. Ich würde so etwas nie selbst machen, um das halbwegs vernünftig und wasserdicht zu bauen ist man sicher eine Weile beschäftigt.

Bei uns ist, soweit ich weiß, der "GFI Mail Archiver" im Einsatz

Oh, und nicht den Speicherplatz unterschätzen den so etwas auf Dauer (die zehn Jahre frisst), oh nein :-D

[sh17]

Find ich momentan am Spannendsten

https://amagno.de/

[Phoenix]

Zitat:

Zitat von eddie11 (Beitrag 1308982)

Da wir eine eigene Software-Entwicklungsabteilung haben, hat unsere Geschäftsleitung die Anfrage an uns gestellt, ob wir so ein Archivierungssystem selbst entwickeln könnten.

Sicher. Ist aber nicht so mal hopp-hopp gemacht. Ich würde eher versuchen, eine Lösung einzukaufen.

Was die Revisionssicherheit angeht: Es ist heutzutage relativ einfach das zu machen. Einfach GIT als Datenspeicher nutzen anstelle von Blobs in einer DB.

Jedes Dokument wird in eine Git-Repository eingecheckt. Die Git-Historie ist kryptographisch gesichert, das heisst wenn man zu jedem Dokument auch den Commit-Hash mit rausgibt, ist sichergestellt das das auch wirklich dieses eine Dokument mit genau dieser Historie war. Auch als Entwickler kann man nicht eingreifen - zumindest nicht so dass es nicht auffallen würde, da sich dann die Hashes ändern. Und da die Historie mit diesen Hasches Kryptografisch gesichert ist, kann man das durchaus als 'Signiert' bezeichnen. Auch das Backup ist recht einfach. Einfach ein Verzeichnis wegsichern und gut ist.

Deine Anwendung verwaltet dann nur die Metadaten in einer DB und benutzt eben Git für das eigentlich Handling der Dateien.

[Sherlock]

Und weil man mit git allen möglichen und auch unmöglichen Unfug anstellen kann, würde ich das eben nicht mit git machen. Ansonsten ist git bzw. ein DVCS eine Klasse Sache, aber die Möglichkeiten, die der Anwender hat sind zu gravierend. Dann lieber ein CMS auf einem gebackgeuppten Webserver, wobei das auch nicht meine erte Wahl wäre, aber der Zugriff darauf ist für Normalanwender deutlich restriktiver.

Sherlock

[eddie11]

Vielen Dank vorerst für Eure Lösungsvorschläge, Bitfarm scheint mir ein interessanter Ansatz zu sein. Da gibt es eine kostenlose GPL-Edition, die es uns ermöglicht, erst mal zu sehen ob das für uns passt. Das ist vielleicht (wahrscheinlich) besser, als es komplett selbst zu machen - schließlich müssen wir das ja auch noch in unser ERP-System integrieren.

Danke

[sh17]

Zitat:

Zitat von eddie11 (Beitrag 1309206)

Vielen Dank vorerst für Eure Lösungsvorschläge, Bitfarm scheint mir ein interessanter Ansatz zu sein. Da gibt es eine kostenlose GPL-Edition, die es uns ermöglicht, erst mal zu sehen ob das für uns passt. Das ist vielleicht (wahrscheinlich) besser, als es komplett selbst zu machen - schließlich müssen wir das ja auch noch in unser ERP-System integrieren.

Danke

Hmm, Quellen über ein Jahr alt, SourceForge-Forum down. Version auf der Startseite unterscheidet sich von der Version auf der Downloadload-Seite. Ich glaub da sollte man erst mal zum Lernen in den Quellen lesen, wie Revisionssicherheit umgesetzt wurde. Vielleicht doch kein Hexenwerk.

//Edit
https://www.bitfarm-archiv.de/dokume...t/faq.html#008 (Warum bietet bitfarm-Archiv kein DMS-Laufwerk an, wie einige andere Anbieter?)
So ein Laufwerk halte ich durchaus für wichtig, wenn das DMS mehr als nur eine Ablage unveränderlicher Dateien werden soll.

[eddie11]

Zitat:

Zitat von sh17 (Beitrag 1309207)

Hmm, Quellen über ein Jahr alt, SourceForge-Forum down. Version auf der Startseite unterscheidet sich von der Version auf der Downloadload-Seite. Ich glaub da sollte man erst mal zum Lernen in den Quellen lesen, wie Revisionssicherheit umgesetzt wurde. Vielleicht doch kein Hexenwerk.

ooops, da sollte ich tatsächlich mal nachsehen, inwieweit das "zukunftsträchtig" ist :oops:

[sh17]

Ich behaupte ja nicht, das die aktuelle Version nicht gepflegt ist, aber hier wird glaube der OpenSource-Gedanke etwas anders ausgelegt, OpenSource wird quasi etwas zeitversetzt veröffentlicht.

[borncrush]

Hallo,

da ich wir u.a. damit unser Geld verdienen. Würde ich Dich zuerst fragen, welche ERP Du einsetzt.
Gerade wenn die --Integration-- als Faktor ist.

Wobei wir sehr zufriedene Kunden haben, die auch DMS Systeme ohne ERP-Anbindung verwenden.
Bei sehr vielen Dokumenten(-arten) ist eine direkte Integration in die ERP fast notwendig.

Je nach Ausgangslage.

Guten Wochenstart für alle und genießt :-)

[jobo]

"zukunftsträchtig"
Ja, das sollte man, das ist Delphi 7. Ebenso für die verwendeten Zusatzkomponenten.

[eddie11]

Zitat:

Zitat von borncrush (Beitrag 1309210)

... welche ERP Du einsetzt.

bei uns wird Navision Financials eingesetzt. Wir haben Navision 1999 angeschafft. Dazu haben wir eine Entwicklerlizent, die es uns ermöglicht Änderungen/Erweiterungen am Programm vorzunehmen. Wir haben seit 2003 auf Updates verzichtet, da unser System aufgrund von Anpassungen sehr stark vom Standard abweicht.

Zitat:

da ich wir u.a. damit unser Geld verdienen

was bietest Du/bietet Ihr denn so an?

[sh17]

Also nachdem ich mich schon mehrmals ins Thema eingelesen hatte, viele Prinzipien können eigentlich nicht also revisionssicher angesehen werden. Ohne Hardware kommt man da nicht weit. Ein guter Einstieg wäre https://de.wikipedia.org/wiki/Elektr...e_Archivierung. Andererseits, welches Speichermedium hält mindestens 10 Jahre, um die geforderter Aufbewahrungsfrist zu erreichen?

Worauf ich eben immer noch eine praxistaugliche Antwort suche, was muss mindestens nach GoBD erforderlich sein, um gesetzlich bei der Aufbewahrung von Dokumenten auf der sicheren Seite zu sein? Eine einfache Datenbank kann es meiner Meinung nach nicht sein.

[eddie11]

Zitat:

Zitat von sh17 (Beitrag 1309230)

Also nachdem ich mich schon mehrmals ins Thema eingelesen hatte, viele Prinzipien können eigentlich nicht also revisionssicher angesehen werden. Ohne Hardware kommt man da nicht weit. Ein guter Einstieg wäre https://de.wikipedia.org/wiki/Elektr...e_Archivierung. Andererseits, welches Speichermedium hält mindestens 10 Jahre, um die geforderter Aufbewahrungsfrist zu erreichen?

Ich denke nicht, dass das Medium, auf dem die erste Speicherung erfolgte, wirklich 10 Jahre halten muss. Es muss halt sichergestellt sein, dass alles nach 10 Jahren noch verfügbar ist. Also: Speicherung auf irgendeinem Medium (z.B. Festplatte), regelmäßige Datensicherung und Prüfung ob alles lesbar ist (das ist eh in jedem vernünftigen Rechenzentrum bzw. IT-Abteilung üblich). Wenn ein Medium nicht mehr eingesetzt wird, so wie früher die Disketten, oder wenn eine Festplatte kaputtgeht, dann umkopieren auf neues Medium.

Zitat:

Zitat von sh17 (Beitrag 1309230)

Worauf ich eben immer noch eine praxistaugliche Antwort suche, was muss mindestens nach GoBD erforderlich sein, um gesetzlich bei der Aufbewahrung von Dokumenten auf der sicheren Seite zu sein? Eine einfache Datenbank kann es meiner Meinung nach nicht sein.

Also nur eine "einfache" Datenbank, ohne Versionskontrolle und Lösch-Schutz wirds wohl wirklich nicht tun. Aber wenn die z.B. auf einem Worm (Hard-/ oder Software) liegt, dann ist ja alles klar.
Darüber hinaus ist wichtig, den Vorgang und die Zugriffsrechte etc. der Archivierung zu dokumentieren und ggf. von einem Wirtschaftsprüfer checken zu lassen.

[Uwe Raabe]

Zitat:

Zitat von eddie11 (Beitrag 1309237)

Ich denke nicht, dass das Medium, auf dem die erste Speicherung erfolgte, wirklich 10 Jahre halten muss. Es muss halt sichergestellt sein, dass alles nach 10 Jahren noch verfügbar ist. Also: Speicherung auf irgendeinem Medium (z.B. Festplatte), regelmäßige Datensicherung und Prüfung ob alles lesbar ist (das ist eh in jedem vernünftigen Rechenzentrum bzw. IT-Abteilung üblich). Wenn ein Medium nicht mehr eingesetzt wird, so wie früher die Disketten, oder wenn eine Festplatte kaputtgeht, dann umkopieren auf neues Medium.

...

Aber wenn die z.B. auf einem Worm (Hard-/ oder Software) liegt, dann ist ja alles klar.

Angenommen, ich speichere die Daten revisionssicher auf einem WORM. Das muss dann sagen wir mal nach 5 Jahren ersetzt werden, da die Lesemöglichkeit in weiteren 5 Jahren nicht sichergestellt werden kann. Wie garantiert man, daß beim Schreiben auf ein anderes WORM-Medium wirklich der originale Inhalt drauf steht? Ich könnte ja zwichen dem Lesen vom alten und Schreiben auf das neue noch manipulieren, oder?

[sh17]

Zitat:

Zitat von eddie11 (Beitrag 1309237)

Also nur eine "einfache" Datenbank, ohne Versionskontrolle und Lösch-Schutz wirds wohl wirklich nicht tun. Aber wenn die z.B. auf einem Worm (Hard-/ oder Software) liegt, dann ist ja alles klar.
Darüber hinaus ist wichtig, den Vorgang und die Zugriffsrechte etc. der Archivierung zu dokumentieren und ggf. von einem Wirtschaftsprüfer checken zu lassen.

Und wie könnte der aussehen? Abgesehen von irgend welchen Triggern oder Table-Restriktionen, die ein Löschen verhindern, kann man doch mit mit jedem beliebigen DB-Admin-Tool das ganze von Hand manipulieren. Und das soll ja nun gerade nicht möglich sein. Oder ist ein so hoher Schutz gar nicht erforderlich nach GoBD?

[eddie11]

Zitat:

Zitat von Uwe Raabe (Beitrag 1309241)

Angenommen, ich speichere die Daten revisionssicher auf einem WORM. Das muss dann sagen wir mal nach 5 Jahren ersetzt werden, da die Lesemöglichkeit in weiteren 5 Jahren nicht sichergestellt werden kann. Wie garantiert man, daß beim Schreiben auf ein anderes WORM-Medium wirklich der originale Inhalt drauf steht? Ich könnte ja zwichen dem Lesen vom alten und Schreiben auf das neue noch manipulieren, oder?

Hmm, grundsätzlich hast Du da recht, da fällt mir auch keine Antwort ein. Ich denke, dass dieser Fall dann ordnungsgemäß dokumentiert werden müsste.

[eddie11]

Zitat:

Zitat von sh17 (Beitrag 1309242)

Und wie könnte der aussehen? Abgesehen von irgend welchen Triggern oder Table-Restriktionen, die ein Löschen verhindern, kann man doch mit mit jedem beliebigen DB-Admin-Tool das ganze von Hand manipulieren. Und das soll ja nun gerade nicht möglich sein. Oder ist ein so hoher Schutz gar nicht erforderlich nach GoBD?

So einfach dann auch nicht. Es muss sichergestellt sein, dass auch mit Admin-Tools und Admin-Rechten keine Veränderung möglich ist.

[sh17]

Zitat:

Zitat von eddie11 (Beitrag 1309247)

Zitat:

Zitat von sh17 (Beitrag 1309242)

Und wie könnte der aussehen? Abgesehen von irgend welchen Triggern oder Table-Restriktionen, die ein Löschen verhindern, kann man doch mit mit jedem beliebigen DB-Admin-Tool das ganze von Hand manipulieren. Und das soll ja nun gerade nicht möglich sein. Oder ist ein so hoher Schutz gar nicht erforderlich nach GoBD?

So einfach dann auch nicht. Es muss sichergestellt sein, dass auch mit Admin-Tools und Admin-Rechten keine Veränderung möglich ist.

Genau, und hier jetzt bitte etwas konkreter werden. Wie ermöglichen das die verfügbaren DMS am Markt? Davon steht nirgends etwas. Ein Hardware-WORM oder Software-WORM scheint es nicht zu sein.

[Phoenix]

Einen 100%-igen Schutz kann es nicht geben.
Das ganze ist immer eine Kombination von technischen Schutzmaßnahmen, die von organisatorischen Maßnahmen begleitet werden.

Ob das ganze System am Ende passt, kann man zertifizieren lassen.
Die Kritierien, nach denen z.B. der TÜV Prüft sind einsehbar. Das sind die sog. "PK-DML" - Prüfkriterien für Dokumentenmanagement-Lösungen des VOI. Die Kriterien kann man für 60€ bestellen und dann seine Lösung so implementieren, dass sie diesen Kriterien entspricht. Danach kann man sich zertifizieren lassen.
Das Dokument gibts hier: http://www.voi.de/index.php/componen.../9/22?Itemid=0

[sh17]

Cool, Danke

[eddie11]

@Phoenix: danke, dieser Link hilft mir auch weiter

[DomZon]

Also in unserer Firma wird die Archivierungssoftware Doxis4 zu diesme Zweck genutzt. Ich komme mit der Software allerdings nur am Rande in Kontakt sodass ich leider nicht allzu viel dazu sagen kann.