Finger weg von ecoDMS

Ein Erfahrungsbericht eines langjährigen Nutzers

Ich hätte es doch besser wissen sollen. Immer wenn ich wieder einmal glaube, proprietäre und nicht-quelloffene Software könnte bei irgendetwas besser sein als Open-Source-Software, werde ich eines Besseren belehrt. So leider auch bei der Software ecoDMS, die von der ecoDMS GmbH, einem Unternehmen der applord Holding Europe GmbH, vertrieben wird.

Diese Software – ein Dokumentenmanagementsystem (DMS) – erfüllt ihren Zweck, solange man

  1. brav für alle Updates bezahlt und diese einspielt;
  2. bereit ist, im Voraus Geld für Support-Pakete zu bezahlen, damit Softwarefehler analysiert und ggf. (sic!) gefixt werden;
  3. sich nur in homogenen IT-Umgebungen befindet; und
  4. kein Problem damit hat, dass seine geschäftskritischen Daten in einer proprietären Datenbankform gespeichert werden.

Dieser Blogbeitrag beschreibt die Tiefen, die ich mit dieser Software erlebt habe, und darf dir ein Praxis-Ratgeber sein, dich besser gleich für Open-Source zu entscheiden. Denn am Ende steht ein vermeintlich revisionssicheres Archiv, aus welchem Dokumente verschwinden 💥, wo interne DocIDs mit neuen Dokumenten überschrieben werden 🤯 und aus welchem du deine PDF-Dateien im Ernstfall nicht wieder rausbekommst.

* * *

Inhaltsverzeichnis

Genau ein Tipp
Short story long
    Lizenzprobleme und Fehlermeldungen
    Bugs über Bugs
    Backup-Wiederherstellung – Lizenzproblem und Fehler
    Wie komme ich wieder an meine Daten?
        Basics zum Datengrab ecoDMS
        Weg 1: ecoDMS Export
        Weg 2: Klassifizierungsinfo aus der PostgreSQL-DB retten
        Weg 3: Aus einem Backup
    Sidestory: Alltag mit ecoDMS
        Suchfunktion benötigt Regex-Kurs
        Klassifizierungsattribute für die Ewigkeit
        Webclient ist Schrott
    Money first, Support second
        Kostenpflichtige Supportpakete mit Ablaufdatum
        Der Knaller 💣💥

Ich möchte ein Open-Source DMS in meinem Unternehmen einsetzen und benötige dabei Unterstützung.
Weiterführende Links

* * *

Genau ein Tipp

Wenn ich also einen Tipp für dich habe, dann dieser:
Finger weg von allem, was nicht Open-Source ist, wenn es um kritische Geschäftsprozesse geht.
Immer.

Denn am Ende gewinnt immer die Bank (in diesem Fall die Firma, der die Software "gehört").
Sei es dadurch, dass du durch deren Cloud-Services deine wertvollen Daten an diese verkaufst und im Zweifel nicht mehr drankommst, weil das Abo abgelaufen ist (z.B. Creative Cloud). Oder weil die Firma deine Daten in proprietären Formaten abspeichern und du nicht mehr drankommst, wenn du sie exportieren oder anderweitig verwenden möchtest (z.B. ecoDMS). Bei Problemen hilft dir dann höchstens ein Support, dessen Tickets nicht öffentlich zugänglich sind. Somit mehrst du mit jedem Ticket das Hoheits-Wissen des Unternehmens; der Allgemeinheit dient das nicht.
Klassischer Lock-In-Effekt eben.

Los gehts also mit dieser traurigen Geschichte rund um das vermeintlich revisionssichere Archiv.

* * *

Short story long

Ich war seit 18. April 2017 ecoDMS-Kunde (damals begonnen mit 16.09 (eleanor), heute 21.12 (bullshit)) und nutze das System seither in einer kleinen virtual machine. Diese ist mit vier Kernen und ca. 3GB RAM ausgestattet, da die auf Java basierende Software entsprechend viel Arbeitsspeicher verbraucht. Als Betriebssystem kommt – gemäß Handbuch – Ubuntu 20.04 (damals mit ecoDMS 18.04, was kurz nach 16.09 veröffentlicht wurde, war es noch Ubuntu 18.04) zum Einsatz und die VM wurde für nichts sonst verwendet.

Lizenzprobleme und Fehlermeldungen

Los ging es schon mit Lizenzproblemen und seltsamen Fehlermeldungen. Anfangs hatte ich nur eine gleichzeitige Lizenz gekauft, da maximal eine Person mit dem System arbeitet. Allerdings registriert die Software bis heute den Neustart eines Clients nicht als "Abmeldung".

Heißt, wenn ich an einem Client eingeloggt bin und den Client-PC neu starten muss (z.B. weil sich der ecoDMS Client nicht mehr starten lässt), gilt die Lizenz weiterhin als "benutzt" und ich kann mich daraufhin für einen Zeitraum X nicht mehr in ecoDMS einloggen:

Anmeldung fehlgeschlagen – Anzahl der verfügbaren Lizenzen überschritten

Ergebnis: Ich kann nicht (mehr) arbeiten und komme nicht mehr an meine Dokumente.

Abhilfe schafft dabei nur abwarten, eine weitere "Puffer-Lizenz" für diesen Fall kaufen oder auf dem Server als ecoSIMSAdmin einloggen und die Sitzung händisch beenden.

Auch treten beim Login immer mal wieder Probleme wie dieses hier auf:

Anmeldung fehlgeschlagen – Keine Antwortnachricht erhalten

Abhilfe schafft hier nur ein Neustart des ecoDMS-Servers mit systemctl restart ecodms.service. Oft hängt sich auch der ganze Prozess so hart auf, dass man die ganze VM neu starten oder die einzelnen Prozesse killen 🙄 muss:

ps -aef | grep ecodms ; kill PROCESSIDS
* * *

Bugs über Bugs

All die Bugs, die ich im Laufe meiner Zeit mit ecoDMS so gefunden habe, würden ein schönes Käferkabinett ergeben 🐛. Die Software (bzw. das Linux-Pendant davon) wirkt eher wie ein Bananenprodukt, das beim Kunden reift, als wie eine ausgereifte Lösung für den Produktiveinsatz.

Meine Bugreports reichten damals von

Simpler Bugreport
Wenn man in den Klassifizierungsattributen zwei Datumsfelder hat, stören sich diese in der Oberfläche gegenseitig und es ist teilweise ein bestimmtes Datum nicht mehr anwählbar.

Dieser Bug bestand auch schon in der vorherigen Version 16 von ecoDMS.

über

Ausführlicher Bugreport
Der Client speichert nach insgesamt drei bis vier Startvorgängen die Tabellenheader nicht mehr und stellt die "Standardeinstellung" wieder her.

bis hin zu

Extremer Bugreport
Guten Tag liebes ecoDMS-Team,

danke für die Rückmeldung.

Ich habe auch noch einige Szenarien, die immer wieder einen Totalabsturz des ecoDMS-Clients verursachen (segmentation fault). Da ich viel zu tun hatte, habe ich hier keine weiteren Dumbs erstellt, könte Ihnen da aber noch ausführliche Infos zukommen lassen.

Haben Sie Interesse daran?

Lieber Gruß
Christian Süßenguth

Man kann mir also durchaus Wohlwollen und einen langen Atem mit dieser verbuggten Software unterstellen. Das nur mal für den Hinterkopf, denn das Thema Support kommt noch.

* * *

Backup-Wiederherstellung – Lizenzproblem und Fehler

Einmal musste ich die VM aufgrund eines Fehlers aus einem Backup wiederherstellen. Kein sehr abwegiges Szenario, wenn man bedenkt, dass sich in dem System allerlei geschäftskritische Dokumente befinden.

Was hat man wohl in so einem Fall nicht getan? Korrekt. Die Lizenz bei ecoDMS "abgemeldet". Natürlich passiert sowas nicht an einem Montagvormittag, wenn man den ecoDMS-Lizenzrücksetz-Support erreicht. Nein, das passiert grundsätzlich vor dem Wochenende oder vor Feiertagen.

