Hallo,

ich setze Hibiscus in der neuesten Verfügbaren Version ein. Vielen Dank für diese tolle Software.

Aber jetzt gibt es Probleme. Folgenden interessanten Fehler habe ich seit Neuestem mit der deutschen Bank.

Es verschwinden seit ein paar Tagen diverse Umsätze aus dem Konto, die mit Hibiscus getätigt worden sind. Aber nicht nur die, sondern alle anderen (auch eingehende Umsatzposten) auch - ganze Umsatztage gehen flöten, sobald an dem Tag auch nur eine Buchung mit Hibiscus ausgeführt wurde. "Verschwinden" bedeutet in diesem Fall, daß die Umsätze systemweit (auch im Onlinebanking) nicht mehr zu sehen sind.

Nach stundenlangem Suchen (und noch längerem, sehr anstrengendem Gespräch mit der Helpline) stellt sich jetzt heraus, daß es daran liegt, daß in den Umsätzen (Verwendungszweck) ein Doppelpunkt auftaucht, was in deren Onlinebanking-System (meine Vermutung) zu einem Parser-Fehler führt. Das ganze passiert erst, wenn die Umsatzposten gebucht werden - in den vorgemerkten Buchungen sind sie noch zu sehen, und die Zahlungen werden im Banksystem auch ausgeführt. Die Bank kann sie intern auch noch sehen, aber im Onlinebanking sind sie nicht mehr sichtbar, wenn der Tag gebucht ist (und alle anderen Umsätze von diesem Tag dann eben auch nicht).

Abgesehen davon, daß die Bank offiziell von einem Fehler spricht, also anerkennt, daß der Doppelpunkt eigentlich ein erlaubtes Zeichen (Sonderzeichen) ist: Wie kommt jetzt der Doppelpunkt in meine Buchungen, ich schreibe in den Verwendungszweck gar keine rein?

Auch das konnte ich aufklären:

Seit einiger Zeit schreibt die Deutsche Bank die Umsatzposten um, und fügt ein Feld "KREF+" ein (anscheinend Kundenreferenz, NICHT Ende-zu-Ende Referenz). Dieses Feld wird Softwareseitig gar nicht bespielt (Hibiscus hat dazu ja auch gar keine Eingabemaske), stattdessen fügt anscheinend der Hibiscus HBCI-Dialog da etwas ein:

Beispiele:

Umsatz 19.09.14

"zweck2": "KREF+hbci4java-2014-09-19T1",
"zweck3": "1:33:22:0391\n

Umsatz 05.09.14

"zweck2": "KREF+hbci4java-2014-09-05T0",
"zweck3": "7:01:12:0945\n

Wo kommt das her?
Sieht wie ein Zeitstempel aus. Naja, jedenfalls führt diese "Signatur" dazu, daß der Umsatztag aus der Bank fliegt.

Jetzt kommt das Trauerspiel: Die Bank sagt, "Ja, das ist ein Fehler auf unserer Seite" - sagt aber nicht, wie der plötzlich da reingekommen ist (es lief bis 22.09. einwandfrei, trotz der sichtbaren Doppelpunkte, siehe oben), und will den Fehler erst zwischen November und Dezember beheben.
So lange kann ich aber nicht warten, da ich die Software auch als Vermieter einsetze und mir nicht jeden Morgen von der Bank telefonisch ein Update holen möchte, ob die Mieten meiner Mieter auf dem Konto eingetroffen sind. Die Bank sagt natürlich wie immer: "Tja, Sie können ja StarMoney einsetzen", aber das kann es ja jetzt auch nicht sein.

Ich vermute mal, daß dieses Problem jeden betrifft, der Hibiscus mit der Deutschen Bank einsetzt. Es ist auch egal, welche HBCI-Methode verwendet wird (ich habe zwei Konten, eines privat und eines für die Mieteinnahmen, eines wird mit HBCI+ abgefragt das andere mit Schlüsseldiskette).

