MT940 - Externer Parser: Möglichkeit zur Integration eines eigenen Tools?

Hallo zusammen,

ich habe eine Frage zur Verwendung der Funktion "Externer Parser" im MT940-Importbereich, da ich dazu in der Hilfe keine konkrete Anleitung finden konnte.

Ich nutze Taxpool Bilanz v18.23.

Meine Frage:

Ist der „Externe Parser“ ein fest vorgegebenes (mitgeliefertes?) Programm, oder könnte ich stattdessen ein eigenes Tool integrieren, wie etwa ein benutzerdefiniertes LUA-Skript oder eine vergleichbare Lösung?

Hintergrund:

Im MT940-Format tauchen häufig SEPA-spezifische Kennzeichnungen im Verwendungszweck auf, wie z. B.:

• EREF+
• KREF+
• NOTPROVIDED

Zusätzlich gibt es viele weitere SEPA-Kennzeichnungen, die ebenfalls relevant sein können.

Mein Ziel wäre es, eine Logik zu entwickeln, die diese und ähnliche SEPA-Zeichenfolgen filtert und gegebenenfalls auch die (zugehörigen) nachfolgenden Angaben entfernt.

Danke + Gruss!

Hallo wiko-services.de,

vielen Dank für die Information!

Gerne würde ich verstehen, was Du damit meinst, dass der Verwendungszweck "mit Bordmitteln von Taxpool ausgewertet werden" kann?

Ich möchte ja nichts auswerten. Gibt es eine Suchen+Ersetzen Funktion? Prinzipiell will ich ihn ja textuell verändern.

Oder spielst Du darauf an, dass ein LUA-Skript die aus dem MT940-Dateiimport resultierenden Buchungstexte bearbeiten könnte?

Vielen Dank!

Grüße

blinky

Quote

Ich habe aber noch nicht verstanden, was Du konkret beeinflussen willst.

Ich möchte im Rahmen des MT940 Imports den Text für den Buchungsvorschlag verändern können, so dass beispielsweise die SEPA-Abkürzungen automatisch entfernt werden. Die Logik dürfte durchaus komplexer werden, deshalb die Frage nach einem extern aufrufbaren Tool oder LUA-Skript.

Beispielhaft

Liefert die MT940-Datei beispielsweise (modifizierte Echtdaten)

192/OCMT/EUR525,00//LU00000000012300000BIC:XXXXXABCXXXKREF+NONREF Zahlungseingang

so wäre im einfachsten Fall beispielhaft KREF+NONREF zu entfernen:

192/OCMT/EUR525,00//LU00000000012300000BIC:XXXXXABCXXX Zahlungseingang

Mit einem regulären Ausdruck könnte auch die ISIN und BIC des Absenders erkannt und entfernt werden:

192/OCMT/EUR525,00// Zahlungseingang

Noch ein Beispiel (partiell Echt- durch Beispielwerte ersetzt):

OTHR Sonst. Transakt /INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01EREF+0816555555KREF+NONREFMREF+1444100020-003CRED+DE88ZZZ00000123456 Zahlungsausgang

könnte nach simpler Entfernung von OTHR, EREF+, KREF+ , MREF+ CRED+ im Ergebnis beispielsweise so lauten:

Sonst. Transakt /INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01 0816555555 NONREF 1444100020-003 DE88ZZZ00000123456 Zahlungsausgang

oder falls gewünscht eine String-Substitution durchgeführt werden:

Sonst. Transakt /INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01 ExtRef 0816555555 MRef 1444100020-003 Zahlungsausgang

oder nach "cleverer" Löschung des zum EREF/KREF/MREF/CRED zugehörigen Wertes sowie Löschung des unnötigen Strings "Sonst. Transakt /" :

INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01 Zahlungsausgang

Der Vollständigkeit halber sei erwähnt:

Obiges basiert auf Daten der Deutschen Bank, nach Abruf mit Hibiscus und Export als MT940-Datei zwecks Import nach Taxpool. CAMT wäre hier wohl das Mittel der Wahl, da die Daten dort hoffentlich bereits "sauber" sind (meine Hoffnung). Leider habe ich gegenwärtig keine Möglichkeit für einen entsprechenden CAMT-Datenbezug.

Quote

Der Verwendungszweck ist ja von der Bank gegeben, den kannst Du nur in den Buchungstext übernehmen und dort bearbeiten.

Ok - Danke! Das hatte ich vermutet. Meine Hoffnung lag darauf, einen beliebigen externen Parser einbinden zu können, in dem die Ersetzungslogik untergebracht ist. Aber so überlegt muss man eventuell einfach direkt an die MT940-Datei heran und die Modifikationen des Verwendungszweckes dort durchführen.

Besten Dank für die Infos!

Hallo modular,

vielen Dank für die Informationen!

Quote

Ein Einsatz von LUA vor und nach dem Import ist bereits auf der ToDo-Liste, da aber derzeit viele wichtige Sachen in der Warteschlange stehen, kann das noch lange dauern.

Danke für den Einblick in die ToDo-Liste!

Ich fasse zusammen

- Externer Parser soll durch interne Funktionen ersetzt werden, geplant ca. Anfang 2025.

- Online-Banking Schnittstelle verbessern, evtl. eigene Online-Banking Fähigkeit oder aber unter Nutzung von Hibiscus, evtl. ab Mitte 2025.

- LUA-Skript vor/nach (Kontoumsatz-)Importen ausführen ist ein Eintrag auf der ToDo-Liste, aber niedrig priorisiert. Nicht in der konkreten Planung.

Ich bin neugierig:

Gibt es denn für uns Anwender auch einen Einblick in die Roadmap oder ToDo-Liste? Ggf. inklusive Priorität.

Falls nicht, nicht schlimm. Ist ja auch immer eine Art Commitment und schraubt die Erwartungshaltungen hoch.

Aber eventuell gibt es das ja doch bereits und ich weiß nur nichts davon. Daher frage ich.

Anpassen der Verwendungszwecke

Danke für die Anregung wg. Notepad++ bzw. den CSV-Exporten. Prinzipiell versuche ich es immer, manuelle Schritte möglichst zu vermeiden.

In Hibiscus scheinen die originalen MT940-Daten zu liegen, aber möglicherweise auch bereits "optimierte" Verwendungstexte.

Denn im MT940-Export wird augenscheinlich das Original samt KREF+, EREF+ etc. ausgegeben. In der Hibiscus-GUI wird es aber schöner dargestellt und auch beim CSV-Export "optimiert" ausgegeben.

Es scheint sogar, dass Hibiscus möglicherweise bereits einige Informationen aus dem Verwendungszweck extrahiert.

Der Vollständigkeit halber hier die Ansicht des zweites Beispiel-Umsatzes aus meinem Post oben. Ich musste entsprechend auch im Screenshot die Echtwerte durch Beispielwerte ersetzen, daher die darin ersichtlichen Manipulationen.

Man beachte unten die Umschaltmöglichkeit hin zum Original-Verwendungszweck anstatt des von Hibiscus bereinigten Textes:

Mir fällt hierbei gerade auf, dass Hibiscus die Reihenfolge im Verwendungszweck nicht konsequent ausgibt.

• In der MT940-Datei werden EREF, KREF, MREF am Ende ausgegeben (wie im Beispiel in meinem vorherigen Post und wie von Taxpool nach dem Import auch dargestellt).
• In der Hibiscus-GUI wird es aber anders herum angezeigt (siehe ersten Screenshot, unten).

Ob die Reihenfolge der Elemente (EREF, MREF, CRED, SVWZ etc.) bei MT940 bzw. im SEPA-Kontext streng definiert ist oder flexibel ist, was ich spontan nicht. Ich tippe auf flexibel. Dennoch interessant zu wissen. Es wird spannend, welche Werte Hibiscus in der Datenbank ablegt respektive per RPC zurückgibt.

Danke + Gruss!

blinky

modular

Noch ergänzen möchte ich:

Die Umstellung zu CAMT ist im Gange. Eben im üblichen Banken-IT-Umstellungstempo. Das Ganze läuft unter ISO 20022 und das kommende Jahr 2025 spielt hier bereits eine entsprechende Rolle. Es dürfte nicht allzu lange dauern, bis es final auch bei den Endkunden im Online Banking ankommt.

Beispielhaft

2025 und 2026 -> Commerzbank: ISO 20022 Umstellung Zeitplan

Nov'2025 --> DATEV -> Das Format MT940 wird von der Deutschen Kreditwirtschaft zum November 2025 abgekündigt und durch das Format camt.053 (CAMT-Format) ersetzt.

Zur Info zwecks entsprechender Design-Entscheide in der Entwicklung.

modular Besten Dank für den Hinweis! Ich werde es mir mal anschauen.

Frohe Festtage und einen guten Rutsch!

modular Nochmals besten Dank!

Da Taxpool und Hibiscus auf unterschiedlichen Rechnern (und nicht immer im gleichen Netzwerk) waren, musste ich erst einmal die Zeit finden, mich dessen anzunehmen. Das habe ich heute tun können.

Die direkt Kommunikation bzw. Übertragung aus Hibiscus heraus nach Taxpool funktioniert ausgezeichnet, besten Dank!

Die Verwendungstexte sind um einiges sauberer, so dass sich der obige Bedarf einer Post-Import-Ersetzung im Buchungstext für mich auch erstmal erübrigt hat. Dennoch wäre es natürlich ein nettes Feature (z.B. per konfigurierbarer Lua-Skript Ausführung nach Umsatzimport) aber sei's drum.

Drei Anmerkungen (hier, da es auch noch kein neues Unterforum für den neuen Hibiscus-Menüeintrag gibt)

1. Popup-Fenster mit Hinweis "neues hibiscus.xmlrpc Plugin"

Beim Hibiscus-Import erhalte ich immer dieses Popup-Fenster, auch wenn ich "Diese Meldung nicht mehr anzeigen" selektiert habe und auch egal, ob ich den Dialog mit Ja oder Nein schließe. Auch ob ich die Kontoumsätze danach importiere oder nicht ändert nichts an dem Verhalten.

Ergo: Das Popup erscheint jedes mal. So beobachtet in 19.09.

2. Kategorienummer versus Kategoriebezeichnung

Laut diesem Beitrag unter dortigem Punkt 4 wurde mit Version 19.04 das Vorgehen beim Kategorie-Mapping geändert.

Zwar ist im referenzierten Forenbeitrag die Rede von "erweitert", ganz klar ist mir aber nicht, ob technisch somit von Hibiscus-internen Kategorienummern zu den Kategoriebezeichnungen gewechselt wurde.

Mir fällt nur auf, dass das Mapping laut der Hilfe (dort dem Screenshot und der Beschreibung) offenbar anhand der Kategoriebezeichnung erfolgt, nicht anhand einer Kategorienummer. In diesem Zusammenhang irritiert die Verwendung des Begriffs "Nummer" in der GUI:

3. Import Kontoumsätze

Wählt man als Zeitraum "Alle verfügbaren Umsätze", so werden diese bzw. können diese nicht mit den per MT940-Import erzeugten Buchungssätzen gematcht werden.

Dies führt dazu, dass man bei längerer Kontoauszugs-Historie in Hibiscus sehr viele redundante Buchungssätze erzeugen würde, die schon in Taxpool vorhanden sind.

Klar kann man nun immer mit "letzter Monat", "letzte Woche" ("letztes Quartal" fehlt ) oder der konkreten Datumsauswahl arbeiten, aber dann muss man sich um die Eingabe ggf. manuell kümmern, wenn man keinen regelmäßigen Takt hat.

Es fehlt die Möglichkeit, Taxpool beizubringen, ab wann es relevante Kontoumsätze abfragen soll.

Entweder dadurch, dass man sämtliche Hibiscus-Kontoumsätze mit den bestehenden Buchungssätzen "matchen" kann oder aber mit einer Funktion "seit letztem Datenimport" oder ähnlich. Es wäre sodann egal, ob man den Import täglich, erst nach 3 Wochen oder erst nach 3 oder 5 Monaten durchführen würde, ohne dass man sich darum kümmern muss herauszufinden, bis zu welchem Datum der Import beim letzten Mal erfolgt ist und ab wann jetzt wieder zu importieren ist.

Punkt 1 ist vermutlich nicht im Sinne des Erfinders und wäre schön, wenn es gefixt würde. Macht den "Workflow" besser

Bzgl. den Punkten 2 und 3: Kosmetik und mit dem Verhalten kann man glaub ich umgehen, kein Weltuntergang. Dennoch sei es erwähnt.

Vielen Dank!