Doch nehmen wir einfach an, die Lizenz konnte kurz danach vom ecoDMS-Lizenzrücksetz-Supportteam freigegeben werden und du startest das System, welches du aus dem Backup wiederhergestellt hast. Was machst du nun, wenn plötzlich folgender Fehler auftritt, sobald man die gespeicherten PDF-Dokumente ansehen möchte?

Fehler beim Export – Wrong file header, not MapDB file

Richtig, du machst dir Gedanken, wie du jetzt wieder an deine PDF-Dateien kommst und wie man so leichtsinnig sein konnte, sie dieser Software anzuvertrauen.

* * *

Wie komme ich wieder an meine Daten?

Basics zum Datengrab ecoDMS

Erstmal zu den Basics: Die PDF-Dateien liegen bei ecoDMS nicht – wie man vermuten könnte – weiterhin als PDF-Datei vor. Sie liegen auch nicht als binary-blob in der PostgreSQL-Datenbank und lassen sich von dort einfach exportieren. Vielmehr werden sie von ecoDMS in ein proprietäres Container-Dateiformat überführt, aus welchem man seine geschäftskritischen Daten nur mit Hilfe der Software wieder herausbekommt.

Nehmen wir nun an, du möchtest – aus gutem Grund (siehe oben) – deine Daten aus ecoDMS befreien und kannst dich aufgrund von fehlender Lizenz oder aus anderen Gründen nicht mehr im System anmelden … oder es tritt der oben genannte Fehler auf. Dann bleiben dir folgende Möglichkeiten:

Weg 1: ecoDMS Export

Hast du aus ecoDMS heraus einen Export aller Dokumente erstellt, erhält dieser alle PDF-Dateien in einem flachen Ordner und eine XML-Datei, aus welcher man sich die Klassifizierungsinformationen halb-automatisch exportieren kann. Dazu muss man nur das XML-Schema "reverse-engineeren" und schon kann's losgehen. 😅

Die Dokumente liegen im Ordner archive und die XML-Datei unter archive/export.xml.

Im Export enthalten ist außerdem ein Windows-only Client, mit dem diese Dateien auch ohne Lizenz angesehen und die Klassifizierungsinformationen angezeigt werden können. Für ein Tool, das mit "OS-Unabhängigkeit" wirbt, eine schwache Leistung.

Das funktioniert natürlich nur, solange die Software selbst auch vollständig intakt ist. Bei mir war/ist das nicht der Fall.

Weg 2: Klassifizierungsinfo aus der PostgreSQL-DB retten

An die Klassifizierungsinformationen kommt man jederzeit über die PostgreSQL-Datenbank heran.
Hierzu einfach ein Tool wie DBeaver auf der Maschine starten, auf der der ecoDMS-Server läuft.
Dort dann eine neue PostgreSQL-Verbindung mit den folgenden Parametern anlegen:

Host: localhost
Port: 5432
Datenbank: ecodms
Benutzername: ecosims
Passwort: eco

Spiel einfach selbst ein wenig darin herum, der Inhalt ist selbsterklärend.
Die Dateien selbst sind darin aber nicht zu finden.

Weg 3: Aus einem Backup

Im Backup ist ein vollständiger Datenbank-Dump enthalten (backup.sql) und auch die verschiedenen binären Datengräber. PDF-Dateien sucht man dort aber (außer in Form eines bereits früher mal getätigten Exports) ebenfalls vergeblich.

Möglicherweise funktioniert noch ein erneutes Aufsetzen des Backups auf einer andern Maschine – ich weiß es nicht.

Alles in allem sind dir durch das proprietäre Containerformat die Hände gebunden, wenn ecoDMS nicht mehr funktioniert.

Will sagen: ecoDMS futsch, PDFs futsch.

* * *

Damit aber noch nicht genug. Zur Abwechslung und bevor ich dir den absoluten Supergau schildere, noch ein paar Infos aus dem Alltag mit ecoDMS.

Sidestory: Alltag mit ecoDMS

Suchfunktion benötigt Regex-Kurs

