ecoDMS - Originaldateien erhalten

[D-Nero]

Guten Morgen,

wie bereits in anderen Threads beschrieben, arbeite ich mich gerade in Richtung des papierlosen Büros vor.
Zu dessen Unterstützung soll ecoDMS zum Einsatz kommen.
Meine Ds218+ ist noch nicht da um die finale Installation auf dem NAS vorzunehmen.
Daher spiele ich gerade auf meiner Windows-Kiste damit herum.
Bislang gefällt mir das alles ganz gut. Es gibt lediglich zwei Punkte, die mich stören. Aber vielleicht stelle ich mich ja nur zu flach an und es kennt jemand eine Lösung.

1. Der Scaninput-Ordner im Windows Dateisystem kann scheinbar nicht geändert werden. Ich hasse es wenn solche Dinger irgendwo unter C: rumbaumeln. In meinem jetzigen (nicht finalen) Setup synchronisiere ich einen Ordner vom NAS, in dem alle Scans landen, mit einem lokalen Ordner in meiner "Office"-Struktur (z.B.: D:/office/scans"). Jetzt wäre es doch wunderbar wenn ecoDMS genau diesen überwachten Ordner als scaninput nehmen würde. Doch das scheint nicht zu gehen, oder?

2. Das ist mein größtes Problem: ich finde es extrem beunruhigend, dass die Originaldateien nach der Verarbeitung durch ecoDMS im Dateisystem nicht mehr vorhanden sind und offenbar in den ecoDMS "Containern" und der Datenbank verschwinden. Mein Vertrauen in diese für mich neue Software ist noch nicht so ausgeprägt, dass ich annehme, dass ich auch bei übelstem Software-Crash/-Gau diese Container wiederherstellen und an meine Dokumente kommen kann. Ganz zu schweigen davon, dass der Hersteller vielleicht die Grätsche macht oder ich die Software wechseln will. Mich würde es schon beruhigen wenn eine lesbare Datei auf meinen Laufwerken als Sicherheit verbleiben würde. Gibt es eine Möglichkeit dieses Verhalten abzuändern? Idealerweise gäbe es einfach die in ecoDMS angelegte Ordnerstruktur auch im Dateisystem. Dann wäre alles fein.

Vielen Dank und viele Grüße
Daniel

 

[JudgeDredd]

Hallo,

also zur WIndows Version von ecoDMS kann ich nichts beitragen. Ich habe eine Linux-Installation.

1.) Bei der Linux Variante ist der scaninput-Folder als SMB-Share veröffentlicht, den kannst Du nennen wie auch immer Du möchtest.
Das physikalische Verzeichnis liegt bei mir unterhalb von /opt und wurde von ecoDMS vorgegeben.

2.) Jedes halbwegs professionelle und mir bekannte DMS legt seine Daten in einer DB ab. Sonst wären große Datenmengen ja auch überhaupt nicht indexierbar.
Das speichern der ursprünglichen Datei in einem Verzeichnis, klingt eher nach einer kleinen Excel-Lösung, als einem richtigen DMS.
Zur Sicherheit erstelle ich jede Nacht ein Backup der Daten und rotiere es nach 5 Tagen.

Ich hoffe mein Input hat Dir geholfen, denn eine richtige Frage habe ich nicht gefunden.

Gruß,
JudgeDredd

 

[D-Nero]

Meine beiden Fragen waren an den Fragezeichen erkennbar. ;-)

Zu 2.: das ecoDMS die Daten in Container und DB speichert ist ja okay und war nicht mein Kritikpunkt.
Mein Kritikpunkt war, dass die Originaldatei, die ich dem scaninput-Ordner zuführe, auf Nimmerwiedersehen verschwindet.
Aus Sicht des DMS verstehe ich das auch.
Dennoch bin ich vermutlich zu paranoid und habe in meiner IT-unterstützen Lebenszeit zu viele Datenverluste erlebt um mich darauf zu verlassen, dass die Backupmechanismen einer Software auf Jahre zuverlässig funktionieren.
Aus diesem Grund war die Frage ob ich ecodms schlicht und einfach dazu bewegen kann die Originaldatei nach Verarbeitung nicht zu löschen?
Falls dies nicht geht, werde ich mir wieder mit irgendwelchen Sync-Jobs behelfen müssen...

 

