OCR auf den Stand der Technik bringen

[#1]

Als Digitalisierungsbeauftragter möchte ich, dass DATEV eine Verbesserung der OCR vornimmt. Den Zweck muss ich hoffentlich nicht beschreiben. 😎

[#2]

Gibt es evtl. auch eine Möglichkeit, der OCR etwas beizubringen bzw. Felder auszuschließen (z.B. Kost, da ja immer je nachdem entschieden wird, auf welche Kostenstelle gebucht wird - steht das Feld aber schon da, weil man Kost ein paar mal z.B. auf die 1 gebucht hat, erscheint dann immer wieder die 1)

[#3]

@Bamsig: Leider nein die OCR ist in den 00er Jahren stehen geblieben ist doof und bleibt doof.

Was die Trefferquote etwas verbessert ist die Pflege der Stammdaten. --> Die IBAN ist im Bildteil des PDF? (geht aber mittlerweile wohl auch auszulesen) --> Wenn die Lieferantennummer erkannt wird zieht er die IBAN zum Erstellen der Überweisung aus den Stammdaten.

Mit dem Auslesen des Bildteils ist ein Schritt in die richtige Richtung gemacht worden. Nur müsste die Logik weiter verbessert werden. Das Inviocenumber nicht als Rechnungsnummer erkannt wird ist ein Unding.

[#4]

Einen zu oft genannten Wunsch, der bisher nicht umgesetzt wurde möchte ich hier noch dazu geben:

Auswahl des Suchfeldes auf einem Beleg --> z. B. wenn die OCR immer am falschen Fleck den Rechnungsbetrag sucht, Auswahl des Rechnungsbetrages auf der jeweiligen Rechnung per Klick in den Bereich bzw. wenn man den Bereich markiert in dem gesucht (und gefunden) werden soll.

Einige essentielle Funktionen, die hier in der OCR fehlen funktionieren bei anderen Anbietern schon seit über 10 Jahren!

[#5]

Warum sollte DATEV in Steinzeittechnik Zeit investieren? Mit den Nutzungsgebühren wurde eine neue RZ Anwendung etwickelt und nunmehr bereitgestellt:

https://www.datev-community.de/t5/Technisches-zu-Software/DATEV-Automatisierungsservice-Rechnungen-ab-Morgen-verf%C3%BCgbar/m-p/213967#M17772 

Das soll nun die Zukunft sein, mehr zahlen für die gleiche Leistung.

[#6]

Sie Fragen?

Anstatt ein halbgares System mit wenig Programmieraufwand zu optimieren und wenigstens mal auf den aktuellen Stand der Technik zu bringen, wird mit viel Aufwand ein neues - im schlimmsten Fall auch halbgares System - entwickelt.

Das ist meine Meinung dazu.

Klar sollte auch in eine KI investiert werden, diese wird aber nur so schlau, wie die Leute die sie programmieren. Ich denke nicht, dass auf absehbare Zeit alle Erfordernisse unzähliger Mandanten/Unternehmen in einer KI verarbeitet werden können. Wir fahren bei uns ganz gut mit der Funktion Ware/Leistung und daran hängender gut gepflegter Lerndateien. Da würde uns eine gut funktionierende OCR mehr helfen, als eine KI.

[#7]

@Bamsig: Nein, geht nicht aber ein Wunsch existiert: Belegdaten zusätzlich manuell per OCR auslesen @juliusbehr: Geht das nicht in die gleiche / ähnliche Richtung? 

Wobei ich manuell auch nicht mehr lesen will. Wenn ich erst "alles immer" manuell einstellen muss, kann ich's auch gleich auf Papier machen. Ist zwar schön, wenn man der OCR helfen kann aber die echte Lösung ist das auch nicht. Nachher ändert der Geschäftspartner das Layout; DUO ist nicht so schlau und behält die festgesetzten manuell eingestellten OCR Orte bei und fällt wieder auf die Nase. Ich glaube, das werden dann relativ viele Anwender haben. 

Die eigentliche Lösung: Vom Bund vorgeschriebene technische Anforderungen an eine Rechnung, die dann per Zusatzdaten (XML und Co.) auch maschinell auswertbar ist, ganz ohne OCR und dem Aufwand, der dahinter steckt. Wenn ich sehe, wie viel Power Nuance PDF braucht, um eine PDF durchsuchbar zu machen 😲 und das mal 3 Mio Belege täglich - nicht zu vernachlässigender Aufwand bei DATEV. Aber Deutschland, deine Digitalisierung ... können wir vergessen. 🙄 

---

@jjunker schrieb:

Die IBAN ist im Bildteil des PDF? (geht aber mittlerweile wohl auch auszulesen) 

---

Geht: OCR durchführen auch wenn nur Teile der PDF ein Bild sind

@jjunker: Was sagt denn @ManfredLener dazu? 🤓 

[#8]

Nur so nebenbei, die OCR ist top.

Was grottenschlecht ist, ist die Auswertung der OCR Daten. DATEV hat in grauer Vorzeit einmal ein System zusammengebaut um dies OCR auszuwerten. Dieses System hat dann für den Stand der Technik gut funktioniert und wurde eingesetzt.

Dann kam, wie üblich, der Forschritt und DATEV hat die bestehenden Systeme nicht weiterentwickelt sonder, wie üblich, ein neues und noch tolleres System angekündigt. Vernachlässigt wurde, wie üblich, die Weiterentwicklung des Bestehenden.

Darum wird die bestehnde OCR Erkennung und die daraus entwickelten Buchungsvorschläge auch nicht mehr weiterentwickelt und in naher Zukunft abgekündigt.

[#9]

Ach Daniel, was soll ich schon groß dazu sagen?

Die OCRs sind mehr oder weniger alle gleich (gut). Die Frage ist, was dahinter passiert! Da gibt es dann viele Möglichkeiten sowohl manuell aber vor allem auch mit KI die tollsten Sachen zu veranstalten...

Deine Idee, der Bund gibt ein Rechnungsformat vor, ist mindestens so alt wie sie intelligent ist. SWIFT hat vor mehreren Jahrzehnten exerziert, wie es funktioniert, neben den uns allen bekannten MT940 wurden für den Interbanken-Bereich noch jede Menge mehr MTs entwickelt, mit denen sich die Banken untereinander austauschen - weltweit und hochgradig automatisiert!!!

Bei den Banken konnte es funktionieren, weil sich (ich glaube in den 70er-Jahren) die ca. 5 größten Banken der Welt zusammengeschlossen und SWIFT gegründet haben. Alle anderen Banken mussten nachziehen, wenn sie mit den Großen weiter Geschäfte machen wollen. Und genau deshalb wird es bei einem einheitlichen Rechnungsformat scheitern (s. Zugferd). Es gibt zu viele Großkonzerne, die überhaupt kein Interesse daran haben, ihr Rechnungslayout auf einen Standard anzupassen - das kostet nur Geld und bringt (vermeintlich) keinen Nutzen. Von den Millionen Kleinen ganz abgesehen, die ihr Rechnungslayout als Marketing-Instrument betrachten.

[#10]

@metalposaunist ich möchte eigentlich nur ein Feld ausschließen (Kost), da übernimmt man ja manchmal auch die falsch vorgeschlagene KOST, nur weil man am Anfang die meisten Sachen dorthin gebucht hat und sich das OCR gemerkt hat... Also nicht manuell auslesen, nur steuern, dass man auch Sachen ausschließen kann, die dann nicht automatisiert erlernt werden.

[#11]

@Bamsig Debitor / Kreditor löschen und neue anlegen. Ich meine damit wird auch der falsch erlernte Schrott aus den Verknüpfungen gestrichen. --> Bitter aber es gibt so weit ich weiß keine direkte Einflussmöglichkeit auf das "Erlernte".

Zu Mal der "Schüler" eh den IQ einer 🐮 hat....

traurig aber wohl nicht zu ändern.

[#12]

Ich möchte hier auch noch eine Ausführung ergänzen, da dieser Wunsch schon des Öfteren angebracht wurde:

OCR liest Daten an der falschen Stelle aus --> ich möchte das Feld markieren, in dem der gewünschte auszulesender Wert steht (hier Rechnungsnummer). 

Bei der Rechnung handelt es sich um einen namhaften Hersteller, der offensichtlich mit SAP arbeitet, da das verwendete Rechnungslayout das SAP-Standardformat ist. 

Da das Programm im oberen Block auf der Rechnung nicht den Wert "Rechnungsnummer" oder etwas anderes erkennt, liest das System die WEEE-Reg.-Nr. als Rechnungsnummer aus der Fußzeile aus. Hier sollte das System generell niemals nach einer Rechnungsnummer suchen. Ich habe noch nie eine Rechnung gesehen, in der die Re-Nummer in die Fußzeile geschrieben wurde.

Dem Anwender bleibt nichts anderes übrig als sich jedes Mal zu ärgern und die Rechnungsnummer manuell mit der Hand in das betreffende Feld zu schreiben...

Aus meiner Sicht könnte man dem System auch bekannte Rechnungsformulare antrainieren - wie das im Beispiel genannte - da ja diese Händler/Hersteller massenhaft Rechnungen an eine Vielzahl von Unternehmen versenden.

Mir ist schon aufgefallen, dass das System sich generell sehr schwer tut, wenn im Text "Nummer/Datum" steht. Hierzu haben wir auch einen Servicekontakt geöffnet.

[#13]

Ja, es wäre schön, wenn man sehen könnte, weshalb die Texterkennung etwas vorgeschlagen hat und man darauf für künftige Erkennung Einfluss nehmen könnte. Das gilt für den Dokumentenkorb von DMS ebenso wie für den Automatisierungsservice der Finanzbuchhaltung. 

[#14]

Bitte auch verwirklichen, daß der Anwender beim Buchen eine eigene OCR hat, um beispielsweise eine nicht erkannte, aber deutlich lesbare Belegnummer einfach in die Buchungszeile kopieren kann. (Siehe Parallel- Idee)
Workflow: beim Buchen (Belegfeld ist nicht gefüllt)
- Im digitalen Beleg per Maus markieren

- Es kommt das Fenster mit der Erkennung und man kann nach einer Korrektur den Wert den Feldern zuordnen.

- Das Fenster verschwindet und ohne [OK] ist der Wert an der gewünschten Stelle in die Buchungszeile übernommen.

Bitte unbedingt das Feld "Buchungstext" hinzufügen, denn oftmals möchte man Details aus der Rechnung im Text stehen haben. (Bezeichung von Anlagegütern, usw.)

[#15]

Auch hier mal wieder ein Paradebeispiel für die Qualität der OCR 

[#16]

Update gefällig?

[#17]

Nur Mal so. Ich kann mir nicht vorstellen, dass nur 24 User mit der OCR unzufrieden sind. 🤔

[#18]

Scheinbar arbeiten nur 24 Leute so mit dem UO, dass es an die Grenzen kommt...was an sich nicht allzu schwer ist

[#19]

Tja wie soll das erst werden wenn die Volltextsuche mit UO next kommt......

[#20]

Vielleicht hilft es, die Anforderung einmal zu konkretisieren.

Was genau ist denn mit "auf den Stand der Technik bringen" gemeint?

Alle paar Wochen ein Beispiel von einem Beleg zu bringen, wo etwas nicht korrekt herausgelesen wurde deutet m. E. nicht auf einen zwingenden Handlungsbedarf hin. 

Hier im Haus werden ca. 80% aller Belege (i. d. R. Eingangsrechnungen) vollständig und korrekt ausgelesen. Statistisch ist da definitiv noch Luft nach oben - es scheitert aber m. E. allein an der Belegstruktur (Kassenbelege aus dem Hosentaschenarchiv, handgeschriebene Quittungen, mit dunklem Textmarker markierte Positionen, buchungsrelevante Informationen in Fließtext, optische tolle Briefbögen bei denen nach dem Scanvorgang eine maschinell nicht auswertbare graue Masse entsteht, Informationen überstempelt, USt-ID-Nr. extrem klein in der Fußzeile, verwendete Schriftart verschwimmt beim Scannen)

[#21]

Ich zumindest rede immer von DIN A4 Belegen die mit irgendeinen Fakturaprogramm geschrieben worden sind.

Berücksichtig wurde: 

DATEV Buchungsassistent online – Tipps zur Qualität und zum Aufbau der Belege

Tipps zur Optimierung der OCR-Erkennung in Belege online (datev.de)

Es ist dennoch immer wieder der regelmäßige(!!!) Fall das gleiche Rechnungen von Lieferanten z.B. fünf Rechnungen direkt hintereinander in DUO bearbeitet werden und er bei jedem Beleg unterschiedliche Felder (teilweise-) ausliest.

Die OCR soll einfach die unter Punkt 2.1 genannten Werte Buchungsassistent online (datev.de)

ZUVERLÄSSIG auslesen!