Bis zur Version 21.12, die ich nutze, muss man erst einen Regex-Kurs besuchen, bevor man die Suchfunktion korrekt bedienen kann. Die Suche nach dem Begriff echnung findet nicht ein einziges Dokument mit dem Text "Rechnung". Erst *echnung fördert diese zu Tage.

Ich kenne bisher noch keine Bürokraft, die vorher einen Regex-Kurs belegen möchte, um eine Suche zu bedienen. Intuitiv geht anders. Oder weißt du, was eine ~ als zusätzlicher Parameter in der Suche bedeutet?

Klassifizierungsattribute für die Ewigkeit

Einmal angelegte Klassifizierungsattribute lassen sich nie wieder löschen. Wenn man also einmal ein paar Attribute zuviel angelegt hat, kann man diese in der Oberfläche zwar noch ausblenden, muss dann aber damit leben, dass diese in jeder export.xml-Datei (siehe Weg 1: ecoDMS Export) noch auftauchen – wenn auch ohne Inhalt.

Einen Hinweis auf diesen Umstand vermisse ich bis heute.

"Gelöschte" Klassifizierungsattribute in ecoDMS

Webclient ist Schrott

Der Webclient der Software ist Schrott. Das gilt auch noch für die Version 21.12, die ich bisher eingesetzt habe. Er ist langsam und völlig unübersichtlich. Hauptsache alles ist schön animiert! 🙄 Wie auch schon bei der Suche darf man erstmal einen Kurs belegen, bevor man den Webclient bedienen kann. Außerdem bietet dieser nicht alle Funktionen, die der native Client bietet. In meinen Augen ein No-Go – Web first, native client second!

Für die Inbox gibt es keine Pagination, er lädt immer alle Screenshots nach. Hat man einen Beleg klassifiziert, geht es wieder ganz oben los. Das mag bei zehn Dokumenten in der Inbox noch vernünftig funktionieren, spätestens ab 30+ wird das Scrollen richtig nervig – von der Bandbreitenverschwendung mal abgesehen.

* * *

Money first, Support second

Jetzt wird es spannend. Denn beim Support zeigt sich, wie gut ein Anbieter und seine Software wirklich sind.
Daher beginne ich diesen Teil meiner Erlebnisse mit zwei Mail-Zitaten:

Bug-Ticket an ecoDMS (13. August 2022)
Seit dem Update auf Version 21.06 kommt es von Zeit zu Zeit vor, dass Dokumente zwar vom Scaninput gelesen und aus diesem entfernt, dann aber nicht in die Inbox verschoben werden. Die Dokumente liegen "verwaist" in tiffsplit. Weil dadurch immer wieder Belege fehlen, die eig. da sein müssten, verursacht das ein großes Chaos in der Buchhaltung.

Teilweise tauchen jetzt uralte Dokumente aus dem tiffsplit-Ordner in der Inbox auf, neue Dokumente fehlen hingegen.

Beispiel:
ecodms_20220607125221318.pdf ist alt und ist plötzlich in der Inbox vorhanden, war vor zwei Wochen aber noch nicht vorhanden.
ecodms_20220801172215578.pdf ist neu und FEHLT in der Inbox.

Ich komme absolut nicht drauf, was hier die Ursache ist, und am Ende kann es nur noch ein Softwarefehler sein. Das System lief mit der alten Version 18.09 seit Jahren problemlos und plötzlich häufen sich die Probleme.

Noch ein Hinweis:
Die Angabe "Fehlgeschlagene Dokumente" in den Einstellungen ist ebenfalls wenig hilfreich, wenn man nirgends eine Information dazu findet, worauf sich das bezieht und was man in diesem Falle prüfen kann. Auch die Logs helfen nicht weiter, die FAQ ebenfalls nicht.

Ich bitte um zügige Abhilfe, die angehängten Screenshots sollten dabei hoff. behilflich sein.

Schritte zum Nachstellen des Problems:
Datei in den Scaninput schieben, Datei wird mit Glück in die Inbox übernommen und mit Pech bleibt sie im tiffsplit Ordner "hängen".

Antwort vom ecoDMS Support (15. August 2022)
Hallo Herr Süßenguth,