[servilianus]

Du legst bei der Implementierung von ecodms einen gemeinsamen Ordner "scaninput" an, auf den schiebt dann Dein Scanner per FTP, SMB oder was auch immer die pdfs drauf. Von dort werden sie von ecodms abgeholt. Die Verfahrensweise ist im ecodms-Handbuch für die Synology-Serverinstallation genaustens beschrieben. Und ja: Natürlich liegen die Dokumente in Containern. Diese Container werden bei mir regelmässig gebackupt.

Was Du natürlich auch machen kannst - für maximale Sicherheit: Innerhalb von ecodms kannst Du ja auch die Unterlagen, die für Dich wichtig sind, als pdfs irgendwohin exportieren. Dann erstellt ecodms eine zip-Datei.

 

[D-Nero]

Das Handbuch habe ich bereits genaustens studiert.
Die Prozesse sind mir bereits bekannt.
Die Backups enthalten aber auch nur wieder die Container und keine PDF-Dateien.
Beim Export scheint es so zu sein, dass ich nur einzelne ausgewählte Dateien exportieren kann und das manuell anstoßen muss.

Abgesehen von dem Datenverlustrisiko: was mache ich denn, wenn ich in 10 Jahren auf ein anderes DMS umsteigen will?
Alle zigtausend Dateien wieder einzeln exportieren um sie dann in dass neue DMS zu migrieren?

Ich befürchte es läuft auf die Redundanz durch Synchronisation hinaus....

 

[JudgeDredd]

Aus diesem Grund war die Frage ob ich ecodms schlicht und einfach dazu bewegen kann die Originaldatei nach Verarbeitung nicht zu löschen?

Nein, das kann man Gottseidank in ecoDMS nicht einstellen, sonst hätte man ja alles doppelt.

Um Deine innere Paranoia zu befriedigen, wirst Du wohl selbst was basteln müssen.

 

[servilianus]

Du kannst doch Deinem Scanner sagen, er soll die pdfs sowohl auf den ecodms-scaninput-folder schieben, als auch auf einen zweiten, wo sie dann liegen bleiben.
Zudem kannst Du auch viele Dokumente en block markieren und dann aus ecodms herausexportieren.

 

[D-Nero]

Ob das direkt vom Scanner her geht, weiß ich nicht. Aber ich würde sie dann in meinen Standardordner legen lassen und von dort per Einwegsynchronisation in den scaninput-Ordner.

 

[JudgeDredd]

Abgesehen von dem Datenverlustrisiko: was mache ich denn, wenn ich in 10 Jahren auf ein anderes DMS umsteigen will?
Alle zigtausend Dateien wieder einzeln exportieren um sie dann in dass neue DMS zu migrieren?

Entweder das neue DMS hat ein Migrationsskript, Du schreibst Dir selbst eins oder Du fängst von vorne an.
Das ist aber nicht nur bei einem DMS so, das hast Du bei jedem Internetforum wenn Du wechseln möchtest.

 

[servilianus]

klar, auch eine Möglichkeit.

 

[frankenpeter]

Gibt es inzwischen eine neue Möglichkeit? Für mich wäre auch wichtig eine Sicherheit zu haben, dass ich in ein paar Jahren ggf. die Software wechseln kann und die ecodms-Datenbank mitnehmen kann. Gibt es eine DMS, die eine Backup-Datei von ecodms komplett übernehmen kann?

Vielen Dank

 

[servilianus]