Besteht die Möglichkeit, diese Signatur herauszunehmen? Ich bin zwar der Meinung, daß das ein Problem sei, was die Bank zu lösen hat, da Doppelpunkte wohl kein Problem bei einer Zahlung darstellen dürften, befürchte aber, daß ich als kleiner Kunde dort nichts ausrichten kann, um den Vorgang zu beschleunigen.

Was könnte ich noch tun? Läßt sich ansonsten dieses Feld irgendwo überschreiben?

Vielen Dank für eine Einschätzung.
Peter Terpe

Nachtrag: Mit "Onlinebanking" meine ich natürlich das Web-basierte Banking auf der Homepage der Bank.

Die Umsätze sind also WEDER im Onlinebanking auf der Webseite NOCH per HBCI sichtbar.
Sorry für eventuelle Unklarheiten.

Peter

Nein. Wenn deine Hibiscus-Version noch "hbci4java-" reinschreibt, kann es nicht die aktuelle Version 2.6.8 sein. Das habe ich naemlich aus der PmtInfId entfernt.
Siehe https://github.com/willuhn/hbc…54feea45d6
Mich hatte naemlich irritiert, dass da "hbci4java" im Kontoauszug steht.

Von daher: Mach auf jeden Fall erstmal ein Update auf die aktuelle Version 2.6.8

Und bist du sicher, dass das an den Doppelpunkten liegt? Kann ich mir eigentlich nicht vorstellen. Die KREF wird ja vom Bankingprogramm generiert. Das machen andere Bankinganwendungen genauso. Und die schreiben dort auch den Zeitstempel in diesem Format rein. Meines Wissens nach sogar auch Starmoney.

Sprich: Von dem Problem bei der deutschen Bank sollte eigentlich nicht nur Hibiscus betroffen sein sondern auch andere Bankinganwendungen.

Unabhaengig davon: Mit Hibiscus 2.6.8 kannst du den Wert selbst beeinflussen. Dort gibt es naemlich ein neues Eingabefeld "Referenz (Payment-Information-ID)", welches genau das ist, welches anschliessend im Kontoauszug unter KREF erscheint. Wenn du das frei laesst, wird da der aktuelle Timestamp im Format "yyyy-MM-dd'T'HH:mm:ss:SSSS" reingeschrieben.

Entschuldigung, ich habe nicht gesehen, daß es schon wieder eine neue Version gibt. 2.6.8 setze ich tatsächlich noch nicht ein, stimmt.
Danke, das werde ich zunächst mit einem Update ausprobieren.
Toll, dass man das KREF Feld jetzt selbst belegen kann. Das wird die Probleme sofort ausräumen.

Ja, ich bin sicher, daß es an den Doppelpunkten liegt, denn das hat mir ein Techniker aus dem Secondlevel so gesagt. Starmoney soll
auch betroffen sein, das hatte er in einem Nebensatz erwähnt, war mir nur nicht wichtig.

Die Bank will das im Rahmen eines Hotfix' auch selbst beheben, aber wenn Hibiscus dieses Feld selbst auch verändern kann, habe ich
ja sofort eine Lösung! Perfekt!!

Danke, dass ihr so toll seid.

Ich melde positiven Vollzug zurück!

Gruß Peter

Da kommt jetzt etwas an die Oberfläche, wo ich mich schon seit längerem gewundert habe, dass das anscheinend klaglos klappt.

Die DeuBa überträgt soweit ich weiß Umsätze ja noch mit MT940. Jetzt ist es so, dass in MT940 der : als Zeichen verboten war und in den Umsatzdaten nicht vorkommen durfte, denn er wird ja als Feldschlüssel benutzt. Eine Zeile beginnt mit :20: oder einem anderen Feld. In ganz bestimmten Konstellationen kann es wohl vorkomkmen, dass die Software, die die MT940-Daten interpretiert und die Felder in eine lokale Datenbank schreibt nicht mehr klar erkennen kann, ob es eine neue MT940-Zeile ist oder ob es ein (deswegen ja eigentlich verbotener) : in einem Feld ist, denn der : unter SEPA ist ja ausdrücklich erlaubt. Ich selbst hatte mit B4W noch nie ein Problem mit in Texten vorkommenden ::::. Allerdings habe ich mich schon oft gewundert, dass dem nie so war

