Fehler saß vor dem Rechner...
Meines Wissens gibt es nur gedankliche Konstrukte in dieser Richtung.
In der Regel liegt es an einem unvollständig konfigurierten 2. Profil. Das bitte mal checken.
Es ist ein "interner Benutzer", der in der normalen Liste meist nicht aufgeführt wird.
Da habe ich gerade keine Ahnung und müsste mich erst damit auseinandersetzen. Ich denke, für viele User ist die aktuelle Variante einfacher, weil man so ein abgegrenztes Logfile für eine einzelne Datei zum debuggen bereitstellen kann. Aber es ist ja nichts ein Stein gemeißelt.
Behelfe mir derzeit auch mit 2 Regeln, um das Problem zu lösen.
Kundennummer: 1234567
Rechnungsnummer: 1234567
Transaktionsnummer: 1234567Kundennummer:
1234567
Rechnungsnummer:
1234567
Transaktionsnummer:
1234567===> Tabellensuche
Suche abgrenzen auf letzte Zahl der ersten "Spalte" der nächsten Zeile
(?|(Beleg-Nr.).+)?\n\K(?:\d*)
Suche abgrenzen auf letzte Zahl der zweiten "Spalte" der nächsten Zeile (hier Datum)
(?|(Datum).+)?\n\d*\s*\K(?:\d{2}.\d{2}.(19|20\d{2}))
Suche dritte Spalte
(?|(Kd-Nr.).+)?\n\d*\s*\d{2}.\d{2}.(19|20\d{2})\s*\K(?:\d*)
Beispieltext:
Beleg-Nr. Datum Kd-Nr. 1235846 ldhlö
20230059 01.02.2023 10467 bla bla
Es gibt einen "Editor", der manchmal für eine Idee hilfreich ist. Bei eindeutigen Strings funktioniert das recht gut. Der syntax ist aber oft recht aufwendig.
===============================================================================================
Suche Monat und Jahr (bsp. für Rechnung)
\S*((?:Rechnung|rechnung)\S{0,}\s{0,}?\S{0,}?\s{0,}?)
(?<=echnung|ECHNUNG|uszug|USZUG|bersicht|BERSICHT).+\K(?:Januar|JANUAR|Februar|FEBRUAR|März|MÄRZ|April|APRIL|Mai|MAI|Juni|JUNI|Juli|JULI|August|AUGUST|September|SEPTEMBER|Oktober|OKTOBER|November|NOVEMBER|Dezember|DEZEMBER)
(?<=echnung|ECHNUNG|uszug|USZUG|bersicht|BERSICHT).+\K((?:19|20)\d{2})
Suchstring ===> Rechnung für Januar 2021
Ausgabe ===> Bspw. Rechnung Januar 2021
===============================================================================================Solche Bedingungen lassen sich derzeit noch nicht abbilden.
Aktuell nur so, indem du die Regel duplizierst.
synOCR sucht ja auf Basis vonWie gesagt im Tester ist alles ok. Stehe ich auf dem Schlauch?! Egal welche Variante ich getestet habe, es ist ihm egal
grep. Anfangs war es z.B. auch so, dass so Sachen wie lookbehind nicht gefunden wurden. Der Schalter -P schaffte Abhilfe. Vielleicht müssen wir grep noch etwas auf die Sprünge helfen. In meinem Test auf der Kommandozeile konnte ich auch keinen Fund replizieren.grep -P "(?|(Beleg-Nr.).+)?\n\K(?:\d*)" "Regextest.txt"-z. Hintergrund ist, dass grep ja prinzipiell nur zeilenbasiert arbeitet. Der Schalter -z weißt grep an, die Suchdatei als einen einzigen String zu verarbeiten. Damit konnte ich deine Regex auf der Shell verarbeiten. Den Schalter muss ich aber erst einmal einbauen.
multilineregex: true kann jetzt in einer Subrule gesetzt werden-z für grep, um über mehrere Zeilen hinweg suchen zu könnenJetzt muss ich mich outen. Nicht nur das ich die Anleitung nicht gelesen habe, wo das mit dem 'grep' sicher steht
, wie aktualisiere ich die Version ohne alle Profile und Einstellungen zu verlieren.Vielen herzlichen Dank für die schnelle Antwort!
Das steht im Log.
sqlite3 "/usr/syno/synoman/webman/3rdparty/synOCR/etc/synOCR.sqlite" "
UPDATE system SET value_1='0' WHERE key='global_pagecount';
UPDATE system SET value_1='0' WHERE key='global_ocrcount';
UPDATE system SET value_1='$(date +%Y-%m-%d)' WHERE key='count_start_date';
UPDATE config SET pagecount='0' WHERE profile='Versicherungen';
UPDATE config SET ocrcount='0' WHERE profile='Versicherungen';"
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
