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

Seitens der Hypovereinsbank haben sich letzte Woche Parameter geändert. Jetzt funktionieren bei mir Überweisungen trotz fehlgeschlagener VoP.

@ L8912

bei der HVB hatte sich wohl etwas geändert. Es ist möglicherweise wieder verschlimmbessert worden.

Ich konnte am 19.,20. und 21.01.26 jeweils SEPA-Sammelüberweisungen tätigen. Dabei waren jeweils alle Empfänger korrekt.

Seit (weis nicht genau) Tagen geht es wieder nicht. Ich lande nach ...xsd:pain.002.001.10 und adding new vop-auth message to queue sofort wieder bei: Meldung der Bank:9050: teilweise fehlerhaft und Namensabgleich erforderlich... Dementsprechend
geht kein VOP-Fenster in Hibiscus auf und in der HVB-App gibt es keinen Auftrag mit ID-Nr.... zum freigeben.

Ich gehe davon aus, dass es an der HVB liegt, da sie es ja zwischenzeitlich hinbekommen hatten.

Einzelüberweisungen habe ich seit dem 19.12.25 nicht mehr probiert. Ich brauche die Sammler.

Seit dem 19.02.2026, und auch am 23.02.2026, gehen die Sammler wieder - sowohl mit allen Posten als Match als auch mit beinahe Übereinstimmung plus der folgenden Zustimmung zum "Trotzdem Ausführen" (diese Zustimmungsfenster geht
auf und auch anschließend das für die Eingabe der TAN, die in der Smartphone-App erzeugt wird) - Erfolg.

Hatte Kontakt mit der HVB-Hotline. Ein Knackpunkt könnte gewesen sein, dass unser Konto ein sog. "Aktivkonto" ist. Dies ist
normalerweise ein Privatkonto und Sammelüberweisungen sind nicht vorgesehen. Viele kleine und mittlere Unternehmen
nutzen dieses laut HVB aber als Geschäftskonto. Die Bezeichnung "Aktivkonto" taucht jedoch nirgends auf. Man kann es nur
anhand der Preisliste und dem Monatspreisin der Abrechnung identifizieren. Allerdings steht in der Kontoabrechnung, dass
man vom Team Business easy betreut wird. Was die HVB geändert hat, weiß ich nicht, es gab trotz angenehmem telefonischen Kontakts keine Info. Bei den diversen Synchronisationen des Bankzugangs gab es auch keine Hilfe, seit November 2025 sind es immer die Version 38 für UPD und die Version 86 für BPD, also gibt es keinen Hinweis auf erfolgte Aktualisierungen.

Hatte am 18.02.2026 gewechselt vom nightly vom 19.11.2025 auf die stable 2.12.2 vom 16.01.2026. Ich weiß nicht, ob sich dadurch auch innerhalb von hibiscus etwas geändert hat - dem ChangeLog konnte ich nichts Derartiges entnehmen.

Da der Abbruch damals immer erfolgte, nachdem die "new vop-auth message" in die Warteschlage geschrieben wurde und die
Angabe "TAN process variant 2" folgte, denke ich, dass die neue Problemstellung, die VoP-Prüfung, eigentlich abgeschlossen war, dann aber der Übergang zum Abarbeiten der 2-Faktor-Autorisierung bei der HVB nicht korrekt durchlief.

Ich hoffe, dass die Situation mit der HVB jetzt zu aller Zufriedenheit - und das auch nachhaltig - gelöst ist. Danke an Mr. Hibiscus.