msa, das ist inhaltlich mit dem Doppelpunkt nicht ganz richtig. Man kann einen Feldschlüssel auch komplexer als mit nur einem Zeichen definieren, z.B. durch Das kann man in einem Programmcode mit einem ganz trivialen Regex beschreiben, der z.B so aussieht: /^:\d{2}:(.+)$/m.
Von daher ist es nicht abwegig, dass ein Doppelpunkt auch als Feldinhalt vorkommen darf und zugleich Bestandteil des Feldtrenners ist. Fraglich ist nur, ob es tatsächlich so definiert ist seit der Doppelpunkt in SEPA zulässig ist oder ob da jeder macht, was er für richtig hält

Du hast natürlich Recht. Wenn der MT940-Parser gescheit programmiert ist, dann klappt das schon - sieht man ja an B4*
Ich gehe aber davon aus, dass das bei anderer Software mitunter nicht soooo genau genommen wurde, insbesondere bei älteren Systemen. Und da könnte es dann wohl manchmal aushaken. Und dass der : früher verboten war (und somit auch kein Parser-Schreiber damit gerechnet hat oder besser rechnen mußte) ist ja Tatsache...

Woran machst Du das fest? Ich kenne keine MT940 Spec, nach der der : verboten wäre. Allerdings ist der letzte Stand auf den ich zugreifen kann aus der Änderung 2001

Mmmmh, ich beziehe mich auf die erlaubten Zeichen im DTA-Zeichensatz.... Da war doch der : verboten. Sollte mich meine Erinnerung so trügen?

Laut einer alten Notiz von mir war der erlaubte Zeichensatz bei DTAUS dieser:
Demnach liegt msa völlig richtig, dass der : zumindest im DTAUS verboten war. Demnach konnte ihn früher eigentlich auch kein Kunde im IZV eingereicht haben und somit sollte der : - egal ob nun so per Spec manifestiert oder nicht - im MT940 auch nur extrem selten aufgetaucht sein. Die Überlegung kann ich nachvollziehen.

wobei das alte Problem ja eher ist, dass eine Foren-Anfrage gestellt wurde, ohne vorheriges Software-Update.

denn wenn durchgeführt, scheint es ja zu funktionieren.

Ja, infoman, das wissen wir, wir können lesen. msa hat in Nr. 5 aber eine Folgefrage und ich würde ihm gern helfen, diese zu beantworten!

Hallo zusammen,

Vielen Dank für den Hinweis mit dem Update. Nachdem ich nun wirklich die aktuellsten Versionen eingespielt habe, ist das Problem verschwunden. Ich habe die Payment Referenz befüllt, und der gewünschte Wert kam bei der Bank unter KREF+ an. Der eingegebene Wert taucht im Onlinebanking zwar nicht sichtbar auf, aber wenigstens sind die Umsätze unbeschädigt und alles sieht wieder normal aus. Was ich noch nicht getestet habe, ist das Freilassen des Feldes, und ob die Bank mit dem Standardwert, den das Programm setzt, auch klarkommt. Das probiere ich bei den nächsten Transaktionen aber aus und berichte davon dann auch noch einmal.

Vielen herzlichen Dank für die Hilfe!
Peter Terpe

Hallo,

ich hatte ja noch eine Rückmeldung versprochen.

Unter Verwendung der neuen Version liefert Hibicus nun, wenn das KREF Feld nicht befüllt ist, folgendes zur Bank, was sich heute abend auf dem Kontoauszug wiederfand:

"KREF+2014-10-06T07:58:32:09"

