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

@hugox
Da Du hier explizit von Sammelüberweisungen sprichst. Heißt das, dass das von dir am 4.11. beschriebene Problem gelöst ist? Ich probiere zur Zeit nur Einzelüberweisungen. Beim exakten Match geht das TAN Fenster auf und alles ist gut. Bei allen zuerst fehlgeschlagenen VoP Prüfungen bekomme ich jedoch keine TAN Abfrage und stattdessen direkt die Fehlermeldung, dass der Auftrag wegen fehlender TAN abgelehnt wird. Sorry, wenn ich in dem anderem Thema etwas übersehen habe, das ist einfach zu lang geworden.

Bei mir funktioniert auch die Einzelüberweisung nicht.
Bei dem Versuch der Übernahme der korrekten Adressdaten in das Adressbuch erschien folgende Fehlermeldung:

26.11.2025 12:22:49] Warte auf Antwortdaten
[26.11.2025 12:22:49] unable to apply rewriter RInvalidSuppHBCIVersion - leaving message unchanged: reststring in DialogEndRes.MsgHead:
[26.11.2025 12:22:49] unable to apply rewriter RSecTypeTAN - leaving message unchanged: reststring in DialogEndRes.MsgHead:

Könnt ihr damit etwas anfangen?

Echtzeitüberweisung oder "alte SEPA-Überweisung"?
Update auf Hibiscus 2.12.1 wurde gemacht?
danach sync durchführen

Die Meldungen kannst du ignorieren. Das ist nicht die Ursache.

Es war eine normale SEPA-Überweisung.
Nach dem update von 2.12.0 auf 2.12.1 habe ich kein neues Sync gemacht. Hätte ich das machen sollen?

Dass das nichtÜbernehmen nicht die Ursache ist, ist klar. Ich dachte nur, es sollte bekannt sein, dass eine von der Bank vergeschlagene korrekte Adresse nicht übernommen wird.

@ L8912

die Probleme vom 04.11.25 bestehen noch immer

1. Einzelüberweisung: bei nicht 100%-iger Übereinstimmung von Empfänger und IBAN
funktioniert "Trotzdem ausführen" nicht. Also abbrechen und Eingaben 100%-ig machen.
Nach der Entzeitüberweisung vom 03.11. funktionieren ab dem 06.11. auch normale
SEPA-Einzel-Überweisungen. Es geht dann direkt das Fenster auf, dass ich die TAN eingeben
soll, die in der HVB-App mit TAN-ID-Abfrage-Nr. xyz per Freigabe erzeugen soll.

2. Sammelüberweisungen gehen bis heute gar nicht. Es geht nicht mal ein VOP-Fenster auf.

@ waki

siehe oben 1.; allerdings habe ich die 2.13.0 nightly-versionen inzwischen im Einsatz und ich
synchronisiere den Bankzugang vorsichtshalber vor jedem neuen Versuch Sammelüberweisungen auszuführen, weil ich mir erhoffe, dass die HVB etwas zum Besseren geändert hat.

Ich will mal ein kurzes Update geben.
Selbst mit dem neuesten nightly vom 16.12. funktioniert bei mir immer noch keine Überweisung.
Ich habe jameica und hibiscus von heute installiert, den Bank-Zugang neu synchronisiert und eine Sofort-Überweisung ausgelöst.
Nachdem der Empfänger nur fast übereingestimmt hat, habe ich den Vorschlag in das Adressfeld übernommen und versucht, die Überweisung neu zu starten. Dann kam das Popup-Fenster nicht mehr und es kam schnell die Fehlermeldung:



Kann ich mit Tests etwas dazu beitragen oder ist das soweit bekannt?

Poste hier doch bitte Mal das vollständige Log und nicht nur einen kleinen Ausschnitt.

Hier das log nachdem ich die Empfängerdaten aus dem vorherigen Versuch übernommen habe: