Ich möchte die Nettosummen aus Amazon-Rechnungen auslesen und als Netto-Summe setzen. Diese liegen im Text+PDF-Format vor. Ich habe dafür eine Intelligente Regel erstellt mit regulärem Ausdruck.
Regulärer Ausdruck, den ich verwendet habe:
Zwischensumme (ohne USt.)[^\d]+\d+,\d{2}[^\d]+(\d+,\d{2})
Wenn man den Text aus der PDF-Datei ausliest sieht er wie folgt aus (gesucht ist die zweite Summe):
…
Zwischensumme (ohne USt.)
29,24 € 29,24 €
Gesamtpreis
…
Es funktioniert nicht.
Ich habe verschiedene andere Varianten versucht. Außerdem bin ich nicht sicher was ich bei “Nettosumme ändern in” eintragen soll. Es steht standardmäßig in hellgrau “NaN” da. Wenn ich z.B. “/1” verschwindet es auch wieder, wenn ich die Regel wieder zum Bearbeiten öffne.
Es ist unklar, was Sie eigentlich tun wollen. Sie möchten Nettosummen festlegen… wo? Als benutzerdefinierte Metadaten?
Und wenn Sie welchen Text in der PDF-Datei lesen? Wenn Sie sich auf das beziehen, was Sie in der PDF-Datei sehen, gibt es keine Garantie dafür, dass dies auch der zugrunde liegende Text ist. Verwenden Sie Daten > Konvertieren > In Klartext, um die tatsächliche Textebene im Dokument zu sehen.
Hallo Bluefrog, danke für deine Antwort und die klärenden Nachfragen!
Genau, Nettosumme als benutzerdefinierte Metadaten.
Ich hatte den Text markiert und in einen Texteditor kopiert um die Textebene zu sehen. Daten > Konvertieren > In Klartext ist möglicherweise eleganter, liefert aber den gleichen Text.
Erstmal müsste man wissen, wie der Text wirklich aussieht. D.h. “Konvertieren in Text” und dann davon den relevanten Ausschnitt posten, bitte.
Zu deinem Regulären Ausdruck: Zwischensumme (ohne USt.)[^\d]+\d+,\d{2}[^\d]+(\d+,\d{2})
Also:
“Zwischensumme (ohne USt.)” (was NICHT das findet, was du denkst!)
gefolgt von mindestens einer Nicht-Ziffer (was man knapper und klarer als \D+ schreiben würde)
Gefolgt von mindestens einer Ziffer
Gefolgt von einem Komma und genau zwei Ziffern
Gefolgt von mindestens einer Nicht-Ziffer (s.o., vermutlich willst du damit das € erwischen)
Gefolgt von mindestens einer Ziffer, einem Komma und genau zwei Ziffern, in einer capturing group aufgesammelt.
Das sieht für mich nach etwas “over-engineered” aus. Du suchst doch einfach nur “Zwischensumme (ohne USt.)” gefolgt von irgendwas und am Ende der Zeile willst du (\d,\d{2})\s+€ haben. Dann schreibst du das besser so: Zwischensumme\s*\(ohne\s*USt\.\).*\D(\d+,\d{2})\s*€.*$
Gegenüber deinem ursprünglichen Ausdruck hat das den Charme, auf unnötige Matches zu verzichten. Und es baut keine capturing group mit den ungeschützten Klammern um ohne USt. herum. Mehr dazu weiter unten.
Außerdem habe ich ein paar \s* eingestreut, wo du fixe Leerzeichen hattest. Damit findest du 0, 1 oder mehr Leerzeichen. Das ist vermutlich bei maschinell erzeugten PDF nicht so wichtig, aber bei OCRten schon.
Und der RA funktioniert so nur, wenn DT implizit . auch auf Newlines passen lässt. Tut es vermutlich.
Und was genau bedeutet das? Niemand außer dir kann wissen, was du tust, um herauszufinden ob “es funktioniert”. Vielleicht meinst du ja “mein regulärer Ausdruck findet nicht, was er finden soll”? Oder vielleicht meinst du “mein regulärer Ausdruck findet zwar, was er finden soll, aber ich komme nicht an die capturing group heran”. Oder Du meinst noch etwas ganz anders, vielleicht “DT stürzt immer ab, wenn ich diesen Regulären Ausdruck benutze”. Aber das sagst du alles nicht.
NaN = Not a number. Vermutlich, weil dein ganzer regulärer Ausdruck fehlschlägt. Außerdem hieße es \1 und nicht /1, meintest du die erste capturing group.
Erklärung zur unfreiwilligen capturing group
Du suchst mit deinem Regulären Ausdruck nach Zwischensumme (ohne USt.). Aber das kannst du so in deinem PDF nicht finden: Bis "Zwischensumme " ist alles ok. Aber dann kommt eine “(” im Text – und nach der sucht der RA nicht, sondern nach “o”. Denn die Klammer in deinem Ausdruck ist der Beginn einer capturing group! Grundsätzlich musst du alle Zeichen, die in Regulären Ausdrücken eine besondere Bedeutung haben, mit einem Backslash “schützen”. Das betrifft {}()[]/|+*.?$^\ (mindestens, vielleicht habe ich auch was vergessen).
Präzisierung des Fehlers:
Wennn ich die Intelligente Regel auf das Dokument anwende, passiert nichts: der Wert Nettosumme bleibt leer.
Vielen Dank für den überarbeiteten regulären Ausdruck und die nachvollziehbare Erklärung. Habe ich so angewendet. Im Ergebnis keine Veränderung. Ich habe als Variante auch den Zeilensprung extra definiert mit \n. Auch hier keine Veränderung.
Wenn ich die intelligente Regel wieder zum Bearbeiten öffne, nach wie vor “NaN” in dem Feld nach “Nettosumme ändern → in”
Ein Screenshot des Dialogs für die Intelligente Regel habe ich angehängt.
Was könnte der Fehler sein?
Und zu meinem Verständnis:
Muss ich immer eine Capture Group definieren in der zweiten Zeile in der ich definiere, worein geändert werden soll, oder kann ich das Feld leer lassen, wenn ich nur eine Capture Group im regulären Ausdruck habe?
in Kombination mit
“Warnung anzeigen” und “\1”
tut bei mir das Richtige.
Also muss das $ am Ende weg.
Was allerdings auch hier nicht funktioniert, ist “\1” bei einem benutzerdefinierten Metadatum vom Typ “Zahl”. Ich weiß nicht, ob das beabsichtigt ist oder ein Bug – @cgrunenberg?
Im Moment scheint der einzige Weg, das von dir Gewünschte zu erreichen, ein Script zu sein.
Genau so durchgeführt. Auch mit Backslash vor den Klammern und dem “.” nach “Ust”. (Hast du die jetzt absichtlich weggelassen?) Die Warnung erscheint. Der Wert Nettosumme ändert sich nicht. Wenn ich die Intelligente Regel zum Bearbeiten öffne ist “\1” wieder verschwunden und das hellgraue “NaN” steht da.
Auch mit einem anderen Wert durchgeführt dessen Datentyp ‘einzeiliger Text’ ist. Gleiches Ergebnis: Warnung erscheint, Wert ändert sich nicht. Allerdings bleibt hier “\1” stehen.
Das läuft vermutlich falsch, weil die benutzerdefinierten Metadaten nicht mit den capturing groups der regulären Ausdrücke zurechtkommen. Da kommen wir jetzt nicht weiter.
Nein. Die waren im Text drin, Discourse zeigte sie aber nicht an, weil ich das nicht als Code markiert hatte. Jetzt aber …
