Bei einer Zahlung via DKB EC-Karte (V-Pay) im PIN-Verfahren (nicht Lastschrifteinzugsverfahren), erfolgt die Buchung seitens der Bank in zwei Schritten: Als erstes wird der Zahlungsvorgang als Solcher sofort nach Zahlung ersichtlich. Zu diesem Zeitpunkt wird nur der Verwendungszweck und der Betrag angezeigt. Kein Gegenkonto und auch keine Zwischensumme. Als Verwendungszweck werden folgende Nummern in Hibiscus angezeigt: Terminalnummer, Datum und Uhrzeit der Transaktion.

Sobald die Buchung selbst durchgeführt wurde, wird als Verwendungszweck nur noch Kartennummer und Uhrzeit angezeigt. Der Rest fehlt.
Mich wundert sowieso, dass die Transaktionsnummer nicht vorhanden ist.

Ich habe daher mal das hbci-log von der ersten Transaktion (also bevor die Buchung selbst stattgefunden hat) angeschaut. Da sind alle Informationen des Zahlungsvorgangs enthalten - also auch die Transaktionsnummer z.B. und die Genehmigungsnummer. Trotzdem werden diese nicht angezeigt.

Der angezeigte Part steht unter
<Document><BkToCstmrAcctRpt><Rpt><Ntry><NtryDtls><TxDtls>
<RmtInf><Ustrd>angezeigter Wert</Ustrd></RmtInf>
</TxDtls></NtryDtls><Ntry></Rpt></BkToCstmrAcctRpt></Document>

Die weiteren Informationen, die nicht angezeigt werden, stehen in
<RltdPties>.....</RltdPties> auf gleicher Ebene wie <RmtInf></RmtInf> oben.

Allerdings ist mir aufgefallen, dass im kompletten <Document> ein verlorenes schließendes <BkTxCd/> rumsteht nach <Ntry>. Könnte das evtl. der Grund sein, warum die Daten nicht angezeigt werden?

Wie der hbci-Trace nach der erfolgten Buchung aussieht, weiß ich noch nicht - da muss ich erst warten, bis die durch ist.


Danke,
Gruß,
hbciuser.

Wenn einzelne Felder bei einer Umsatzbuchung in Hibiscus nicht mit angezeigt werden, liegt das in der Regel daran, dass diese Informationen seit dem neuen XML-basierten CAMT-Format in separaten Feldern abgelegt sind. Vor CAMT im alten MT940-Format gab es hierzu keine dedizierten Felder. Daher wurden diese von der Bank direkt mit im Verwendungszweck abgelegt. Um sie auch bei CAMT-Umsaetzen mit anzuzeigen, muss die SQL-Tabelle in Hibiscus um die entsprechenden Felder erweitert werden, die Daten muessen von HBCI4Java mit ausgelesen werden und die Benutzeroberflaeche von Hibiscus muss um diese Felder ergaenzt werden.

Ich empfehle dir auf jeden Fall erstmal ein Update auf Hibiscus 2.8.6 per Online-Update unter "Datei->Plugins verwalten". Das von dir genannte Feld "RltdPties" ist in 2.8.6 aber auch noch nicht enthalten. Siehe https://github.com/hbci4j/hbci…00107.java

Bin jetzt auf 2.8.6. Ich habe auch temporär die nightly-Variante getestet - da war es auch noch nicht drin. Gibt es schon eine grobe Vorstellung, wann das Feld "RltdPties" implementiert sein könnte - damit ich ungefähr weiß, wann ich mal wieder vorbeischauen sollte

Danke für Deine super Anwendung! Die läuft hier seit Jahren völlig geräuschlos!

Ich hatte das Feld bisher nicht auf der Roadmap fuer Hibiscus. Jetzt da ich weiss, dass es von Usern benoetigt wird, kann ich es mit aufnehmen. Ich denke, dass ich es in die naechste Version (2.8.7) mit einbauen kann.

Das wäre echt super! Wird hier konkret von der DKB so eingesetzt:
<RltdPties>
<Dbtr><Nm>Wert</Nm></Dbtr>
<DbtrAcct><Id><Othr><Id>noch ein Wert</Id></Othr></Id></DbtrAcct>
<CdtrAcct><Id><Othr><Id>ein anderer Wert</Id></Othr></Id></CdtrAcct>
</RltdPties>

Ach gleich 3 Felder? Ich dachte, eins. Was stehen denn da fuer Werte drin? Sprich: Was soll denn als Bezeichner bei diesen Feldern angezeigt werden?

