Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- elo:paperless_ngx [2026/01/22 08:09] – 37.24.22.134
+++ elo:paperless_ngx [2026/01/24 20:04] (aktuell) – [Pricing für einen User On-Premise] 84.20.184.166
@@ Zeile 7: / Zeile 7: @@
 NGX ist hier eine wilde Mischung. Ein bisschen Java hier (Apache Tika, Formaterkennung), ein bisschen Go (Gotenberg) da und als Hauptdarsteller Python3 als Frontend. Als Datenbankbackend dienen entweder PostGres, MariaDB oder MySQL, alles freie Datenbanken, die hier gut und gerne auch als Pakete bei namhaften NAS-Herstellern auch für den Bare-Metal Weg zur Verfügung stehen (u.a. bei Synology und UGreen). Summa sumarum muss man hier aber sagen, dass man wohl zu Beginn mit einem Footprint mit 4GB RAM sehr gut klar kommt, 8 GB sind dann schon gar üppig für Startsysteme. Da kommt ELO nicht mit, ELOprofessional verleibt sich dann schon bei V23-Systemn gut und gerne brutto 12-14 GB ein, V25 ist noch etwas heftiger unterwegs mit 17GB+. Kingston und Co. freuen sich.
+===== Pricing für einen User On-Premise =====
+Da Paperless NGX ja nicht wirklich etwas kostet, entfallen hier die initialen Lizenzkosten. Bei ELO ist hier die Notwendigkeit zumindest einen User zu lizenzieren. Darunter gibt es das somit nichts. Hardwaretechnisch nehmen wir bei Paperless einfach einmal eine aktuelle Synology oder UGreen an mit etwa 800 EUR Anschaffungskosten. Bei ELO einmal einen 32 GB Server mit 2.000 EUR Anschaffungskosten oder zwei Cloud Server mit 32 EUR im Monat sowie einer Windows Lizenz mit 800 EUR Anschaffungskosten.
+Somit ergeben sich folgende Kosten in der Übersicht:
+| Produkt | Hardwarekosten | Installationskosten (à 100 EUR) | Lizenzkosten (User) | Gesamt |
+| Paperless NGX | 800 | 200 | 0 | 1.100 |
+| ELOprofessional | 2.000 | 500 | 950 (190 Wartung) | 3.640 |
+| EcoDMS One | 2.000 | 300 | 750 (3 User, Wartung 150) | 3.200 |
 ===== Gespeicherte Ansichten =====
-Wo ELO mit seinen dyn. Registern punktet und auch mit seinen Archivansichten, kann hier NGX durchaus mit seinen Ansichten gleichziehen bzw. überflügelt ELO sogar geringfügig. Spalten können aus/eingeblendet, sortiert werden. Das kann ELO bis heute in Version 25 nicht. Filterung ist hier aufgrund von Zusatzfeldern möglich (Bereichswerte). Vieles was bei ELO mittels Suche+dyn.Register möglich ist, ist hier mit nur wenigen Klicks erreich/aktualisierbar. Wehrmutstropfen: Ansichten sind bisher nur auf Userebene speicherbar, alle anderen User dürfen wieder von Vorne anfangen. Hier ist dann direkter Datenbankeinsatz vonnöten.
+Wo ELO mit seinen dyn. Registern punktet und auch mit seinen Archivansichten, kann hier NGX durchaus mit seinen Ansichten gleichziehen bzw. überflügelt ELO sogar geringfügig. Spalten können aus/eingeblendet, sortiert werden. Das kann ELO bis heute in Version 25 nicht, bzw. ist das eher ein Generation 2 / administratives Thema über den Workspace. Filterung ist bei NGX hier aufgrund von Zusatzfeldern möglich (Bereichswerte). Vieles was bei ELO mittels Suche+dyn.Register möglich ist, ist hier mit nur wenigen Klicks erreich/aktualisierbar, wohingegen bei ELO zuerst einmal eine Suche abgesetzt werden muss, um ein dyn. Register ableiten zu können. Will man dieses aktualisieren, dann ist wiederum die Suche von Beginn an anzubahnen, bzw. wenn man mitgedacht hat, aus einer Vorlage zu laden. Wehrmutstropfen: Ansichten sind bisher nur auf Userebene speicherbar, alle anderen User dürfen wieder von Vorne anfangen. Hier ist dann direkter Datenbankeinsatz vonnöten. Und wo ELO natürlich wiederum Nachteile hat, hat es dann auch wiederum den Vorteil, dass hier die Registerdefinition in JSON Notation geführt wird oder in SQL Notation, diese kann wiederum einfacherweise per Programmierung angepasst und wiederholt werden.
 ===== Versionskontrolle =====