gerne unterstützen wir Sie beim Einsatz unserer Archivlösungen. Für eine genaue Analyse des von Ihnen beschriebenen Verhaltens würden wir gerne eine Fernwartung auf Ihrem System durchführen.
Bitte wenden Sie sich im Rahmen eines gültigen Supportpakets telefonisch bei unserem Support.
Unter https://www.ecodms.de/index.php/de/support/support-pakete finden Sie eine Übersicht unserer Angebote.
Darüber hinaus finden Sie jegliche Vertriebs-, Preis- und Produktinformationen auf der ecoDMS-Webseite.
Wir bitten um Verständnis, dass wir keine kostenlosen Service- und Supportleistungen per E-Mail/Telefon/vor Ort anbieten.

Es grüßt Sie

Nach dieser Antwort war ich – gelinde gesagt – richtig sauer. Meine Buchhaltung funktioniert seit Wochen nicht (mehr) reibungslos, weil dieses Tool macht, was es will. Ich bezahle für dieses Produkt, welches seit Jahren reibungslos funktionierte, schon regelmäßig Geld für Updates. Und wenn es dann plötzlich ohne erdenklichen Grund nicht mehr tut, soll ich ein kostenpflichtiges Support-Paket (welches übrigens ein Ablaufdatum hat 🤯) buchen, damit ecoDMS die Fehler in seiner Software behebt?

Kostenpflichtige Supportpakete mit Ablaufdatum

Den Fehler, ein Support-Paket zu buchen, welches dann ungenutzt abgelaufen ist, habe ich genau einmal gemacht:

Doch weiter im Text, denn es wird noch verrückter:

Meine Antwort an ecoDMS Support (15. August 2022)
Hallo Herr XX,

habe ich das richtig verstanden, dass ich ein kostenpflichtiges Support-Ticket bei Ihnen buchen soll, um einen Softwarefehler in Ihrer Software zu analysieren, für welche ich bereits Geld bezahlt habe?

Gruß
Christian Süßenguth

Antwort vom ecoDMS Support (15. August 2022)
Hallo Herr Süßenguth,

da das von Ihnen beschriebene Verhalten auf keinem unserer Systeme nachstellbar ist und ebenfalls von keinem unserer Kunden gemeldet wurde, müssen wir uns dies auf Ihrem System ansehen. Dies ist nur im Rahmen eines gültigen Supportpakets und dem damit einhergehenden AV-Vertrag möglich.

Es grüßt Sie

Damit war der Ofen für mich endgültig aus und ich wusste, dass meine Tage mit dieser Software gezählt sind.

Meine Antwort an ecoDMS Support (15. August 2022)
Hallo Herr XX,

vielen Dank, damit sind meine Tage mit ecoDMS wohl endgültig gezählt.
So einen miserablen Support habe ich noch nirgends erlebt – und das bei so einer businesskritischen Software. Ich hätte schon viel früher auf mein Gefühl hören sollen und diese Software nicht weiter nutzen sollen...

Was interessiert mich eine "LLG" wenn ich wegen jedem Furz wieder Geld zahlen darf? Dann lieber jährlich im Abo und vernünftiger Support.

Gruß
Christian Süßenguth

Antwort des Head of Support (16. August 2022)
Guten Tag Herr Süßenguth,

vielen Dank für Ihre ehrlichen Worte.
Ich stimme Ihrer Aussage wegen des "miserablen Supports" definitiv nicht zu, habe ich doch erst im Mai diesen Jahres aufgrund eines von Ihnen verursachten Ubuntu Upgradefehlers aus Kulanz (!) die Datenbank umgezogen, damit Sie weiterarbeiten konnten.
Mein Kollege hat Ihnen vollkommen korrekt geantwortet, dass wir das von Ihnen genannte Verhalten auf unseren Testsystemen nicht nachstellen können.
Weiterhin wurde dieses Verhalten bisher von keinem einzigen Kunden gemeldet.
Somit gehen wir erst einmal von einem lokalen Problem auf Ihrem System aus und schließen vorerst ecoDMS als Verursacher aus.

