PAPERLESS_FILENAME_FORMAT vs. Speicherpfad

Hallo,

bei meinen ersten Schritten mit paperless-ngx habe ich das System mit einigen Test-Dokumenten gefüllt und nun nachträglich das PAPERLESS_FILENAME_FORMAT angepasst, anschließend docker compose down und danach up, sowie den retagger und renamer laufen lassen. Die Dokumente wurden dann korrekt in die Verzeichnisse einsortiert.

Wenn ich nun jedoch nachträglich Änderungen am Korrespondent, Dokumenttyp oder Datum durchführe scheint es, dass paperless-ngx den Pfad im Archiv nicht aktualisiert.

Ist dieses Verhalten normal? Muss ich bei der Verwendung von PAPERLESS_FILENAME_FORMAT bei Änderungen immer den retagger und renamer verwenden?

Wäre dies über einen Speicherpfad einfacher und wie kann ich bei Verwendung eines Speicherpfads sagen, dass dieser immer angewendet werden soll? Unter dem Konfigurationsparameter „Zuweisungsalgorithmus“ beim Speicherpfad konnte ich keinen Wert finden, welcher aussagt, dass der Speicherpfad immer angewendet werden soll (ein einziger Speicherpfad würde mir ausreichen).

Ergänzung: Mein Ziel wäre, dass die Dokumente in der INBOX nach der Bearbeitung durch mich (Korrektur des Titels, Datums, Korrespondent, Dokumententyp, etc.) beim Klick auf „Speichern“ direkt in den korrekten Speicherpfad (oder PAPERLESS_FILENAME_FORMAT) abgelegt werden. Ist dies möglich, oder muss ich hierzu dann immer noch den retagger bzw. renamer verwenden?

Vielen Dank,

Thomas

Hallo @thn80!
Ich weiß nicht, ob das Thema bei dir noch aktuell ist.

Ich habe es so gelöst (Danke an das Forum für die vielen guten Posts!), dass ich PAPERLESS_FILENAME_FORMAT nur noch als Fallback nutze. falls bei der Speicherpfadzuweisung etwas schief läuft.: PAPERLESS_FILENAME_FORMAT=99/

Das mit dem Fallback hat @huebi in Beispiele für die neuen storage path templates ab Version 2.13 beschrieben.

Den Titel weise ich mit einem Arbeitsablauf mit den 3 Auslösern Verarbeitung gestartet, Dokument hinzugefügt und Dokument aktualisiert ohne weitere Angaben, also immer {created_year}{created_month}{created_day}-{correspondent}-{document_type}-{owner_username}zu.

Den Speicherpfad erstelle ich auch mit einem Arbeitsablauf, der mit den 3 Auslösern Verarbeitung gestartet, Dokument hinzugefügt und Dokument aktualisiert ohne weitere Angaben, also immer den Speicherpfad zuweist. Am Ende wird der Dateiname des Dokuments mit dem zuvor generierten Titel geschrieben.

{{ owner_username }}/
{{ correspondent }}/
{{ created_year }}/
{{ title }}

Das sollte deine Frage beantworten.

Viele Grüße!

Wenn du Lust und Laune hast kannst du deinen letzten Arbeitsablauf ja nochmal überdenken. PLNGX lernt und das recht gut. Betroffen sind davon correspondent, type, tags und auch der storage path. Eigentlich sollte zumindest nach einiger Zeit der Pfas automatisch ohne Arbeitsablauf zugeordnet werden. Ich habe 9 unterschiedliche Pfade und kann mich nicht erinnern wann ich das letzte mal eine Zuordnung manuell gemacht zu haben.

Aber wenn es bei dir so passt ist auch ok, never change a running system.

Den Speicherpfad übrigens nur 99/ zu benennen ist keine gute idee. Das sollte zumindest 99/{{ original_name }} sein.

Ich bin für alle Ideen Dankbar!

Das zieht bei mir aktuell noch nicht wirklich, da ich noch immer am Testen bin. Ich habe einfach noch einige Punkte, wo ich noch nicht weiter komme und wohl auch nicht die richtigen Fragen an die Suchmaschine übergebe bzw. in der Doku verwende.

Ich habe den Abeitsablauf zur Pfadzuweisung mal deaktiviert.

Macht es Sinn, PLNGX bei den Triggern durch Zuweisung von Variablen wie z.B. exaktes Wort für Kontonummer zu unterstützen, oder wird damit die KI untergraben?

Die Zuweisung von Berechtigungen zur Bearbeitung wird die KI dann auch nicht lernen?

Dokumentation lesen hilft wie immer, schadet nicht einfach mal durchzugehen, auch wenn man am Anfang einiges nicht versteht.

Paperless-ngx comes with a new matching algorithm called Auto . This matching algorithm tries to assign tags, correspondents, document types, and storage paths to your documents based on how you have already assigned these on existing documents. It uses a neural network under the hood.

Diese 4 Metadaten würde ich erstmal PLNGX anvertrauen. Je weniger man selbst konfiguriert dest weniger Fehler können passieren. Erst wenn der Algorithmus sich immer wieder vertut würde ich mit einem Arbeitsablauf nachhelfen.

Rechte und benutzerdefinierte Felder erfordern Arbeitsabläufe. Ich weise zB beim Dokumenttyp Kontoauszug das Feld Kontonummer zu. Das funktioniert mitlerweile bei mir fehlerfrei. Den Inhalt kann man noch nicht per Arbitsablauf setzen.

Wer Altbestände scannen und importieren will sollte daher nicht alles aufeinmal in PLNGX hineinwerfen. Erstmal 10, dann korrekt zuordnen, dann nochmal zehn, wieder zuordnen. Das trainiert das neuronale Netzwerk schon recht gut. Dann den Rest hineinwerfen.

Auf jeden Fall! Das Problem ist die richtigen Wörter in die Suche einzutragen, um ein Ergebnis zu erhalten das auch passt. Ich stehe da noch am Anfang :wink:

Dann werde ich mit Auto starten und sehen, wie die KI lernt :smiley:
Wenn das nach 10, 20 Dokumenten einer Art nicht greift, werde ich den matching algorithms von Auto auf Exact ändern.

Viele Grüße!