@@ Zeile 15: / Zeile 25: @@
 Zzt. verfügt Paperless NGX über keine echte Versionskontrolle. Sprich Dokumente werden hochgeladen und das war es dann. Auch können Dokumente über die WebUI verändert werden (PDFs mit PDF Editor, der hier eine neue Sortierung der Seiten zulässt), das wird dann zwar im Verlauf protokolliert allerdings wird dann hier wahrscheinlich zwar das Original aufbehalten (zu prüfen). Eine revisionssichere Ablage ist das dann gesamt gesehen eher nicht so wirklich, teilweise lässt sich das aber durch das Berechtigungssystem herstellen (keine Änderungsrechte für "normale" Benutzergruppen, dann entfällt hier auch die Möglichkeit zum Löschen).
+Darüber hinaus muss man hier im Hinterkopf behalten, dass NGX auch keine Möglichkeit vorsieht Dokumente zu "aktualisieren". Um ein Dokument zu aktualisieren bleibt hier also über die UI nur der Weg "Löschen" + "Neu hochladen" des neuen Dokuments, ggf. danach wieder neu taggen, verschlagworten. Über das FileSystem kann man ggf. auch die Datei direkt ersetzen (numerische ID). Über die Datenbank könnte man ggf. auch den ID-Wert des alten Dokuments hochdrehen, ein neues Dokument platzieren und somit das alte Dokumente beleassen.
 ===== Installation =====
 Die Installation ist relativ einfach über Docker-Container und dauert in etwa 20-30 Minuten. Mit Debian-Installation ist das System also binnen einer Stunde einmal grundinstalliert und danach einsatzbereit. Weitere Anpassungen für die API Verwendung sind hier keine erforderlich. Ggf. müssen hier einmal die Dokumenttypen hinterlegt werden, Tags sowie die Korrespondenten. Es sind darüber hinaus Ansichten anlegbar (bspw. alle Dokumente vom Typ Eingangsrechnung über 10.000 EUR).
+===== Metadatenmodell =====
+Paperless NGX befindet sich hier im Grunde auf Ebene von OpenText von vor 10 Jahren. Typisierte Erweiterungsfelder sind hier für die Dokumente speicherbar, von einer Checkbox über ein Datumsfeld bis hin zu einem kurzen (150 Zeichen) oder langen Text (?) ist hier alles mit dabei. Felder können hier immer nur einen Wert fassen, nicht beliebig viele. Relationale Objekt-Typen oder Business-Objekte gibt es hier keine. Somit ist bei Datenübernahmen von ELOoffice oder ELOprofessional oder ELOenterprise ggf. eine Zäsur zu machen. Wenn man neue Projekte startet, dann sollte man dies in die Überlegungen mit einbeziehen. Rechnungsworkflows mit bspw. mehreren Sachkonten oder Kostenstellen (Kontierung), können hier nativ wohl nur dahingehend gestaltet werden, wenn hier mehrere Felder angelegt werden, eine echte tabellarische Verspeicherung von Indexwerten geht hier also nicht.
 ===== Formate & Renditioning =====