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ß

Ich habe mich nie intensiv mit dem HBCI-Protokoll auseinandergesetzt, aber das werden eh die allerwenigsten hier je getan haben. Aber:

Ich gehe mal davon aus, dass da zwei Handynummern für den Versand von Mobile-TAN registriert sind? Also werden zwei Datensätze mit den möglichen Auswahlen gesendet...

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

Super. Dank Deiner Erläuterungen konnte ich das ganze auch in der Spec nachvollziehen. Da geht einem doch ein Licht auf ...

Gruß

@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

Klar wäre höchstwahrscheinlich die Verwendung einer API sinnvoll(er). Aber das war hier nun mal nicht die Frage. Und ich muss sagen, ich finde es gescheiter, die gestellte Frage zu beantworten als sich bemüßigt zu fühlen, den Frager zu "missionieren".

Wenn er z.B. nur ganz bestimmte Dinge braucht (z.B. ausschließlich Umsatzabfrage), könnte es auch sinnvoller sein, das selbst zu programmieren, als eine große API zu verwenden, die erstens für solche Fälle (vielleicht sogar Distribution des fertigen Programms) alles andere als billig und ggf. viel zu "mächtig" ist. Ein anderer Aspekt ist die Unabhängigkeit von Vorlieferanten, was unter Umständen auch Vorteile bietet. Klar, die werden an anderer Stelle durch Nachteile erkauft - aber das muss jeder Entwickler selber wissen. Insofern finde ich die "einfache Beantwortung der Frage" durchaus gut.

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.

Ja, das ist nur ein Teil der Anwendung, an der ich arbeite. Aber ein Wichtiger. Es geht um den regelmäßigen Abruf von Umsätzen und die Durchführung von Einzel-Überweisungen.

Um "unabhängig" zu bleiben, schaue ich mich im Opensource-Bereich um und versuche, das HBCI-Protokoll zu verstehen. Ob es in vertretbarer Zeit möglich ist, ohne den Einkauf von Drittherstellern auszukommen, wird sich zeigen. Zumindest hbci4java (und auch hibiscus) wirkt ausgereift.

Ich finde, es ist immer von Nachteil, eine Technologie einzusetzen, die man nicht versteht.

Gruß

@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

Das verschiebt aber nur die Fragestellung. Auch hier muss/sollte ich Grundlagen der verwendeten Schnittstelle kennen
Um bei deinem Autovergleich zu bleiben:
Ich muss das nicht bauen können, aber es hilft schon zu wissen, dass wenn die gelbe Lampe aufleuchtet, dass ich tanken muss, ich in einem Diesel besser mei Benzin fülle und wenn es passiert auf gar keinen Fall den Motor starten sollte, wie ich eine Reifen wechsel, Schneeketten drauf ziehe usw....
Wie tief das Wissen geht / gehen sollte hängt von vielen Faktoren ab.

Viele Grüße
Holger

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.)