Was denn für PATTERN jetzt aufeinmal, wovon redet ihr, worum geht es?
Im Kontext dieses Threads ist ein Pattern (ungefähr) ein regulärer Ausdruck, der den Zweck hat, den Wert für einen bestimmten Schlüssel (z.B. Rechnungsnummer) aus einer Rechnung eines bestimmten Lieferanten zu extrahieren. Und ein Pattern-Set ist eine Sammlung von Pattern, die die Werte für alle Schlüssel aus einer Rechnung eines bestimmten Lieferanten ermitteln sollen. Wenn man das wirklich programmiert, sollte man vielleicht bessere Namen finden.
Erkennung Typ der Rechnung (Kategorie):
-> Wie willst du das über ein Pattern lösen?
-> Beispiel:
a) Du kaufst bei Amazon einen Stuhl und buchst das als Büromaterial
b) Morgen kaufst du bei Amazon einen Telefon und buchst das unter Telefon
-> Würdest du hier dann wiederum Patterns anlegen, damit die einzelnen Positionsarten ermittelt werden?
Ursprünglich war die Kategorie doch eher ein grobes Branchenkennzeichen, bei dem man davon ausgehen konnte, dass es bei demselben Lieferanten nahezu konstant ist (Hotel, Hoster). Da hätte man im Set des Lieferanten entweder ein Pattern mit einem konstanten Wert oder mehrere Pattern mit Bezeichnungen angelegt.
Das neue Beispiel (Stuhl, Telefon) ist jetzt aber viel spezifischer. Deine ursprüngliche Anforderung war kaum mehr, als den Rechnungsbetrag zu ermitteln, was man mal so eben aus der hohlen Hand umsetzen kann. Jetzt sind wir plötzlich bei einer Rechnungspositionserkennung. Ich hatte schon in einem meiner ersten Beiträge angedeutet, dass das eine ganz andere Grössenordnung ist. Das wird dann schon ein Projekt, bei dem man auch eine vernünftige Analyse machen muss. So etwas würde ich aber nur anfangen, wenn positionsweise Daten aus Bestellungen und Wareneingangen der Warenwirtschaft zur Verfügung stehen. Sonst kann man das, was man aus der Dokumentenerkennung bekommt, sowieso nicht sinnvoll weiter verarbeiten.
In der PATTERN - Tabelle würde ich wirklich nur die verfügbaren PATTERNS speichern, die es tatsächlich gibt, also genau 1x
Sofern kein Treffer eines PATTERN_SET gefunden wird, könnte ich ja die einzelnen PATTERN von der Tabelle PATTERN durchgehen, ggf. matched dann das ein oder andere aber eben nicht alle von einem PATTERN_SET
Die würden bestimmt hier und da matchen. Wenn sie aber für einen anderen Lieferanten entwickelt wurden, bekommt man da aber sicher auch mal beispielsweise ein Auftragsdatum zurück, wenn man eigentlich ein Rechnungsdatum haben will. Die Lieferanten stimmen sich ja nicht untereinander ab, in welcher Reihenfolge sie solche Angaben auf der Rechnung machen.
Außerdem würden wahrscheinlich Pattern-Leichen entstehen, weil man bei Anpassungen sicherheitshalber ein neues Pattern erstellt, obwohl es vielleicht ausschließlich für den Lieferanten, den man gerade verbessern will, benutzt wird und gefahrlos geändert werden könnte. Ich glaube, es ist viel einfacher, bei einem neuen Lieferanten irgendein Pattern-Set zu kopieren und da die RegEx rein zu kopieren, die man im RegExp-Tester entwickelt.
Die Variationen der OCR können so vielfältig sein, dass es ohnehin schwierig wäre, vordefinierte Pattern vernünfttig zu benennen, damit man sie für eine Wiederverwendung überhaupt findet. Man braucht unterschiedliche Pattern ja nicht nur aufgrund verschieden strukturierter Rechnungen, sondern auch zur Kompensation von OCR-Fehlern. Da muß man manchmal trotz eigentlich gleicher Struktur dennoch individuelle Umwege nehmen.
Den Vorteil, den ich aber sehe ist, wenn ich keinen Treffer zu einem PATTERN_SET finde, muss ich nicht 1000 x X Patterns durchgehen, sondern nur die Einträge, die in PATTERN sind.
Wie bereits im vorigen Abschnitt beschrieben, würde ich das nicht machen, denn ich hätte lieber keinen Treffer, als einen falschen.