Hätte sich im Laufe einer Supportsitzung herausgestellt, dass es sich um einen Fehler in unserer Software handelt, hätten wir das gebuchte Supportpaket selbstverständlich zurückerstattet.

Ein gültiges Supportpaket (und ein damit verbundener Auftragsverarbeitungs-Vertrag) sind für eine Verarbeitung Ihrer Daten rechtlich unerlässlich und keine Idee von uns, die wir uns haben einfallen lassen.

Noch für Sie zur Info: "Fehlgeschlagene Dokumente" bezieht sich nur auf die Indizierung der Dokumente, weshalb dieser Punkt auch im Reiter "Datei Indizierung" zu finden ist.
Diese Funktion hat keine Relevanz für Dokumente in der Inbox.

Ich kann Ihnen nicht sagen, ob Sie bei anderen Softwareherstellern bessere Erfahrungen mit einem "vernünftigen Support" machen werden, wünsche Ihnen jedoch viel Erfolg bei der Auswahl.

Mit freundlichem Gruß

Die in dieser E-Mail erwähnte "Kulanz" ist ein schlechter Witz. Im Rahmen eines OS-Updates wurde von ecoDMS vergessen zu erwähnen, dass man die alte PostgreSQL-Datenbank deinstallieren / abschalten muss, damit ecoDMS bei Backups keinen Fehler wirft. Der Fehler wird in diesem Knowledgebase-Artikel erwähnt, die eigentliche Problemlösung sieht jedoch ganz anders aus. Eben jene wurde mir als E-Mail mit teilweise unvollständigen oder verkehrten Kommandos geschickt. Das war die erwähnte "Kulanz". Und selbst ausgeführt hat er die Deinstallation ebenfalls nicht, ich habe die Arbeit (und damit die Verantwortung dafür) vollständig selbst übernommen.

Doch ist der Spaß (welcher schon lange keiner mehr ist) noch nicht zu Ende:

Meine Antwort an den Head of Support (16. August 2022)

Ich stimme Ihrer Aussage wegen des "miserablen Supports" definitiv nicht zu, habe ich doch erst im Mai diesen Jahres aufgrund eines von Ihnen verursachten Ubuntu Upgradefehlers auf Kulanz (!) die Datenbank umgezogen, damit Sie weiterarbeiten konnten.

Habe ich das richtig verstanden? Ich soll diesen Upgradefehler verursacht haben, obwohl ich mich genau an ihre Upgradeschritte aus der Anleitung gehalten habe? Und mehr als eine Liste von teilweise unvollständigen Befehlen haben Sie mir nicht geschickt, siehe meine Antwortmail vom 14. Mai 2022 um 12:12. Die Arbeit habe ich selbst gemacht und ebenfalls die Verantwortung dafür übernommen.

In Ihren Upgradeschritten ist nirgendwo die Rede davon, dass irgendwelche alten Datenbanken deinstalliert werden sollen. Ihre Aussage ist eine echte Frechheit und bestärkt mich darin, ecoDMS den Rücken zuzukehren. Noch dazu, weil Ihnen dieses "Problem" mit dem Backup schon bekannt war, die Lösung allerdings meinen Fall nicht abgedeckt hat, siehe KB-Artikel. Und so ein unrealistisches Szenario ist ein Distributionsupgrade nun wirklich nicht.

schließen vorerst ecoDMS als Verursacher aus

Das dürfen Sie gerne so tun. Ich denke hier haben wir eine unterschiedliche Sichtweise auf "guten" Kundensupport. Bei mir gilt: Hilfe first, Bezahlung second. Bei einer proaktiven Lösung des Problems Ihrerseits bin ich jederzeit bereit, im Nachhinein Geld dafür zu bezahlen. Andersrum wird für mich kein Schuh daraus, denn das lässt ihre Software als "das heilige und perfekte Etwas" dastehen und mich als Kunden als den "Blöden", der sie nicht korrekt bedient / einrichtet. Wie auch immer, das Thema ist durch. ecoDMS wird bei mir und meinen Kunden keine Zukunft haben und endlich abgelöst.

