AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

OCR Delphi und Belegerfassung

Ein Thema von Lemmy · begonnen am 22. Feb 2018 · letzter Beitrag vom 22. Feb 2018
Antwort Antwort
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.381 Beiträge
 
Delphi 10.4 Sydney
 
#1

OCR Delphi und Belegerfassung

  Alt 22. Feb 2018, 09:57
Servus,

wenn ich mir das Thema hier anschaue:
http://www.delphipraxis.net/79040-oc...-delphi-3.html

stellt sich mir die Frage (auch wenn mir klar ist, dass es auch Produkte mit einer genaueren Erkennungsleistung gibt): Wie gehen die Programme vor, die Belege nach einem Scan automatisch erfassen und ggf. buchen oder daraus eine Überweisung zaubern? Neben einer möglichst fehlerfreien OCR muss das Programm dann ja die Informationen durch gehen und schauen wo der Rechnungsbetrag steht. Nur wie bekommen das die Programme raus? Bei den wenigsten steht vor dem Rechnungsbetrag noch ein Text. Die Kontoinformationen sind da sicherlich einfacher zu ermitteln, weil IBAN oder BIC meist mit einem entsprechenden Text versehen sind....

Grüße
  Mit Zitat antworten Zitat
Benutzerbild von sh17
sh17

Registriert seit: 26. Okt 2005
Ort: Radebeul
1.664 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: OCR Delphi und Belegerfassung

  Alt 22. Feb 2018, 12:48
Ich würde zunächst ein Dokument durch eindeutige Merkmale klassifizieren, also bei Lieferant xy sieht das Schriftstück so und so aus, oben der Name, Rechnungsbetrag steht immer dort usw. also wenn die OCR dann an der entsprechenden Stelle etwas findet, ist klar von wem das Dokument kommt. Jeder neue Lieferant muss manuell angelernt werden. Ebenso wenn der Lieferant sein Layout ändert. Durch geschickte Auswertung von unbekannten Dokumenten kann dem Bearbeiter bei der Klassifizierung geholfen werden. Evtl steht eben doch schon mal Rechnungsbetrag als Text drauf oder so.

//Besser wäre übrigens, wenn die Dokumente schon als PDF kommen und die Rechnungsdaten mittels ZUGFeRD schon enthalten. Das spart die OCR.
Sven Harazim
--

Geändert von sh17 (22. Feb 2018 um 12:50 Uhr)
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.381 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: OCR Delphi und Belegerfassung

  Alt 22. Feb 2018, 13:48
//Besser wäre übrigens, wenn die Dokumente schon als PDF kommen und die Rechnungsdaten mittels ZUGFeRD schon enthalten. Das spart die OCR.
also bitte... das wäre doch viel zu einfach


Ich frag mich halt insbesondere, wie das die Banken mit ihrer Handy-Rechnungsapp machen. Keine Frage, die aktuellen Smartphones haben genug dampf - aber mir fällt beim besten Willen nicht ein, wie ich das zuverlässig (d.h. für mich 8 von 10 Rechnungen funktionieren ohne manuellen Eingriff) funktioniert - selbst wenn die Rechnungsapp das gar nicht macht sondern den Beleg an einen Sever übermittelt und der am Ende die Arbeit macht...



Grüße
  Mit Zitat antworten Zitat
Benutzerbild von sh17
sh17

Registriert seit: 26. Okt 2005
Ort: Radebeul
1.664 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: OCR Delphi und Belegerfassung

  Alt 22. Feb 2018, 14:13
Machine Learning

Evtl wild alle Zahlen auf dem Blatt OCRn und zusammenaddieren, bis alle Zahlenblöcke die korrekte Summe ergeben, die auch auf dem Blatt sein muss. In der Regel stehen die ja auch in einer Spalte von oben nach unten.
Sven Harazim
--
  Mit Zitat antworten Zitat
hanvas

Registriert seit: 28. Okt 2010
168 Beiträge
 
Delphi 11 Alexandria
 
#5

AW: OCR Delphi und Belegerfassung

  Alt 22. Feb 2018, 19:42
Servus,

wenn ich mir das Thema hier anschaue:
http://www.delphipraxis.net/79040-oc...-delphi-3.html

stellt sich mir die Frage (auch wenn mir klar ist, dass es auch Produkte mit einer genaueren Erkennungsleistung gibt): Wie gehen die Programme vor, die Belege nach einem Scan automatisch erfassen und ggf. buchen oder daraus eine Überweisung zaubern?