Im Prinzip sind das Infos auf dem Beleg vom Kartenterminal:
<RltdPties>
<Dbtr><Nm>Transaktionsnummer und Genehmingungsnummer</Nm></Dbtr>
<DbtrAcct><Id><Othr><Id>eigene Kontonummer</Id></Othr></Id></DbtrAcct>
<CdtrAcct><Id><Othr><Id>vermutlich Kartenfolgenummer</Id></Othr></Id></CdtrAcct>
</RltdPties>

In der eigentlichen Buchung sind dann die folgenden Infos verbraten (und die von oben nicht mehr):
<RltdPties>
<Dbtr><Nm>ISSUER</Nm></Dbtr> (-> das steht explizit so drin)
<DbtrAcct><Id><IBAN>eigene IBAN</IBAN></Id></DbtrAcct>
<Cdtr><Nm>Firmenname</Nm></Cdtr> (was heute schon im Gegenkonto steht)
<CdtrAcct><Id><IBAN>IBAN der Firma</IBAN></Id></CdtrAcct> (die ist jetzt an sich schon da in GK IBAN)
<UltmtCdtr><Nm>Firmenname und Nummer//Ort/DE</Nm></UltmtCdtr>
</RltdPties>

=> Die interessanten Infos sind also über zwei getrennte Transaktionen zusammenzufügen - erst die Buchungsvormerkung und dann die Buchung selbst. Die Vormerkung bekommt man wahrscheinlich nur dann, wenn man noch vor der eigentlichen Buchung seitens der Bank eine Abfrage macht (-> übers Wochenende bei Zahlung am Samstag hat man ja genügend Zeit bis am Montag erst wieder gebucht wird). Die jeweils wichtigen Infos habe ich noch zusätzlich rot markiert.

Ich kann nicht sagen, ob alle Infos in der eigentlichen Buchungstransaktion enthalten sind, wenn man die Buchungsvormerkungsdaten nicht gezogen hat - ich gehe aber mal davon aus, dass man die dann nicht bekommt - dass sie also nie dabei sind in den eigentlichen Buchungsdaten.

Der Unterschied zwischen der Buchungsvormerkung und der eigentlichen Buchung dürfte hier zu finden sein:

<Sts>PDNG</Sts> -> Buchungsvormerkung / erster Datensatz
<Sts>BOOK</Sts> -> eigentliche Buchung

Cool wäre es, wenn man die beiden Datensätze zusammenführen könnte! Allerdings tue ich mich gerade schwer, eine ID zu finden, auf welcher man die beiden Transaktionen zusammenführen könnte.
Theoretisch vielleicht aus folgender numerischer ID (kommt in beiden Transaktionen vor - ob die allerdings auf die beiden Transaktionen bezogen ist oder global, vermag ich nicht zu sagen):

<Rpt>...
<Acct><Id><IBAN>eigene IBAN</IBAN></Id><Ccy>EUR</Ccy><Svcr><FinInstnId><BIC>BYLADEM1001</BIC><Nm>DEUTSCHE KREDITBANK AG</Nm><Othr><Id>diese numerische ID?</Id><Issr>UmsStId</Issr></Othr></FinInstnId></Svcr></Acct>
...
</Rpt>

Wobei, wenn die beiden getrennt stehen bleiben und die erste nicht durch die zweite ersetzt wird, ist das für mich auch ok (die erste bringt ja keine Salden mit und wirkt sich daher nicht weiter aus). Bisher war das immer so - aber diesmal komischerweise nicht (liegt das an der neuen Version?)

Das heisst, die für dich wirklich relevanten Informationen stehen gar nicht in der finalen Buchung sondern in der Vormerkbuchung? Dann gibt es keine wirkliche Möglichkeit, die Daten in Hibiscus zu übernehmen. Die Vormerkbuchungen sind nur temporär. Sobald die valutierten Buchungen eintreffen, werden die Vormerkbuchungen gelöscht. Hibiscus führt auch keinen Vergleich zwischen diesen Buchungen durch - eben weil es schwer ist, die Zuordnung zu finden. Ich bin mir auch nicht sicher, ob es überhaupt sinnvoll ist (selbst wenn es gehen würde), Daten aus Vormerkbuchungen final in die valutierten Buchungen zu übernehmen. Das Wesen der Vormerkbuchungen ist ja eben, dass sie nicht persistent sind sondern nur eine Vorankündigung.

Nein, ein Teil steht ja auch in der eigentlichen Buchung:
<UltmtCdtr><Nm>Firmenname und Nummer//Ort/DE</Nm></UltmtCdtr>

