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.