Ich kann Ihnen nicht sagen, ob Sie bei anderen Softwareherstellern bessere Erfahrungen mit einem "vernünftigen Support" machen werden, wünsche Ihnen jedoch viel Erfolg bei der Auswahl.

Eine Lehre ziehe ich daraus: In meiner Firma wird es kein Closed-Source-DMS mehr geben. Mit vernünftigem Support kann die neue Software vllt. nicht aufwarten, allerdings lässt mir OpenSource-Software die vollständige Wahlfreiheit und gängelt mich nicht mit kostenpflichtigen Wartungspaketen und sonstigen Hürden wie Lizenzupgrades/Lizenzaktivierungen, die mich daran hindern, alle Teile der Software zu kontrollieren und sie "mein eigen" zu nennen.

Einen schönen Dienstag
Christian Süßenguth

Eine Antwort habe ich daraufhin nicht mehr erhalten, jedoch hat sich das eigentliche Problem weiter zugespitzt. Daher habe ich mich entschlossen, nochmal einen Anlauf zu wagen und der Firma ecoDMS erneut auf ihre Support-Mail geantwortet:

Meine erneute Antwort an den Head of Support (22. August 2022)
Sehr geehrter Herr XX,

die Probleme mit den fehlenden Belegen, die SICHER in der Inbox gelandet waren, häufen sich und es ist ein Witz, dass Sie weiter behaupten, dass das weder bei Ihnen reproduzierbar ist, noch Ihre Software damit etwas zu tun hat. Und all das noch BEVOR Sie sich von mir überhaupt irgendwelche Logdateien haben zukommen lassen.

Anbei das Errorlog Ihrer ausgiebig getesteten Software, für deren Bugfixing ich als Kunde kostenpflichtige Supportpakete buchen soll.

Meldungen wie

ERROR |Convert svg.
ERROR |Close jar file
ERROR |/opt/ecodms/workdir/tiffsplit/ecodms_20220514115108522.pdf (Datei oder Verzeichnis nicht gefunden)
ERROR |Datei konnte nicht gefunden werden: /opt/ecodms/workdir/tiffsplit/ecodms_20220514115108522.pdf
ERROR |Indexer error: Document not found!

sprechen für mich eindeutig NICHT für ein Bedienerproblem.

Ich verhalte mich seit Monaten gleich, die Belege haben sich nicht verändert und auch der Weg, wie sie in ecoDMS gelangen, hat sich nicht geändert. Das Einzige, was in der Zwischenzeit von mir gemacht wurde, waren ganz normale Updates auf dem ecoDMS Server, ggf. mal ein Neustart nach diesen und das ecoDMS Upgrade auf die nächst höhere Version.

Sie haben es weiterhin in der Hand, unser Geschäftsverhältnis sauber und erwachsen zu beenden, indem Sie den Fehler in Ihrer Software analysieren und beheben.

Gruß
Christian Süßenguth

Die Antwort, die darauf folgte, war:

Antwort von einer unbekannten Person aus dem Vertrieb (25. August 2022)
Guten Tag Herr Süßenguth,

vielen Dank zunächst für Ihre Ausführungen.

Nach Durchsicht des E-Mail-Verkehrs zwischen Ihnen und unserem Technischen Support habe ich mir einen Überblick über den aktuellen Status gemacht.
Wenn an Ihrem System durch unserer Support-Mitarbeiter Operationen durchgeführt werden sollen, wird die Existenz eines gültigen Support-Pakets zwingend vorausgesetzt.

Dass wir Sie als Kunden verloren haben, bedauern wir sehr, was aber nicht bedeutet, dass wir Sie anders behandeln als andere Kunden.
Im Hinblick auf den Verlauf der Kommunikation, resp. Ihrer Terminologie, und den bereits geleistete Kulanz-Support ist mein Angebot mehr als fair.

Das Ticket wird hiermit geschlossen.

Ihnen weiterhin alles Gute und viel Erfolg.

Und dieser Blogartikel wäre es nicht wert gewesen, wenn ich jetzt nicht den Knaller zünden könnte.

Der Knaller 💣💥