Da ich den gebuchten Umsatz so wiedergeben kann, bedeutet das, daß die Bank nun auch wieder "Doppelpunkte" schluckt, was wohl an dem neuen Filter liegt, den sie im Rahmen eines Hotfixes eingespielt haben wollen. Das eigentliche Update und die endgültige Fehlerbehebung erfolgt aber erst im November, so daß es bis dahin weiterhin zu fehlerhaften oder verschwundenen Umsätzen kommen kann, solange dieser (oder ein anderer) Zeitstempel im Verwendungszweck (KREF+) auftaucht. Dies sei auch bankseitig nicht mehr beeinflußbar. Garantien geben sie darauf jedenfalls nicht.

Ich bin zu gleich froh und entsetzt. Froh darüber, daß ich mit der neuen Hibiscus Version dies notfalls auch selbst beeinflussen kann. Entsetzt darüber, daß die Bank ohne im Vorfeld zu informieren einfach solche Hürden, freie Software zu nutzen, einbaut. Schwer zu sagen, was das bewirkt: Aber offenbar ist es Zeit, die Bank zu wechseln.

Eine letzte Frage noch an Olaf Willuhn: Kann ich im Payment Server dieses Feld auch setzen, wenn ich mit XML Überweisungen oder Lastschriften für die Mietzahlungen erzeuge?? Mein Sohn hat mir ein Programm dafür geschrieben, allerdings zu einer Zeit, wo das Feld noch nicht existierte. Ist das einfach nachrüstbar?

Schönen Gruß
Peter Terpe

Naja, es ist ja nun eigentlich keine Huerde, die sich speziell auf freie Software bezieht sondern ein Problem ganz allgemeiner Natur. Andere Bankingprogramme waren davon ja wie gesagt auch betroffen.



Ist im Payment-Server nocht nicht drin - rueste ich aber bis zur naechsten Version 2.6.9 noch nach.

Hallo,

die neue Version 2.6.9 ist ja jetzt draußen. Wie kann ich das KREF Feld im Hibiscus-Server per XML ansprechen?

Schönen Gruß,
Peter Terpe

Ich weiss jetzt nicht, ob du die XML-RPC- oder die SOAP-Schnittstelle verwendest. Aber es gibt da jeweils ein neues Attribut "pmtinfid", bei dem man diesen Wert hinterlegen kann.

Hallo,

XML-RPC ist es. Auch mit der aktuellen Nightly-Build-Version wird ein Attribut "pmtinfid" nicht in die Payment-Referenz im Auftrag übertragen, das Feld bleibt leer (gleichermaßen bei Lastschrit und Überweisung).

Heißt das wirklich so und findet man darüber was im Wiki unter http://www.willuhn.de/wiki/dok…zelauftrag ? Ich bin mir nicht sicher, ob wir die richtigen Werte angegeben haben, andere Felder funktionieren allerdings wie immer einwandfrei, nur pmtinfid tut es nicht (mein Sohn kommt erst nächste Woche wieder vorbei, vorher kann ich im Programmcode nichts prüfen [lassen]).

Schönen Gruß,
Peter Terpe

Mein Sohn hatte gerade noch zum Schluß eine allerletzte Idee. Und die war es dann.

Alle Programmversionen waren aktuell - bis auf das XML-RPC Plugin selbst. Das war nicht aktuell, sondern noch von der 2.6.8. Was lernen wir daraus? Immer erst ein vollständiges Softwareupdate machen.

Nach einem Update des Moduls und einem Aufruf der XML-Routine werden die Paymentreferenz-Felder einwandfrei befüllt, so wie es sein sollte. Es besteht also kein Handlungsbedarf mehr, damit kann man das Feld vollständig mit unkritischen Werten füllen, und dann werden die Umsätze von der Bank auch wieder fehlerfrei wiedergegeben.

Thema kann nun geschlossen werden.

Vielen Dank fürs Lesen, und die freundliche Hilfe.
Peter Terpe