Grüße
Dazu muss man zunächst einmal zwischen strukturierten, semi strukturierten und nicht strukturierten Daten unterscheiden.

Formulare sind strukturiert. Der Sinn einer Information ergibt sich aus der Position auf dem Formular. Bei einem Überweisungsbeleg ist klar wo der Betrag steht und was die Information bedeutet, ebenso haben Kontoinformationen und Personen ihren festen Platz.

Das ist der einfachste Fall. Aber einfach ist relativ. Gescannte Papiere werden ja nicht immer gerade eingezogen und wenn diese gerade sind, dann möglicherweise ein wenig mehr rechts oder ein wenig mehr links als normal, möglicherweise hat der Lieferant aus dem Lieferschein ja auch ein verknülltes Brotzeitpapier gemacht oder hat den Lieferschein im Regen ausgefüllt.

Die grundsätzliche Vorgehensweise ist immer gleich. Zunächst versucht man zu erkennen um welches Formular (das als Referenz in einer Art Datenbank gehalten wird) es sich handelt. Dann wird das gescannte Bild gerade ausgerichtete und möglicherweise entzerrt. Wenn das geschehen ist wird das Bild mit dem Referenzbild in übereinstimmung gebracht (Bildregistrierung)

Linien und Kästchen welche als Felder auf dem Formular dienen müssen natürlich entfernt werden, da ansonsten über den Rand geschriebene Informationen nicht ordentlich gelesen werden können.

Daneben gibt es noch eine Vielzahl weiterer Operationen und das Thema ist wirklich komplex.

Zitat:
Neben einer möglichst fehlerfreien OCR muss das Programm dann ja die Informationen durch gehen und schauen wo der Rechnungsbetrag steht. Nur wie bekommen das die Programme raus? Bei den wenigsten steht vor dem Rechnungsbetrag noch ein Text.
Das sind meist semistrukturierte Daten. Wie bei einem Formular sind gleiche Informationen, wie Absender, Datum etc. entweder an festen Positionen zu finden oder der Kontext ergibt sich aus Beschriftungen. Wenn man beispielsweise immer Rechnungen von der gleichen Person / Firma bekommt dann ist der Aufbau des Dokumentes nach dem ersten Dokument klar.

Zur Verarbeitung unstrukturierter Dokumente braucht man ein wenig Hintergrundwissen. Beispiel gefällig :

In Deutschland geschriebene Briefe haben immer ungefähr das gleiche Format, links steht der Empfänger, in einer Zeile über dem Empfänger meist der Absender, das Datum meist rechts.

Die Art der nichttextuellen Information kann man häufig auch aus dem Format ableiten. Ein Datum in Deutschland hat meist 10 Buchstaben, zwei für den Tag, zwei für den Monat, vier für das Jahr und zwei Trennzeichen. Alle so aufgebauten Daten sind vermutlich Datumsangaben.

Finden sich Währungszeichen oder Währungsbezeichnungen neben oder über den Angaben handelt es sich vermutlich um Beträge, Anschriften zu erkennen ist seit den 60er Jahren automatisiert.

Daten die in Tabellenform angeordnet sind, mit oder ohne Trennlinien, lasse sich relativ leicht daran erkennen das es Blöcke gibt bei denen der Wortanfang immer an der gleichen X Position beginnt (linksbündig) oder das Wortende an der gleichen X Position endet (rechtsbündig)

Weiss man das tabellierte Daten vorliegen und weiß man das es sich um eine Rechnung / Gutschrift etc. handelt, dann ist der Schluss das es sich um die Positionen der Rechnung handelt nicht mehr weit.

Natürlich gibt es noch viel mehr Regeln, aber ich glaube die grundsätzliche Vorgehensweise wird klar. Wichtig ist das man weiss um welche Art von Dokument es sich handelt, damit man weis welche Regelsätze verwendet werden. Ein Dokument zu klassifzieren ist aber nicht sehr schwer (z.B. Bag of Words)

Wenn man den ungefähren Aufbau ermittelt hat, ermittelt man alle nicht textuellen Daten und versucht diese zuzuordnen, entweder man kennt die Bedeutung aus der Phase zuvor oder die Bedeutung oder ein beschreibendes Wort steht in der Nähe.


cu Ha-Jö
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:13 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz