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

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

[sh17]

Find ich momentan am Spannendsten

https://amagno.de/

[Phoenix]

Zitat von eddie11:

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 von 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

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 von sh17:

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