[gnucash-de] Vorschlag zur Änderung des Verhaltes des SWIFT-Import

[gnucash at junix.ch]

Lieber Pierre

Ja, mehr oder weniger funktionieren tuts bei mir auch. Ich meine, ich bekomme Transaktionstexte wie " 20.03.2017/19:52 / Maestro-Karten-Nr. xyz". Das war mir dann etwas zu wenig, weshalb ich mich entschlossen hatte, der Sache auf den Grund zu gehen. Im E-Banking meiner Bank (Raiffeisen, auch nicht gerade ein kleines Licht 😉) verfügt die Transaktion über die erweiterte Info "Einkauf Metzgerei xyz", die für mich mindestens so wertvoll ist wie der Transaktionstext der auch in GNUcash ankommt. Als ich das MT940-File mal im Texteditor aufgemacht habe, stellte ich fest, dass die Daten auch da drin steckten. Nur eben nicht dort wo es GNUcash erwartet hätte.

> Ich gebe zu, ich habe die ganze MT940-Problematik nie so richtig studiert.
> Es funktioniert bei mir so mehr oder weniger, darum habe ich es nicht hinterfragt.
> 
> Ich habe allerdings den Eindruck, dass nicht alle Banken die MT940-Regeln gleich interpretieren. Denn:
> Ich importiere MT940-Dateien von einer deutschen Sparkasse und von unserer Schweizer PostFinance, in der Schweiz wohl das wichtigste Institut für den Zahlungsverkehr.
> Was importiert wird, und wie es schlussendlich ankommt, ist ganz unterschiedlich!
Der Grund weshalb die MT940-Transaktionen unterschiedlich ankommen dürfte darin liegen, dass Raiffeisen diese Daten beispielsweise im NS-Datensatz (Non-SWIFT) speichert. Das scheint wohl irgendwie auch festgelegt. AqBanking (das Import-Frontend) hat da beispielsweise folgende Zuordnung:
- NS-Bereich 01-14: Zweck
- NS-Bereich 15-16: Auftraggeber
- NS-Bereich 17: Buchungstext
- NS-Bereich 18: Primanota
etc.
Die Frage ist aber natürlich berechtigt ob und inwiefern sich die Banken an diese Non-SWFT-Codierung halten. Wäre es Dir vielleicht möglich, Deine MT940-Auszüge mal auf diese :NS:-Datensätze zu prüfen? Die Zeilen fangen mit :NS:01 an, gefolgt von einer Reihe von Zeilen mit zweistelligen Dezimalzahlen und ggf. Text. Bis irgendwann wieder ein :61: o.ä. kommt.

> Wie gesagt: irgendwie kommt man schon draus, und es geht so, aber in den Details wird es offensichtlich anders interpretiert.
> Darum wäre ich sehr vorsichtig, bevor man alles auf den Kopf stellt.
Die vorgeschlagene Option B würde lediglich den NS-Bereich 17 den Bereichen 01-14 voran stellen und so einen "bandwurm"-String bilden. Option A wiederum würde NS17 nur benutzen wenn auch vorhanden und sich sonst verhalten, wie Du es Dir gewohnt bist. Ich bin mir jetzt nicht sicher ob das wirklich "alles auf den Kopf stellen" bedeutet...

> Inwieweit wäre es möglich, und auch sinnvoll, den Import zu parametrisieren?
> Z.B. dass GnuCash in der Tabelle anzeigt, was es verstanden hat, und der User dann sagen kann, ob es richtig ist, und ob er es anders haben möchte?
Das ist ein spannender Gedanke. Für eine Antwort stecke ich da aber zu wenig tief im GTK-Teil von GNUcash drin. Unabhängig von der Umsetzung könnte ich mir aber auch vorstellen, dass man sich die Zusammenstellung vielleicht auch komplett einstellen könnte. Also NS17 gefolgt von NS4, dann NS9, ganz so wie es passen würde. Ich gehe aber davon aus, dass dies ein erheblicher Mehraufwand bedeuten würde. Insbesondere weil ich in dem Zusammenhang gleich auch noch fordern würde, dass man diese Präferenzen irgendwie speichern und wieder abrufen kann (das nervt mich beim CSV-Import schon gehörig, dass das nicht geht). Wie gesagt. Hier fehlt mir die Kompetenz für eine Einschätzung der Komplexität. Vielleicht hat Christian da ja 'ne Meinung zu?

Viele Grüsse
Ueli