Woran erkennt Hibiscus, dass für eine valutierte Buchung eine Vormerkbuchung vorhanden ist, die gelöscht werden muss?

Das verstehe ich jetzt nicht ganz - wenn man die Vormerkbuchung löschen kann, muss man sie doch gefunden haben?

Das ist schon sinnvoll, weil die dort enthaltenen Daten ja nicht nur temporär relevant sind, sondern ständig - wie will ich sonst eine Doppelbuchung nachweisen können ohne die Transaktionsnummer? Ist erst kürzlich vorgekommen.

Aber das steht doch auch schon in "<Cdtr><Nm>Firmenname</Nm></Cdtr>". Das ist doch dann redundant.



Gar nicht. Es findet kein Abgleich zwischen Vormerkbuchungen und valutierten Buchungen statt. Hibiscus vergleicht lediglich die neu empfangenen Vormerkbuchungen mit den bereits vorhandenen Vormerkbuchungen. Alle Vormerkbuchungen, die lokal vorhanden sind, von der Bank aber nicht mehr geliefert wurden, werden geloescht. Aus der Tatsache, dass die Bank sie nicht mehr liefert, sie lokal aber noch vorhanen sind, ergibt sich implizit, dass die Buchung valutiert worden sein muss. Sonst waere sie von der Bank erneut uebertragen worden.



Wie gesagt: Sie werden einfach pauschal geloescht, sobald sie von der Bank nicht mehr geliefert werden. Da die valutierten Buchungen anders aussehen koennen, als die Vormerkbuchungen, ist ein zuverlaessiger Vergleich zwischen ihnen nicht moeglich. Wuerde man die Vormerkbuchungen erst dann loeschen, wenn man eine korrespondierende valutierte Buchung gefunden hat, wuerden regelmaessig verwaiste Vormerkbuchungen im System bleiben, zu denen die zugehoerige valutierte Buchung nicht gefunden wurde.



Aber nur die valutierten Buchungen sind die "echten". Deswegen sind es ja die valutierten. Unabhaengig davon, dass es aus meiner Sicht keinen zuverlaessigen Weg gibt, Vormerkbuchungen gesichert auf die valutierten Buchungen zu matchen, begibt man sich meiner Meinung nach auf recht "experimentelles" Feld, wenn man versucht, aus Vormerkbuchung und valutierter Buchung eine Art hybride Buchung zu konstruieren, in der sowohl Daten aus der Vormerkbuchung als auch aus der valutierten Buchung enthalten sind.
Gibt es denn irgend eine Banking-Anwendung, die sowas macht?

Nein - nur teilweise, weil in

<UltmtCdtr><Nm>Firmenname und Nummer//Ort/DE</Nm></UltmtCdtr>
[/quote]

auch der Ort und die Filialnummer steht - bei Firmen, die Ketten sind, durchaus relevant.


Zur Vormerkungs- und eigentliche Buchungs-Geschichte
Eigentlich müsste die Bank dafür sorgen, dass in der finalen Buchung alle Infos drin stehen - das schaffen andere Banken ja auch. Muss mal mit denen reden.

Wenn man zwei unterschiedliche und konkurrierende Informationen hat, ist das Problem ja eher noch komplexer. Die Software müsste sich ja dann für einen von beiden Werten entscheiden. Und dort sollte ja dann eher der Wert aus der valutierten Buchung Priorität vor dem Wert aus der Vormerkbuchung haben.
Es gibt ja keine zuverlässigen Kriterien, nach denen die Software sowas entscheiden könnte. Da begibt man sich auf einen Pfad aus Mutmaßungen, welche Informationen aus welchen Buchungen dann die relevanteren sein könnten.



Korrekt. Die valutierte Buchung ist die echte und gültige. Dort müssen die Informationen drin stehen.

Die Info ist in der valutierten Buchung! Da gibt es auch keine Widersprüche: die eine Info ist die schon vorhandene im Gegenkonto und die bleibt exakt unverändert. Zusätzlich kommt die oben genannte hinzu im Verwendungszweck, die die konkrete Verkaufsstelle angibt, während im Gegenkonto die globale Firma genannt wird. Das ist kein Widerspruch und da muss man sich auch nicht entscheiden und da gibt es auch keine Widersprüche. Das ist eine einfache Entnahme, die statisch völlig unabhängig von allen anderen Infos ist.

Aber weiter vorn im Thread schriebst du doch noch, dass hier Informationen aus Vormerkbuchung und valutierter Buchung zusammengeführt werden sollen?