Die Datenbank von ecodms ist propietär, also nicht 1:1 in ein anderes System einzuspielen. Aber Du kannst alle Dokumente als pdfs herausexportieren.

Die Exportfunktionen von ecodms sind hier beschrieben:

https://www.youtube.com/watch?v=hskUz1WpqFQ

Oder Du du speicherst halt vor der Verarbeitung durch ecodms die Originaldateien/pdfs parallel an einer anderen Stelle, bsp., indem Du den Scanner anweist, die Dateien nicht nur in den Ordner Scaninput zu schieben, sondern noch in einen zweiten Ordner.

 

[Uhlhorn]

[…]und offenbar in den ecoDMS "Containern" und der Datenbank verschwinden.

Bei Docker kann man Container persistent machen. Das bedeutet, dass bestimmte Ordner in den Containern nach außen verlagert werden, deren Inhalt also nicht mehr innerhalb von Containern gespeichert wird. Auf diese Art und Weise kann man Container und deren Inhalt (Daten) trennen. Und das sollte man auch unbedingt machen.

Bei mir liegt die ecoDMS-Datenbank in einem Ordner auf dem NAS, den ich freigegeben habe. Dort ist auch ein Ordner „Backup“ wohin das Backup gemacht wird. Dieser wird mit der Dropbox synchronisiert, so dass ich das Backup auch noch zusätzlich zum c2-Backup in der Dropbox habe.

 

[servilianus]

Aber das löst das „Problem“ nicht, nämlich, dass die ecodms-Datenbank propietär ist. D.h., Du benötigst immer ecodms, um die Originaldateien wieder sichtbar zu machen. Es sei denn, Du speicherst die Original-pdfs irgendwo parallel woanders ab- aber dann eben ohne die Datenbankfunktionen wie zb. Klassifizierungen, etc. Das sind eben die Vor/ Nachteile von Datenbanken. Ist doch bei Synology dasselbe: Wenn Du Deine Fotos in der Syno in Moments speicherst, gibt Dir ja auch keiner die Garantie, dass Moments bis in alle Ewigkeit wiederherstellbar ist, etwa nach einer Pleite von Synology, was Gott behüte...

 

[Uhlhorn]

Ja, das stimmt schon, das gefällt mir auch nicht. Doch wie willst Du sonst Dokumente vor Änderung schützen und eine Versionierung hinbekommen? Wenn Du auf diese Funktionen verzichten kannst, kannst Du die Dokumente auch einfach als Dateien in Ordner sortieren und gar kein dediziertes DMS verwenden.

Ich z.B. arbeite auf einem Mac, dort braucht man eigentlich kein DMS: der Mac durchsucht bei seiner globalen Suche auch den Inhalt von PDFs. Man kann außerdem Tags vergeben und Schlagworte zuweisen. Dokumente kann man in Ordner sortieren und man kann auch nach Datum suchen. Alles, wozu man normalerweise ein DMS benötigt. Nur drei Sachen gehen nicht mit Bordmitteln: Versionierung, Festschreibung und Wiedervorlage. Nur deswegen habe ich mir dann doch ecoDMS zugelegt.

Möglicherweise ist es für Dich sinnvoller einfach die Daten auf dem Rechner zu speichern – ich weiß es nicht.

Zur Not kann man aber die Dokumente auch auf einen Schlag exportieren … nur so als Idee.

 

[servilianus]

Auf dem Mac geht auch etwas sehr wesentliches nicht: Revisionssicheres archivieren für das Finanzamt (was ecodms kann). Ausserdem kann der Mac die umfangreichen Klassifizierungsmöglichkeiten nicht. Also für geschäftliches Verwenden geht an einem DMS nichts vorbei, und ich finde ecodms ein sensationelles Preis-Leistungsverhältnis. Ich verwende überdies ecoMailz für die revisionssichere Speicherung von Mails, was ja auch im geschäftlichen Umfeld vorgeschrieben ist.

 

[Uhlhorn]

