@ hibiscus

hibiscus schrieb in Re: VoP-taugliche Version 2.12.0 verfügbar · Gepostet: Heute um 16:11 Uhr · #211 : @hugox: Das ist ein anderer Fehler. Das VoP-Ergebnis wurde korrekt erkannt und das VOP-Auth an die Bank gesendet. Die Bank lehnt den Auftrag aber wegen vermeintlich falscher TAN ab. Warum sie das macht, kann ich in dem Log nicht erkennen.

so wie ich das verstehe, passiert nach

got VoP multiple result [desc: urn:iso:std:iso:20022:tech:xsd:pain.002.001.10]
adding new vop-auth message to queue [vop-id: aadd49b6-9755-45ab-9265-fbc831018388]
TAN process variant 2
Warte auf Antwortdaten

nicht mehr das zu erwartende:

es geht kein vop-fenster auf (datensatz1 ist 100% match und datensatz2 sollte close match sein).
also sollte das vop-fenster aufgehen und nach "abbrechen" oder "trotzdem ausführen" fragen.
das fenster geht aber nicht auf. dann kann ich auch nicht bestätigen, dass trotzdem ausgeführt werden soll. also erhalte ich auch keine app-TAN-anfrage auf dem smarty, so dass es keine falsche sondern gar keine TAN für die bank gibt. die bank bricht merkwürdigerweise den dialog sehr schnell ab, obwohl sie bei einem vop-fenster doch eine weile warten müßte, ob ich annehme oder abbreche.

der fehler scheint bereits nach dem senden der VoPAuth1 zu liegen. im hbcitrace-log steht 'HIRMS:3:2:3+3090::Ergebnis Namensabgleich prüfen', das vop-fenster geht jedoch nicht auf.

habe die anhänge hier nochmal beigefügt.

Wie soll Hibiscus Daten zu einem Close Match anzeigen, wenn die Bank in dem PAIN-XML keine Informationen zu den Aufträgen liefert?

@ hibiscus

haben wir hier einen ähnlichen fall wie aus "VoP-taugliche Version 2.12.0 verfügbar" #61 Seite4 ?

@ hibiscus

Vielleicht eine erste Merkwürdigkeit: beim Bankzugang der Hypovereinsbank ist kein
TAN-Verfahren hinterlegt (bei allen anderen steht chipTAN-USB oder photoTAN o.so).
Im log tauchen dann die Angaben "[PIN/TAN] using stored tan sec mech: <ask-user>"
bzw. "using chiptan MANUAL" auf. Ist das ein normales Verhalten?

Ich hänge ein jameica-log an. Darin ist 1. der Versuch eine Sammelüberweisung mit 2
Posten zu senden. Beide Posten sind 100% match. Diesen Sammler habe ich 2. dann in
2 Einzelaufträge geteilt und nacheinander gesendet. Es ging jeweils sofort das Fenster
für die Eingabe der TAN, die ich in der App auf dem Smarty erzeugen soll, auf. Ich habe
beide Aufträge abgebrochen, weil mir ja bekannt ist, dass Einzel bei 100% klappen.

Aus dem log ist vielleicht ersichtlich, wo der Unterschied bzw. Fehler liegen könnte.
Bei dem Sammler wird wohl das Ergebnis der Abfrage des 1. Datensatzes in Zeile 84
in eine queue geschrieben. Die Abfrage des 2. Datensatzes, der (für mich ist das komisch)
wieder VoPAuth1 genannt wird, scheitert dann in Zeile 97 jedoch sehr schnell.

Ich wünsche aber vor allem ein schönes Wochenende

Der Ablauf in Hibiscus ist ja bei beiden Auftragsarten exakt der selbe. Ich habe ehrlich gesagt keine Idee, was hier passiert.