Hallo zusammen,
DT3 erfreut mich heute mit einem neuen Feature, indem es reinkommende PDF-Dokumente nicht mehr mit einem OCR beglückt.
Dies lief bis gestern völlig problemlos, und tritt heute überraschend auf.
An den Settings wurde nichts verändert.
Vielleicht gibt es dafür ja eine Erklärung?
Grüße
Ulli
Ticket #104305
Wie kommen die Dokumente denn rein? OCR wird nur auf Scans, sofern die Option aktiviert ist, automatisch angewendet.
Hinweis: Sie haben Ihr Ticket heute eröffnet und ich habe bereits darauf geantwortet.
(Übersetzt mit https://deepl.com)
Naja, deswegen schrieb ich ja im Titel “Import von Scans”!
Die werden per ScanSnap gescannt, und dann über den Importordner in DT3 eingefügt.
Funktionierte sehr lange prima, aber leider seit heute nicht mehr…
Sorry, aber 12.3.1 wird zumindest mir hier in Deutschland bisher nicht angeboten. Kommt vielleicht noch im laufe des Abends?
Ich sehe hier aber ehrlich gesagt keinen Zusammenhang!
Wieso sollte es plötzlich nicht mehr funktionieren, nachdem es das lange gut gemacht hatte, nur weil macOS geupdated wird, DT3 aber eben nicht geupdated wurde?
Ich würde dies verstehen, wenn es für DT3 ein Update gab, aber das ist hier noch auf 3.8.3, wenn also beide Softwareversionen nicht geändert wurden, es bisher gut funktioniert hat, und vor allem, nach allem was man im Internet zu 12.3.1 finden kann, dieses Update auch zumindest offensichtlich nichts (es geht hier weder um Bluetooth, noch um einen per USB-C angeschlossenen zweiten Monitor an einem Mac mini (2018)) mit dem hiesigen Problem zu tun haben soll, erschließt sich mir nicht, warum das Problem verschwinden sollte, wenn das Update durchgeführt wurde?
Normalerweise ist es genau anders herum…
Ach ja, und ich gehöre verrückterweise zu denjenigen, die ein Update immer innerhalb weniger Stunden nach der Veröffentlichung einspielen.
Der Hinweis, ich sollte mein System up to date halten, ist daher irgendwie unnötig…
Zum einen, weil man sich über das Betriebssystem und unsere Neuerscheinungen auf dem Laufenden halten sollte, was viele nicht tun.
Zum anderen erzwingen Updates auch einen Neustart des Rechners. Das ist etwas anderes, was die Leute oft vernachlässigen: einen Rechner gelegentlich neu zu starten.
Ein Neustart ist nicht nur eine faule Support-Antwort. Er beseitigt oder lindert oft Probleme auf einem Gerät.
Was ist in den Einstellungen Ihres ScanSnap-Profils festgelegt? Ein Bildschirmfoto könnte hilfreich sein.
Ich habe den Neustart alle drei Tage in meiner GTD-Taskliste drinnen.
Und natürlich, vor dem eröffnen des Tickets, extra einen gemacht, um diese Probleme abzufangen.
Ich mache das auch nicht erst seit gestern.
Auch ein nun durchgeführtes Update auf 12.3.1 hat, wie zu erwarten, nichts gebracht. Das Problem dass die eingehenden Scans, anders als in den letzten Tagen, nicht mehr mit OCR behandelt werden, ist unverändert vorhanden.
Das ScanSnap-Profil sieht hierfür so aus:
Die Hazel-Rule, die den Scan dann in den Eingang von DT3 verschiebt, sieht so aus:
Kurz bevor ich das Problem das erste Mal festgestellt habe, habe ich die folgende Regel angelegt:
Das Problem ist aber vorhanden, unabhängig davon, ob die Regel aktiviert ist, oder nicht.
Eine automatische OCR wird m.W. nur auf direkt von der Scannersoftware an DT übermittelte Dateien angewandt. Dein Vorgehen, nämlich die PDF über einen Ordner mittels Hazel an DT, dürfte den Mechanismus nicht auslösen. Hast du bisher mittels einer intelligenten Regel (z.B. Art ist PDF, Wortzahl ist 0) OCR ausgelöst? Wenn ja, poste bitte die Regel; in welcher Position ist sie in der Regelabfolge?
Warum schickst du die Scans nicht direkt aus SnapScan an DT?
Ich glaube ich schrieb es schon mal, ich arbeite mit dieser Regel seit einigen Tagen. Bates Nummer wird nicht immer eingefügt - #9 by Ulli
Seitdem habe ich geschätzt über 100 Scans so durchgeführt, und die wurden alle beim Eingang mit OCR versehen, und dann in DT3 weiterverarbeitet. Völlig problemlos, bis ich heute leider feststellen musste, dass es nun plötzlich nicht mehr geht.
Und ich gehe diesen Weg, um die Datei mit einem Tag versehen zu können, wie man auf dem Screenshot der Hazelrule sehen kann.
Damit kann ich dann in DT3 automatisch die Bates-Stempelung auslösen, ohne (bisher) über Probleme mit “nicht eindeutigen” Dateinamen o.ä. zu stolpern.
Ich habe jetzt in DT3 eine neue Regel erstellt, um das OCR auszulösen, wenn ein PDF importiert wird, welches “0 Buchstaben” enthält.
Diese Regel funktioniert jetzt auch mit meinem Dokument.
Leider löst diese Regel aber nicht den Trigger “nach OCR” in einer anderen Regel aus.
Wenn ich das OCR in DT3 manuell ausführe, also ohne Regel, dann löst die Regel, die den Trigger “nach OCR” hat, zuverlässig aus.
Wie ist dies zu erklären?
Korrekt, per se lösen Regeln keine anderen Regeln aus; damit sollen Regelschleifen vermieden werden. Eine Regel kann eine ausgewählte Folgeregel auslösen.
Interessant, das ist nicht das Verhalten, das ich erwartet hätte.
Das ist korrekt.
Wenn tatsächlich DT3 keinen automatisches OCR durchführt, nachdem ein PDF ohne OCR über die Inbox hinzugefügt wurde, dann stellen sich hieraus für mich zwei Fragen:
Ich glaube wir reden hier aneinander vorbei.
Wenn ich eine Regel A habe, die ein OCR durchführt. Und eine Regel B habe, die sich triggern soll, wenn ein OCR durchgeführt wurde (“Nach OCR”), dann erwarte ich als Nutzer, dass genau dies auch geschieht.
Es muss für Regel B völlig egal sein, was das OCR ausgelöst hat, und ich kann in der Dokumentation dazu auch keinen Hinweis finden, dass es tatsächlich nicht egal wäre.
Hier kann auch keine “Regelschleife” entstehen, da Regel A verständlicherweise nicht getriggert werden kann, wenn Regel B durchgelaufen ist, da die Datei dann ja ihre OCR-Schicht bereits hat.
Regelschleifen entstehen dadurch, dass die Eingangsregel einer Regel A, der Ausgangskondition einer Regel B entspricht.
Ein einfaches Beispiel ist meine Regel, die ich geschrieben habe, um ein Tag zu einer Datei hinzuzufügen. Hier war es notwendig, dass die Regel erst einmal prüft, ob das Tag nicht schon vorhanden ist, bevor es das Tag setzt. Ohne diese Eingangsprüfung würde diese Regel tatsächlich in einer Schleife laufen, aber auch hier unabhängig von anderen Regeln.
Das stimmt in dieser Absolutheit nicht. Es gibt z.B. handgeschriebene Rechnungen auf Papier. Wenn ich die scanne, bekomme ich ein PDF. Auf dem allerdings OCR zu betreiben, ist reichlich sinnfrei. Trotzdem ist das ein Dokument für meine Buchhaltung, und ich kann Herkunft, Datum, Zweck und Betrag ohne Schwierigkeiten in Metadaten unterbringen. Auch danach kann ich sinnvoll suchen. Ähnlich sieht es übrigens mit vielen Belegen auf Thermopaier aus: Man muss die sofort kopieren (aka scannen), aber der Scan lässt sich häufig nicht mit OCR brauchbar behandeln.
Nicht jeder bekommt PDFs, die nur aus gedrucktem Text bestehen.
Kannste erwarten, tut‘s aber nicht, weil Regeln keine Regeln auslösen. Du kannst aus einer Regel heraus eine weitere ausgewählte Regel auslösen; mit einem Skript kannst du auch alle Regeln nochmal auslösen, wobei das erst ab 3.8.4 (wieder) funktionieren wird. Dass dabei keine Schleifen entstehen muss der Nutzer selbst prüfen, wenngleich bestimmte Schutzmechanismen eingebaut sind/sein werden.
Toll, Du hast Ausnahmen zu meiner allgemein formulierten Feststellung gefunden!
Herzlichen Glückwunsch!!
Dennoch kannst Du mit den von Dir genannten Dokumenten in DT3 eben nicht viel mehr anfangen, als sie nur zu speichern. Dafür benötigt man DT3 aber nicht, das macht der Finder im Zweifel genauso, zumal Du sie, wenn Du damit tatsächlich Buchhaltung betreiben willst, ohnehin in spezielleren Programmen speichern müsstest, da DT3 immer noch nicht den gesetzlichen Anforderungen hierfür entspricht.
Es geht doch hier gar nicht darum, dass eine Regel eine andere auslösen soll, wobei aber eben genau dies doch ausdrücklich möglich ist, wenn ich die zweite Regel in die erste reinschreibe!
Es geht darum, dass die zweite Regel nicht auslöst, weil das OCR von einer Regel angestoßen wurde!
Und das ist ein Fehler, der nicht sein kann!!
Es muss der zweiten Regel völlig egal sein, was das OCR ausgelöst hat. Wenn hier eine versteckte Sperre eingebaut ist, die verhindert dass eine Regel den Trigger “nach OCR” auslöst, nur weil dieser vorher ebenfalls von einer Regel ausgelöst wurde, dann ist dies nicht nur ein erheblicher Fehler in der Programmierung, sondern müsste auch entsprechend dokumentiert sein. Dies ist es aber nicht, bzw. ich habe dies bisher nicht gefunden.
Dann müssten aber auch alle anderen, vermutlich dann bestehenden, versteckten Regelfunktionen etc. irgendwo dokumentiert sein.
Wo steht das alles!?
Du, ich nenne dir bloß die Tatsachen. Die Aktionen einer Regel lösen keine weitere Regel aus.
Ganz grundsätzlich: ich bin hier um zu helfen, nicht um zu streiten. Ich biete anderen hier meine Freizeit an; ich glaube daran, dass wenn jeder Input in eine Community bringt, am Ende auch jeder was davon hat. Heißt: ich weiß viel über DT, lerne aber auch hier durch Interaktion mit anderen viel dazu. Ich habe bislang aber nicht das Gefühl gehabt, dass ich dir in unseren Interaktionen helfen konnte; ich selbst habe sie vielmehr als frustrierend wahrgenommen. Selbst mitnehmen konnte ich nichts. In diesem Sinne wünsche ich dir, dass du im Laufe der Zeit deine Zufriedenheit mit DT steigern kannst, oder aber Software findest, die deinen Vorstellungen entspricht.
