synOCR synOCR - GUI für OCRmyPDF

[Struppix]

Aber egal, ob ich das postscript-Kommando in die erste oder die zweite Regel lege, es kommt immer der o.g. Fehler.

Das kann nicht funktionieren. Du hast einen Schreib oder Kopierfehler drin. Oben in der Fehlermeldung sind 2 // drin.

Karsten

 

[Struppix]

Hi Karsten,

ja ich nutze eine YAML-Datei, die ich im YAML-Editor zusammengebaut habe.

Hallo,

hier die Regeln für Deinen Fall. Du musst beide Regeln verwenden. Ändere den Regelnamen nach Deinen Wünschen, aber achte darauf, dass die Regeln in der Reihenfolge ausgeführt werden.

rule_1001:
    tagname: §tagname_RegEx
    tagname_RegEx: (?:)(f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s+?(19|20)\K(\d{2})
    postscript: mv "${output}" "${output%/*}/$(echo "${output##*/}" | sed 's/für\ Januar/0101/g;s/für\ Februar/0201/g;s/für\ März/0301/g;s/für\ April/0401/g;s/für\ Mai/0501/g;s/für\ Juni/0601/g;s/für\ Juli/0701/g;s/für\ August/0801/g;s/für\ September/0901/g;s/für\ Oktober/1001/g;s/für\ November/1101/g;s/für\ Dezember/1201/g')"
    condition: all
    subrules:
    - searchstring: (?:)((f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s+?(19|20\d{2}))
      searchtyp: contains
      isRegEx: true

rule_1002:
    tagname: §tagname_RegEx_Bezügemitteilung
    tagname_RegEx: (?:)((f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember))
    condition: all
    subrules:
    - searchstring: (?:)((f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s+?(19|20\d{2}))
      searchtyp: contains
      isRegEx: true

Im GUI sind die beiden Felder wie in dem Bild zu befüllen.



Wenn Du Probleme haben solltest einfach melden. Ich habe jetzt nicht alles Monate getestet, für den Fall eines Schreibfehlers,

Gruß
Karsten

 

[Yippie]

Das kann nicht funktionieren. Du hast einen Schreib oder Kopierfehler drin. Oben in der Fehlermeldung sind 2 // drin.

Karsten

Leider nein. Kein Schreibfehler bzw. selbst wenn ich den Slash aus dem Zielverzeichnis entferne, findet das Postscript Kommando die Datei nicht. Es liegt definitiv am Dateinamen im Zusammenhang mit den beiden gleichzeitig angewendeten Regeln.

 

[Behemoth09]

Ahoi Karsten,

erstmal danke für die Regeln, leider bekomme ich sie aber nicht zum Laufen. Die Einstellungen im GUI habe ich so getätigt (das heißt aber auch, dass alle meine anderen Kategorien nicht mehr korrekt nach §yocr2§mocr§docr_§tag benannt werden, sondern nur nach §tag, richtig? Also müsste ich für jede Kategorie in der YAML-Datei irgendwie das YYMMDD_tag generieren?)

Ich habe die Regeln, so wie du sie gepostet hast übernommen und lediglich den Targetfolder hinzugefügt.

Das Dokument landet vom Scanner so in der Inbox: 20240225_Scan_000064.pdf

Nach Anwendung der Regeln in der YAML liegt das Dokument so in der Outbox: 2024-02-25_19-27_20240225_Scan_000064.pdf

Das ist der entsprechende Teil der YAML:

rule_1007: tagname: §tagname_RegEx targetfolder: /volume1/docker/SynOCR/Outbox/Job/LfULG/Bezügemitteilungen tagname_RegEx: (?:)(f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s+?(19|20)\K(\d{2}) multilineregex: postscript: mv "${output}" "${output%/*}/$(echo "${output##*/}" | sed 's/für\ Januar/0101/g;s/für\ Februar/0201/g;s/für\ März/0301/g;s/für\ April/0401/g;s/für\ Mai/0501/g;s/für\ Juni/0601/g;s/für\ Juli/0701/g;s/für\ August/0801/g;s/für\ September/0901/g;s/für\ Oktober/1001/g;s/für\ November/1101/g;s/für\ Dezember/1201/g')" apprise_call: apprise_attachment: notify_lang: condition: all subrules: - searchstring: (?:)((f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s+?(19|20\d{2})) searchtyp: contains isRegEx: true multilineregex: source: casesensitive: rule_1008: tagname: §tagname_RegEx_Bezügemitteilung targetfolder: /volume1/docker/SynOCR/Outbox/Job/LfULG/Bezügemitteilungen tagname_RegEx: (?:)((f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)) multilineregex: postscript: apprise_call: apprise_attachment: notify_lang: condition: all subrules: - searchstring: (?:)((f.r)\s+?(?:Januar|Februar|M.rz|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s+?(19|20\d{2})) searchtyp: contains isRegEx: true multilineregex: source: casesensitive:

Ich stehe leider ziemlich auf dem Schlauch...

Das ist übrigens der Teil im Dokument, woraus das Datum generiert werden soll:

 

[wegomyway]

mein Nick sagt einiges aus
ich habe in der GUI die tags konvertieren lassen in eine YAML. Mit einem Texteditor dann an den Stellen wo wichtig durch "rule" ersetzt. Danach erst wurde die Datei erfolgreich importiert. Dort habe ich dann vorliegende "Fehler" korrigiert und rules neu hinzugefügt, Natürlich erstmal auf richtig einfache Art, die doch umfangreichen komplizierten lass ich erstmal außen vor. Die geänderte dann exportiert, gespeichert und die vorhandene ersetzen lassen und an gleicher Stelle auf dem DSM gespeichert (da in der GUI von synOCR der Pfad ja drinsteht, sollte da sich grundlegend nichts ändern, solange der Dateiname auch unverändert bleibt). Werde das jetzt mal mit einem Scanning probieren. Der ADS1700W lässt noch auf sich warten

 

[Struppix]

Leider nein

leider bekomme ich sie aber nicht zum Laufen

Schickt mir bitte mal ein LOG Level 2 (upload in meiner Signatur), alles andere ist Kaffeesatz lesen.

 

[wegomyway]

Wenn ich in der YAML nach "Berliner" "Pensionsverwaltung" (zwei Wörter die ohne Bindestrich etc. daherkommen) suchen lassen will, muss ich dafür erst eine "rule" und darunter eine "subrule" erstellen ? Ich will das beide Wörter im Zusammenhang gesucht und gefunden werden um das Doku dann in den korrekten Ordner ablegen zu lassen.

 

[Struppix]

muss ich dafür erst eine "rule" und darunter eine "subrule" erstellen ?

Hey wegomyway,

nein musst Du nicht. Du kannst beide Wörter in einem Suchbegriff verwenden, wenn die zu suchende Schreibweise WorteinLeerzeichenWort als Beispiel immer gleich ist.
Hilfreich hierzu ist die Funktion im GUI "Leerzeichen bereinigen", die genau das tut.

Gruß
Karsten

 

[Struppix]

Ich stehe leider ziemlich auf dem Schlauch...

Hallo Sebastian,

wie bereits vermutet verträgt die SYN die Umlaute nicht. Außerdem hatte ich Schreib- / Kopierfehler eingebaut.

Denke daran wenn diese Regeln funktionieren sollen:
- Die "Leerzeichenbereinigung" im GUI muss eingeschaltet sein
- Dein OCR Rename-Syntax im GUI muss lauten §yocr2§mocr§docr_§tag (also wieder umstellen).


Viel Spaß damit
Karsten

PS: Teste bitte unbedingt den März und versuche mal die Variante mit Umlauten zuerst:

rule_1007:
    tagname: §tagname_RegEx
    targetfolder: /volume1/docker/SynOCR/Outbox/Job/LfULG/Bezügemitteilungen
    tagname_RegEx: (?i)(für)\s*(?:Januar|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s*(19|20)\K(\d{2})
    postscript: mv "${output}" "${output%/*}/$(echo "${output##*/}" | sed 's/^.\{6\}_//g;s/für\ Januar/0101/g;s/für\ Februar/0201/g;s/für\ März/0301/g;s/für\ April/0401/g;s/für\ Mai/0501/g;s/für\ Juni/0601/g;s/für\ Juli/0701/g;s/für\ August/0801/g;s/für\ September/0901/g;s/für\ Oktober/1001/g;s/für\ November/1101/g;s/für\ Dezember/1201/g')"
    condition: all
    subrules:
    - searchstring: (?i)((für)\s*(?:Januar|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s*(19|20\d{2}))
      searchtyp: contains
      isRegEx: true

rule_1008:
    tagname: §tagname_RegEx_Bezügemitteilung
    tagname_RegEx: (?i)((für)\s*(?:Januar|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember))
    condition: all
    subrules:
    - searchstring: (?i)((für)\s*(?:Januar|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)\s*(19|20\d{2}))
      searchtyp: contains
      isRegEx: true

 

[Struppix]

Es liegt definitiv am Dateinamen im Zusammenhang mit den beiden gleichzeitig angewendeten Regeln.

Hallo,

hier der funktionierende Syntax.

postscript: mv "${output}" "${output%/*}/$(echo "${output##*/}" | sed -E 's/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{4})/\3-\2-\1/g')"

Gruß
Karsten

 

[Yippie]

Schickt mir bitte mal ein LOG Level 2 (upload in meiner Signatur), alles andere ist Kaffeesatz lesen.

Sie haben Post, leider via PM, da der Upload-Port in unserer Firewall gesperrt ist.

postscript: mv "${output}" "${output%/*}/$(echo "${output##*/}" | sed -E 's/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{4})/\3-\2-\1/g')"

Der PS-Code funktioniert so auch hier tadellos, jedoch habe ich zwei Regeln, die beide das gleiche Dokument bearbeiten um aus beiden Rename-Tags dann einen finalen Dateinamen zu erzeugen.

Möglicherweise erstellt synOCR dabei eine Zwischendatei, die das am Ende angewendete postscript-Kommando durcheinanderbringt bzw. den Zwischendateinamen in die Variable ${output} stellt statt den finalen Dateinamen samt Pfad.

 

[Struppix]

Hallo Micheal,

ich antworte hier mal das Gleiche wie im PN .... damit dass die anderen Leser auch nachvollziehen können.

Die Postscript Anweisungen werden während des Durchlaufes gesammelt, und am Ende für jede Datei nacheinander ausgeführt.
Sprich Umbenennung Datei 1, Umbenennung Datei 2 => Postscript1, => Postscript2

Dadurch macht der Postscript Befehl Deiner zweiten Regel (ohne die Sachen von Dir gesichtet zu haben) keinen Sinn, da die Datei ja schon umbenannt wurde.
Für den Fall, dass Du mehrere Befehle absetzen willst, mache Sie in einem Aufruf durch | getrennt.
Also mv .... | sed | sed oder mittels ; getrennt.

Wie gesagt, der Postscript Befehl kommt am Ende nach dem vollständigen Durchlauf und der vollständigen Umbenennung zur Anwendung, und NICHT nach jeder Regel.

@geimist bitte korrigiere mich wenn ich falsch liege.

Gruß
Karsten

 

[geimist]

Möglicherweise erstellt synOCR dabei eine Zwischendatei, die das am Ende angewendete postscript-Kommando durcheinanderbringt bzw. den Zwischendateinamen in die Variable ${output} stellt statt den finalen Dateinamen samt Pfad.

Der Mechanismus ist anders:
Jedes Postskript jeder erfüllten Regel wird in ein Array gespeichert. Zu diesem Zeitpunkt ist der Inhalt der Variablen irrelevant.
Erst im letzten Schritt wird Postskript ausgeführt. Zu diesem Zeitpunkt steht in der Variable $OUTPUT der Zieldateiname inkl. Pfad. Hier gibt es in diesem Zusammenhang eine Einschränkung: Werden mehrere Regeln erfüllt, welche unterschiedliche Zielpfade erzeugen, so nutzt das Postskript lediglich den letzten ($OUTPUT enthält ja nur den letzten und wird immer wieder überschrieben). Im Fall von lediglich einem Zielpfad ist das aber nicht von Bedeutung.
(@Struppix war schneller )

Sprich Umbenennung Datei 1, Umbenennung Datei 2 => Postscript1, => Postscript2

Wenn @Struppix hier von mehreren Dateien spricht, dann meint er damit: Wenn durch Erfüllen mehrerer Regeln verschiedene Zielordner zutreffen (also aus einer Quelldatei mehrere Zieldateien werden). Es hat aber nichts mit den Quelldateien zu tun. Hier wird eine nach der anderen (inkl. möglicherweise zutreffenden Postskript) abgearbeitet.

Man kann auch den Pfad zu einer Skriptdatei als Postskript angeben. Etwaige Variablen kann man ja als Parameter übergeben.

Aber nochmal zur Warnung:
Wenn man mit Postskripten arbeitet, sollte man wissen, was man tut. Es sind Befehle auf der Konsole mit Adminrechten!

 

[Yippie]

Ich fasse nochmals zusammen

Der von mir im postscript-Tag oder wie das auch immer heißt, angegebene Befehl, funktioniert tadellos, wenn nur eine zutreffende Regel erfolgreich erkannt und ausgeführt wird. Der dabei erzeugte und durch die postscript-Anweisung geänderte Dateiname ist auch korrekt und wie gewünscht.

Für den Fall dass zwei Regeln zutreffen, wie in meinem Fall, die ich auch so benötige da ich andernfalls nicht an die entsprechenden Inhalte der Datei rankomme um daraus zwei tagname_Regex zu erzeugen, bringen die postscript-Anweisung ins Straucheln, da offenbar jede Regel zunächst jeweils eine Datei erzeugt, die abschließend dann aber wieder zur finalen Datei kopiert(?) wird. So ganz verstanden habe ich es jedoch nicht und von daher lediglich meine Vermutung.

Jedenfalls steht dann offenbar in der Variable ${output} ein zuvor gültiger Dateiname und nicht der finale und für die PS-Anweisung erwarteten Datei.

Ich habe dies geprüft, indem ich in der zweiten PS-Anweisung den Befehl

echo ${output}

verwendet habe. Dieser zeigte dann im Log den wahren Dateinamen (samt Verzeichnis), nur dies ist nicht der finale.

Die Zielordner der beiden Regeln sind identisch, es existiert nur eine YAML-Datei.

## Erkennung des Datums des Schreibens mit anschließender Umkehrung des Datums von 23.03.2024 nach 2024-03-23 im Dateinamen
STADTWERKE002:
    tagname: §tagname_RegEx
    tagname_RegEx: (?i)(Datum\:)(?:.+)\K(([[:digit:]]{2}).([[:digit:]]{2}).)((19|20)\d{2})
    targetfolder: "Stadtwerke/"
    condition: all
    postscript: mv "${output}" "$echo '${output}' | sed -E 's/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4})/\3-\2-\1/g'"
    subrules:
    - searchstring: (?i)(Gutschrift Einspeisung Photovoltaik)
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: true 
    - searchstring: Stadtwerke
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: true       

## Erkennung des Abrechnungsjahres, bspw 2023 für den Dateinamen
STADTWERKE003:
    tagname: " Gutschrift Einspeisung PV §tagname_RegEx"
    tagname_RegEx: (?i)(vom)\s*([[:digit:]]{2}.[[:digit:]]{2}.)\K(19|20)\d{2}
    targetfolder: "Stadtwerke/"
    condition: all
    postscript: echo ${output}
    subrules:
    - searchstring: (?i)(Gutschrift Einspeisung Photovoltaik)
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: true
    - searchstring: Stadtwerke
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: true

Dies führt im Log zu folgender Ausgabe:

run user defined post scripts:
➜ postscript_STADTWERKE003_240750937
/volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023 (1).pdf
➜ postscript_STADTWERKE002_355636808
mv: cannot stat '/volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023 (1).pdf': No such file or directory
ERROR at line 2537: mv "${output}" "$echo '${output}' | sed -E 's/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4})/\3-\2-\1/g'"
ERROR at line 2537: eval "${cmd}"

Wie man sieht, ist die erste Ausgabe der Pfad, der mir in der zweiten Regel ausgegeben wird

➜ postscript_STADTWERKE003_240750937
/volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023 (3).pdf

Die zweite Ausgabe zeigt den Fehler aus dem postscript, weil die Datei so gar nicht existiert: Die finale Datei liegt in und heißt:

/volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023.pdf

Von daher meine Annahme, dass bei der Ausführung zweier passender Regeln, die postscript-Anweisung(en) ins Leere läuft.

Michael

 

[geimist]

Vorab: Ich kann nicht garantieren, dass es keinen Fehler im Code gibt, kann ihn aber derzeit nicht sehen.

Mir gefällt die Schreibweise nicht ($echo ist keine gültige Variable und soll es hier auch nicht sein - es fehlt noch die Klammer um den Befehl).
Kannst du dein Postskript bitte mal so ändern:
mv "${output}" "$(echo '${output}' | sed -E 's/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4})/\3-\2-\1/g')"

 

[Struppix]

Hallo Michael,

ich muss das nochmal anschauen, aber ich verstehe nicht, warum Du das so machst? Kannst Du mal bitte mit PM das anhand der Suchbegriffe erklären.

Noch weniger verstehe ich warum Du beide Dateien in einen / oder auch gleichen Zielordner verschiebst.
Lass doch die Regeln die Umbenennung in einem Dateinamen machen, die ja je nach Zutreffens die Benennung vornimmt, und dann mit einem Postscript die abschließende Verschiebung der Reihenfolge.

Warum so kompliziert?

Karsten

Edit: Wenn die erste Umbenennung 23.02.2024 Gutschrift Einspeisung PV 2023 ist und die Zweite 23.02.2024 Gutschrift Einspeisung vom xxxxx, dann kannst Du doch damit arbeiten mit PS. Dabei ist es unerheblich ob PS etwas zum umbenennen findet oder nicht.
Der Name ist aber von der Logik immer gleich, oder ?

 

[wegomyway]

gibt es eine Grenze von "rules" die ich in der YAML-Datei mit Editor erstellen kann ? Aktuell hab ich 46
Meine hier im Thread gelesen zu haben das ein User was von 100 erstellten rules geschrieben hat, aber nicht ob dass das Ende der Fahnenstange ist.

 

[Struppix]

Hallo wegomyway,

theoretisch sollte es keine Grenze bei der Anzahl der Regeln geben, zumindest kenne ich keine. Man darf nur nicht vergessen, dass umso mehr Regeln vorhanden sind auch der Durchlauf immer länger dauert, und die Auslastung des Systems steigt.
Ich verwende mehr als 300 Rules und fast 800 Subrules in verschiedenen Profilen. Hier ein älteres Bild meiner Haupt YAML-Datei.

Gruß Karsten

 

[Struppix]

gibt es eine Grenze von "rules" die ich in der YAML-Datei mit Editor erstellen kann ?

Hallo wegomyway,

sehe gerade, Deine Frage bezieht sich auf den Editor.
Im Editor habe ich damals bei der Erstellung eine willkürliche Grenze von 4999 Zeilen vorgesehen. Das erschien mir als ausreichend. Falls jemand mal an diese Grenze stoßen sollte einfach melden.

Gruß
Karsten

 

[Yippie]

Noch weniger verstehe ich warum Du beide Dateien in einen / oder auch gleichen Zielordner verschiebst.
Lass doch die Regeln die Umbenennung in einem Dateinamen machen, die ja je nach Zutreffens die Benennung vornimmt, und dann mit einem Postscript die abschließende Verschiebung der Reihenfolge.

@geimist , @Struppix : Vielen Dank an euch beide, dass ihr hier so fleißig mitlest und Empfehlungen abgebt. Ich versuch nochmals meinen Plan beim aktuellen Problem zu beschreiben.

Ich habe eine gescannte Datei der lokalen Stadtwerke, das finale Dokument soll vom Namen her, das Abrechnungsjahr (2023) haben und zudem das Datum des Schreibens (23.02.2024).

Damit sollte sich folgender, finaler Dateiname ergeben: 2024-02-23 Gutschrift Einspeisung PV 2023.pdf

Hier die Quellen der beiden Datum:

Herausforderung ist:

1. Die Position des Abrechnungsjahr im Schreiben, da Teil eines Datums
2. Die Position des Schreibens nach den beiden Datum am Anfang der o.a. Zeile
3. Das Umsetzens des Datums des Schreibens von 23.02.2024 nach 2024-02-23

Da synOCR das erste Datum verwendet (ich kann die GUI-Option wegen anderer Regeln nicht einstellen), wurde mir gesagt, dass ich mein Vorhaben mit zwei Regeln für ein und dieselbe PDF-Datei umsetzen kann.

Dies funktioniert auch wie gewünscht, allerdings ohne Umsetzung von Punkt 3 oben.

## Erkennung des Datums des Schreibens mit anschließender Umkehrung des Datums von 23.03.2024 nach 2024-03-23
STADTWERKE002:
    tagname: §tagname_RegEx
    tagname_RegEx: (?i)(Datum\:)(?:.+)\K(([[:digit:]]{2}).([[:digit:]]{2}).)((19|20)\d{2})
    targetfolder: "Stadtwerke/"
    condition: all
    postscript: mv "${output}" "$(echo '${output}' | sed -E 's/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4})/\3-\2-\1/g')"
    subrules:
    - searchstring: (?i)(Gutschrift Einspeisung Photovoltaik)
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: true
    - searchstring: Stadtwerke
      searchtyp: contains
      isRegEx: false
      source: content
      casesensitive: true     

## Erkennung des Abrechnungsjahres, bspw 2023 für den Dateinamen
STADTWERKE003:
    tagname: " Gutschrift Einspeisung PV §tagname_RegEx"
    tagname_RegEx: (?i)(vom)\s*([[:digit:]]{2}.[[:digit:]]{2}.)\K(19|20)\d{2}
    targetfolder: "Stadtwerke/"
    condition: all
    subrules:
    - searchstring: (?i)(Gutschrift Einspeisung Photovoltaik)
      searchtyp: contains
      isRegEx: true
      source: content
      casesensitive: true
    - searchstring: Stadtwerke
      searchtyp: contains
      isRegEx: false
      source: content
      casesensitive: true

Somit erhalte ich erstmal den Dateinamen 23.02.2024 Gutschrift Einspeisung PV 2023.pdf
Um den Punkt 3 zu realisieren, wurde mir empfohlen, eine postscript-Anweisung zu verwenden, die ich in der Regel STADTWERKE002 umgesetzt habe.

Vorneweg, wenn diese Regel alleine in der YAML-Datei steht, dann wird der Dateiname 23.02.2024.pdf nach 2024-02-23.pdf umgesetzt.

Wenn ich beide Regel anwenden lasse, so kommt es zu dem Fehler:

                ➜ move to category directory
                  tag directory "Stadtwerke/" exists? ➜  OK [subfolder target dir]
                  target:   /volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023.pdf
                  do not set a hard link when copying across volumes

  -----------------------------------------------------------------------------------
  | adjusts the attributes of the target file:                                      |
  -----------------------------------------------------------------------------------

                ➜ Adapt file date (Source: Source file)
                ➜ File permissions target file:
                  -rwxrwxrwx+ 1 synOCR synOCR 867185 Feb 25 09:48 /volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023.pdf

                  tag directory "Stadtwerke/" exists? ➜  OK [subfolder target dir]
                ➜ File name already exists! Add counter (1)

                  target:   /volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023 (1).pdf
                  same file has already been copied into target folder (Stadtwerke/) and is skipped!


  -----------------------------------------------------------------------------------
  | final tasks:                                                                    |
  -----------------------------------------------------------------------------------

                  INFO: Notify for apprise not defined ...

run user defined post scripts:
 ➜ postscript_STADTWERKE002_382717120
mv: cannot stat '/volume1/Scanner/Ausgabe/Stadtwerke/23.02.2024 Gutschrift Einspeisung PV 2023 (1).pdf': No such file or directory
ERROR at line 2537: mv "${output}" "$(echo '${output}' | sed -E 's/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4})/\3-\2-\1/g')"
ERROR at line 2537: eval "${cmd}"

Wie bereits erwähnt, erhält die postscript-Anweisung bzw. die Variable $(output) nicht den finalen Dateinamen, sondern irgendeinen temporäeren Dateinamen mit Endung (1).pdf, dessen Ursache in der Anwendung zweier Regeln zu sein scheint, siehe Ausschnitt aus dem Log oben.

Fazit:

• Ich habe genau eine Datei, die es zu bearbeiten gibt
• Ich habe genau ein Zielverzeichnis, auf welches ich keinen Einfluss habe
• Die finale Datei ist exakt einmal vorhanden
• Bei Anwendung einer Regel funktioniert das postscript-Kommando perfekt
• Bei Anwendung zweier Regeln für ein und dieselbe Datei, wird eine Zwischendatei erzeugt, das postscript-Kommando bekommt ausschließlich den Pfad und die Datei der Zwischendatei mitgeteilt und nicht der finalen PDF.

Ih hoffe ich konnte damit ein wenig zur Entwirrung meiner bisherigen Fragen und Details beitragen und hoffe ebenso, dass es eine Lösung für das postscript-Problem gibt.

Möglicherweise, habe ich jedoch nicht getestet, muss ich das postscript aus der ersten Regel zusätzlich in die zweite Regel kopieren um dann eine Umbenennung der finalen Datei zu erhalten!?

Danke,
Michael