Anmerkung 01.11.2022
Nach ausführlicher Recherche (siehe Kommentare) konnte das Problem insofern eingegrenzt werden, dass wohl das Entfernen der "hängenden" Belege aus dem Ordner tiffsplit und erneute Hinzufügen in die Inbox die Ursache für die fehlenden/überschriebenen DocIDs sein dürfte. Das ändert nichts an der zentralen Aussage dieses Blogbeitrages, dass so etwas bei einem "revisionssicheren" Archiv einen Supergau darstellt.

Das technische Problem hat sich inzwischen derart zugespitzt, dass in ecoDMS nicht nur bereits klassifizierte Belege verschwunden sind, sondern die zugehörigen DocIDs wurden vom Tool sogar neu vergeben. Will heißen, es sind Dokumente aus einem revisionssicheren Archiv verschwunden und wurden mit anderen Belegen überschrieben. Der SUPERGAU! Und all das ohne irgendwelches Zutun meinerseits lediglich durch das Verschieben von Dateien aus dem Ordner tiffsplit zurück in die Inbox. Darüber hinaus wurden lediglich weiterhin neue Belege in einen Share kopiert und dann in der Inbox klassifiziert. Es wurden in der Zeit auch keinerlei (partielle) Backups zurückgespielt oder sonstige Veränderungen am System vorgenommen.

Zwischendurch tauchten immer wieder Fehlermeldungen wie diese hier auf, die für mich absolut nicht zuordenbar waren. Es wurden zwar die Dateien aus dem Ordner tiffsplit entfernt, in welchem Dateien aus der Inbox verarbeitet werden. Doch das war ja der Sinn der Übung, da die Belege nicht in der Inbox aufgetaucht sind und irgendwo "festhingen".

Information – Dieses Dokument ist nicht mehr verfügbar

Da die DocIDs als Referenz in der Buchhaltung verwendet werden, kann ich sicher sein, dass diese DocIDs zum Zeitpunkt der Erfassung bereits im Archiv existierten.

Darin, welche Dokumente fehlen und überschrieben wurden, ist keinerlei Logik erkennbar und der Fehler hat jetzt ein Niveau erreicht, an dem für mich alles zu spät ist. In den Log-Dateien finden sich keine Fehler, die irgendwie damit zusammenhängen. Damit ist die Software in meinen Augen eine tickende Zeitbombe! Finger weg!

Ich werde alle noch vorhandenen Belege aus der Software exportieren, in die neue Software paperless-ngx importieren und mir an meinen Spiegel schreiben: Nie wieder ein proprietäres Dokumentenmanagement-System!

ByeBye ecoDMS 🖕, Hallo paperless-ngx 🙋!

* * *

Ich möchte ein Open-Source DMS in meinem Unternehmen einsetzen und benötige dabei Unterstützung.

Ich unterstütze dich gerne bei der Einführung und Konfiguration von paperless-ngx oder MayanEDMS in deinem Unternehmen oder auf deinem eigenen Server. Schreib mir hierzu einfach über Kontakt, per Telegram oder unten in die Kommentare eine Nachricht.

* * *

Open-Source-Alternativen zu ecoDMS

* * *

Änderungshistorie

01.11.2022, 11:10 – Anmerkung ergänzt und Passage "Der Knaller" um weitere Informationen ergänzt
25.10.2022, 00:30 – Beitrag erstellt

* * *
Christian Süßenguth Christian Süßenguth @sweetgood

Hi, ich bin Inhaber der Firma SWEETGOOD. Mit dem andersGOOD Blog möchte ich auch dich für datensichere IT-Lösungen begeistern. So bringst du dein Unternehmen voran, ohne großen Konzernen deine wertvollen Daten zu liefern. Probiers mal anders!


Kommentarbereich

Die Kommentare sind für dich noch deaktiviert, da du dem Setzen von Cookies bisher nicht zugestimmt hast.
Klicke oben rechts auf "Ja, klar!" und lade die Seite neu, um die Kommentare anzuzeigen.

Seite neu laden

👾 Magst du Kekse?

Ich würde gerne Cookies setzen

Ist das OK für dich?