Aufbau von HBCI-Nachrichten

Hallo,

ich habe bereits einen anderen Thread aufgemacht, weil ich Probleme beim Abruf der Kontoumsätze mit libfintx habe.

Ich merke aber, dass ich zur Fehleranalyse erst mal ein Verständnis des Aufbaus von HBCI-Nachrichten benötige. Ich habe auch schon in den Spezifikationen gelesen, aber so richtig "Klick" hat es bei mir noch nicht gemacht.

Hier ein einfaches Beispiel, bei dem das TAN-Medium abgefragt wird:
Nachricht an die Bank:

Antwort:


Die Geschäftsvorfälle kann man ja in der Spezifikation nachschlagen. Aber die Antwort der Bank sagt mir nicht so viel. Zum Beispiel der Block


Die Plus-Zeichen sind ja Trennzeichen. Wofür stehen die Felder M:2 und M:1? Und warum die vielen Doppelpunkte?

Würde mich freuen, wenn da jemand Licht ins Dunkel bringen könnte...

Gruß

Hallo Sugar,

wenn Du dich ernsthaft mit eigenen Entwicklungen auseinander setzen möchtest, solltest Du Dich zunächst mal mit dem Aufbau der FiNTS Nachrichten genauer beschäftigen.
Das von Dir genannte Beispiel ist dafür ganz gut geeignet

Sowohl das "Plus", wie auch der "Doppelpunkt" sind Trennzeichen. Diese trennen nur unterschiedliche Dinge
Der Doppelpunkt trennt die einzelnen Datenelemente (DE in der Spec) innherhalb einer Datenelementgruppe (DEG in der Spec), während das Plus die Datenelemente trennt, bzw. wenn eine Datenelementgruppe mehrfach vorkommen darf, werden die einzelnen Gruppen ebenfalls mit einem "Plus" getrennt.
mit "+M:2" startet die erste Gruppe in der DEG
HITAB:5:4:3 Ist die DEG Segmentkopf
"+0" ist das DE TAN Einsatzoptionen und 0 steht dabei dafür, dass alle aktiven Medien parallel genutzt werden dürfen.
mit "+M:2" startet dann die DEG "TAN-Medium-Liste" mit der Definition des ersten TAN Mediums M steht für die TAN Medium Klasse "mobil/SMS", die ":2" gibt den Status dieses TAN Mediums an. Die 2 steht dabei für "Verfügbar".
Wenn ein Element nicht befüllt werden muss (O), dann bleibt der Eintrag leer, wird aber dennoch mit aufgeführt. Dadurch kommt es zu einer Liste "::::::::".
Alles das lässt sich in der Spec sehr gut nachlesen (nicht unbedingt für den Laien, aber wenn man sich dafür interessiert udn ein wenig Verständnis für Technik hat, geht das ganz gut) und auch jeweils durch klicken.

Viele Grüße

Holger

@Holger
ist es aber in o.g. Fall nicht sinnvoller, dass eine fertige API verwendet wird?
alles andere braucht "hier und dort" jeweils Fachwissen und dann kommen die Anpassung usw. hinzu

zumal es ja nicht die Hauptanwendung sein wird, von dem Entwickler, wenn man sich die posting-Historie anschaut

Ja, eine fertige Api erleichtert das alles. Aber auch da kommt man nicht wirklich drum herum einen Dialog analysieren zu können. Wenn man in dem Umfeld unterwegs ist, stellt sich einem mehr die Frage, wie tief man einsteigen muss und will.
Ich habe seit 30 Jahren kein Code mehr erzeugt und verstehe im FinTS Umfeld ganz viele Dinge nicht, aber das Verständnis zum Aufbau und Parametrisierung der GVs hat mir schon oft weiter geholfen.

@sugar76
ja und nein, denn ich muss kein Auto bauen/reparieren können, um es zu fahren, wenn ich nur von A nach B muss.
daher greifen ja viele startups usw. auf div. Anbieter zurück, da deren Fokussierung bspw. auf Buchhaltung/Rechnungserstellung liegt und der Abruf der Umsätze usw. nur ein "Nebenprodukt".

aber jeder soll es machen wie er will

da kann und werde ich Dir nicht widersprechen - das hatte ich einfach mal grundsätzlich vorausgesetzt
(deine aufgeführten Punkte "Auto" stimmen ebenso, hinzu kommt Führerschein usw.)