Ja, genau. Versionierung, Festschreibung und Wiedervorlage. Das sind die Funktionen, die nicht gehen. Falls man die benötigt, braucht man natürlich ein DMS. Doch nicht immer benötigt man diese Funktionen.
Die Festschreibung (also revisionssicheres Archivieren) braucht man nur, wenn man die Papier-Originale wegwerfen will. Sonst nicht.

Ich habe bisher alle Urkunden und alle Rechnungen über 100 EUR im Original aufgehoben. Den Rest habe ich entsorgt und nur deren Scans aufgehoben. Bei Belegen unter der Bagatellgrenze (100,– EUR) wird das Finanzamt kaum auf das Papier-Original bestehen. Und die wenigen Papierbelege habe ich nach dem Scannen nur in einen Karton gelegt. Dort kann ich sie im Notfall wieder heraussuchen. Bei meiner letzten Prüfung wollten sie aber kein einziges Original sehen.

Seitdem ich es so mache, komme ich mit einem(!) kleinen Ordner für mehrere Jahre aus. Denn rund 90 % aller Belege kommen heutzutage ohnehin schon digital. Ich mache das schon seit 2013 und 2013…2015 sind kürzlich geprüft worden.

Außerdem habe ich die Belegverarbeitung und Buchhaltung weitgehend automatisiert. Ich kann das gerne mal ausführen, wenn es interessiert.

 

[JudgeDredd]

Aber das löst das „Problem“ nicht, nämlich, dass die ecodms-Datenbank propietär ist. D.h., Du benötigst immer ecodms, um die Originaldateien wieder sichtbar zu machen.

Was genau soll denn an der Datenbank proprietär sein ? ecoDMS läuft mit einer PostgreSQL DB. Dort kann man wie bei jeder anderen DB auch SQL Befehle absetzen. Ob es nun eine MariaDB, MS SQL oder gar ne Orcale ist, spielt doch keine Rolle.
Aus einem SQL-Dump kann man so jederzeit die Dokumente wieder herstellen.
Damit beschäftigt man sich aber nicht erst wenn die Hütte brennt, sondern am besten vor dem ersten Dokumenten-Scan.

 

[Uhlhorn]

ecoDMS läuft mit einer PostgreSQL DB. Dort kann man wie bei jeder anderen DB auch SQL Befehle absetzen.

Nein, „man“ kann das nicht. Man muss das erst mal erlernen. Genau so gut könntest Du sagen, man muss das nur in C++ programmieren oder so. Die allermeisten Computernutzer können das nicht.

servilianus hat in einer Beziehung Recht: es wäre besser, wenn die PDFs als PDF in eine Ordnerstruktur abgelegt werden würde und nur der Rest in die Datenbank geschrieben werden würde. Also in etwa so, wie das iTunes mit Musik macht (oder war das iPhone mit Fotos?).

 

[JudgeDredd]

Nein, „man“ kann das nicht. Man muss das erst mal erlernen.

OK, da gebe ich Dir natürlich Recht, aber ich wollte auch eher darauf hinaus, das ecoDMS nicht mit einer proprietären DB arbeitet, sondern eben mit einer DB, die sich nicht großartig im Befehlssatz von einer anderen DB unterscheidet.

servilianus hat in einer Beziehung Recht: es wäre besser, wenn die PDFs als PDF in eine Ordnerstruktur abgelegt werden würde und nur der Rest in die Datenbank geschrieben werden würde.

Da hingegen gebe ich Dir kein Recht. Das ist bestenfalls (D)eine Meinung, mehr nicht. Files die in einer festen Beziehung zu einem Datensatz in einer DB stehen, lösen schnell inkonsistenzen aus, wenn z.B. eine Datei umbenannt wird oder ein Datensatz gelöscht wird, ohne die Dateioperation nachzuziehen etc...
Ich kann Dir aus dem Enterprise Bereich berichten, das die Ablage im Dateisystem absolut unüblich ist.