Hallo,

seit einiger Zeit (Ende letzten Jahres?) sehe ich bei Lastschriften aus Kartenzahlungen bei meiner Bank (Sparkasse) als Empfänger bzw. Inhaber nur noch den Text "Lastschrift aus Kartenzahlung":



Im Online-Bereich der Bank ist der Empfänger aber ausgeschrieben:



Gibt es eine Möglichkeit die Informationen in Hibiscus anzuzeigen und zu speichern? Ansonsten lässt sich schwer zuordnen, wofür die Lastschrift war. Was ist mit bereits abgerufenen Datensätzen: Können die noch aktualisiert werden?

Vielen Dank für die vielen Jahre der Entwicklung dieses sehr nützlichen Programms.

Viele Grüße,
Hendrik Peilke

Einstellung geprüft ob CAMT Abruf erfolgt?
(oder noch alt mit MT940)

Das kommt darauf an, ob die Bank diese Informationen per HBCI ueberhaupt uebertragen hat. Um das herauszufinden, braeuchte man die "rohen" HBCI-Nachrichten, so wie sie von der Bank gekommen sind. An die kommt man ran, indem man oben im Menü auf "Hibiscus->Erweitert->HBCI-Protokoll speichern..." klickt, dann das betreffende Konto auswaehlt und die Datei abspeichert.
Das Problem hierbei ist aber: Das Protokoll enthaelt nur die HBCI-Nachrichten der aktuellen Hibiscus-Sitzung. Du muesstest also vorher einmal Umsaetze abgerufen haben und in den empfangenen Buchungen muesste auch eine solche betreffende Buchung mit enthalten sein.
Poste diese Datei aber bitte auf keinen Fall hier im Forum. Sie enthaelt sehr sensible Informationen zu deinem Bankzugang. Du koenntest mir die Datei per Mail an hibiscus[at]willuhn.de senden. Kopiere in den Mailtext aber bitte den Link zu diesem konkreten Forum-Thread hier mit rein, damit ich den Bezug herstellen kann.



Nicht wirklich. Falls die Bank die gesuchten Informationen tatsaechlich liefert und sich das auch tatsaechlich als Aenderung in Hibiscus einbauen laesst, dann muesstest du warten, bis das Hibiscus-Update draussen ist, dann die betreffenden Umsaetze loeschen und diese nochmal rueckwirkend abrufen. Da die meisten Banken die Umsaetze aber nur 90 Tage rueckwirkend liefern, waere das das maximale Zeitfenster, in dem sowas rueckwirkend noch korrigiert werden kann. Wie gesagt - alles unter der Vorbedingung, dass die Bank diese Informationen ueberhaupt per HBCI ausliefert.

Danke für eure Antworten.

@infoman: CAMT-Abruf ist aktiviert gewesen

@hibsicus: Ich habe Hibiscus auf ein altes Backup zurückgesetzt und den Umsatz nochmal abgerufen. Das Protokoll gespeichert und schicke es per Mail. Der Empfänger vom Screenshot ist im Protokoll enthalten.

Hab deine Mail erhalten. Danke fuer's Extrahieren der relevanten CAMT-Daten aus dem HBCI-Datenstrom - das machts einfacher. Ich denke, das laesst sich so umbauen, dass Hibiscus den Wert aus "<UltmtCdtr><Nm>" praeferiert, wenn sowohl dieser als auch "<Cdtr><Nm>" angegeben ist. Ich denke, dass ich Montag dazu komme, das einzubauen.

Da es seit dem Abruf per CAMT ja auch endlich eine eindeutige Umsatz-ID gibt, wuerde es anschliessend beim rueckwirkenden Abruf der Umsaetze nicht mal zu Dopplern kommen. Hier muesstest du dann allerdings die alten Umsaetze nochmal loeschen, da Hibiscus sie sonst nicht nochmal anlegt, da es ja davon ausgeht, dass sie bereits vorhanden sind.

Ich gebe nochmal Bescheid, wenn ich es eingebaut habe.

Habe die Sache jetzt mal analysiert. So pauschal kann man es leider nicht implementieren, dass man automatisch "<UltmtCdtr><Nm>" bevorzugt, wenn es vorhanden ist. Bei meinem Konto (SPK) ist es naemlich so, dass "<UltmtCdtr><Nm>" im Wesentlichen nochmal die selben Daten enthaelt, wie in "<Cdtr><Nm>". Aber in haesslich. Naemlich nur noch Grossbuchstaben, verkuerzt auf 27 Zeichen und ohne Umlaute. Wenn ich das jetzt so einbaue, mache ich damit die Anzeige bei meinen eigenen Umsaetzen kaputt.

Eine wirklich brauchbare Loesung dafuer ist mir noch nicht eingefallen. Die Umsatz-Tabelle nur deshalb um eine Spalte "name2" ergaenzen will ich nicht. Denn auch in dem Fall muesste man ja entscheiden, welchen von beiden Namen man in der Umsatzliste anzeigt. Beide nebeneinander jedenfalls nicht. Bei meinem Konto wuerde dann zweimal hintereinander das selbe stehen - nur einmal davon in haesslich.

Man koennte das jetzt fuer den Benutzer konfigurierbar machen, sodass er - fuer den Fall, dass die Bank beide Namensfelder gefuellt hat - selbst entscheiden kann, welcher von beiden verwendet wird. Das muesste dann aber pro Konto konfigurierbar sein. Und wenn man dazu eine Option in der Benutzeroberflaeche anbietet, werden die meisten User zum einen nicht wissen, wozu diese Option gut sein soll. Zum anderen koennen sie vorher gar nicht wissen, in welchem von beiden Feldern ueberhaupt der "bessere" von beiden Namen steht. Und ob das pauschal fuer alle Umsaetze gilt oder nur fuer manche.

Hier sollte man vielleicht vorher mal in anderen Bankinganwendungen schauen, wie es dort geloest ist. ich will mit der Aenderung jedenfalls nicht meine eigenen Umsatzbuchungen verunstalten. Und bei der Sparkasse sind ja nun mal viele User.

Danke für deine ausführliche Analyse. Das Problem tritt nicht immer bei Lastschrift-Kartenzahlungen auf, sondern vermutlich nur, wenn das Buchungssystem des Einziehers es auf diese Weise übergibt.

Ich habe mir mal bei AlfBanco, StarMoney und GnuCash angesehen, was dort passiert. GnuCash arbeitet ebenso wie Hibiscus und die Informationen sind dort über die Oberfläche gar nicht anzeigbar. In AlfBanco haben sie ein Feld Name2 integriert, das nur bei den Details der Buchung sichtbar ist:



Bei StarMoney (ist ja meist von der Sparkasse empfohlen) gibt es einen abweichenden Auftraggeber:



Ggf. kann hier ein Feld im Bereich der sonstigen Informationen einer Buchung eingeführt werden?



Ich habe mir das Feld mal für die anderen Buchungen angeschaut und es scheint, wie du schon sagst, eher ein technisches Feld zu sein, wenn es denn überhaupt gefüllt ist. Mein Problem ist, dass ich für solche Buchungen momentan in Hibiscus gar nicht erkenne, um was es sich handelt. Zumindest könnte ich jetzt aber nach dem Abruf ins HBCI-Protokoll schauen und mir dann am Umsatz was im Notizfeld vermerken. Das wäre auch erstmal eine Art Workaraound, da solche Buchungen bei mir nur etwa 1x pro Monat auftreten.

Vielen Dank für deine Hilfe!

Danke fuer das Evaluieren der anderen Programme. Das hilft auf jeden Fall schonmal sehr beim Verständnis. Das Erweitern der Detailansicht der Buchung ist nicht das Problem. Sondern das Erweitern der Datenbank-Tabelle mit den Umsaetzen um eine weitere Spalte und die damit verbundenen Implikationen. Wenn man zwei Namensfelder hat, die potentiell beide befuellt sind, muesste man alle Stellen im Code anschauen, wo der Name einer Umsatzbuchung verwendet wird und die dann ggf. ebenfalls ergaenzen. Sei es der Export und Import von Umsaetzen in verschiedenen Dateiformaten, die Uebergabe an SynTAX, die Beruecksichtigung von weiteren Hibiscus-Addons, die Nicht-HBCI-Konten abfragen, die Suchfunktionen, die automatische Kategorisierung, ....
Da kommt schnell eine ganze Menge zusammen.

Fachlich sind die Hintergründe relativ einfach. Wenn man mit seiner Karte bezahlt, dann zieht nicht der Handler das Geld ein, sondern der Anbieter, über den das Terminal angeschlossen ist. Der ist damit der Lastschrifteinreichende und steht -im Idealfall - als Auftraggeber drin. Da er das nicht für sich macht, gibt es den UltimateCreditor, sprich der, der das Geld letztendlich bekommt. In der Regel der Handler.
Bei Kartenzahlungen ganz normales Geschäft.
Ähnliches gilt bei Hausverwaltungen, die für unterschiedliche Eigentümer einziehen. Wenn es formal richtig gelöst ist, dann ist das Mandat auf die Hausverwaltung ausgestellt und die zieht ein.
Das Ganze gibt es auch bei Überweisungen dort in der Regel bei Überweisungen von öffentlichen Kassen. Da sind sogar Kombinationen möglich, in der es einen abweichenden Auftraggeber und einen abweichenden Empänger gibt.
Wenn die Familienkasse bei der Arbeitsagentur angesiedelt ist, kann es sein, dass die Arbeitsagentur der Auftraggber des Kindergeldes ist, der eigentliche Auftraggeber (Abweichender Auftraggeber) aber die Familienkasse. Der Empfänger sind die Eltern, der abweichende Empfänger aber eigentlich das Kind.

BeimUmsatzinformationen im Format camt, gibt es entsprechende Tags Ultimate Debitor/Creditor und beim Mt940 +ABWE und +ABWA

Viele Grüße

Holger

Danke Holger - wie immer für das Hintergrundwissen ;)

Das möchte ich bestreiten!

Bei Mietverwaltung wird jede ernstzunehmende Hausverwaltung ein Konto lautend auf den Eigentümer eröffnen und mit diesem die Einzüge der Mieten im Auftrag des Eigentümers ausführen. Die Creditor-ID lautet auf den Kontoinhaber - also den Eigentümer.

Bei Wohnungseigentum lautet das Konto auf die Wohnungseigentümergemeinschaft - auch hier zieht die Hausverwaltung als bestellter Verwalter unter dem Namen der WEG ein - auch hier wieder Creditor-ID der WEG.

In keinem der Fälle wird ein Konto verwendet, das auf die Hausverwaltung lautet.

Das ist häufig so, SEPA kann aber auch anders ohne dass es wirklich komplizierter geht. Die Buchenden benötigen dazu auch Vollmachten am jew. Konto.
Es wäre z.B. aber auch möglich, dass die Hausverwaltung als Service-Rechenzentrum auftritt (wie DATEV) und die Buchungen lediglich einreicht. Viele Banken winken dann die eingereichten Lastschriften einfach durch.
Es gibt einige Optionen, alle mit unterschiedlichen Vor- und Nachteilen.
Gruß
Raimund

Klar, möglich ist viel. Und viele Banken machen auch viel. Besonders die, die mit der Materie "Immobilienverwaltung" wenig bis gar keine Ahnung haben (besonders die großen). Alle spezialisierten Banken, die die entsprechende Ahnung haben (Beispiele sind da die Hausbank München, die DKB oder die Aareal) eröffnen schon gar keine Treuhandkonten auf den Namen der Hausverwaltung/des Verwalters für WEGs. Einzig im Mietbereich könnte man das machen, ohne sich auf glattes Eis zu begeben. Aber auch da wird man es nicht machen, wenn es nicht aus irgendwelchen Gründen sein muß. Dass die Verwaltung Vollmachten auf den entsprechenden Konten benötigen ist ja sowieso klar und kein Problem.

Vielleicht kannst du vorerst eine zusätzliche Tabelle anlegen, in der beim Abruf der Umsätze die aktuell noch nicht im sonstigen Code berücksichtigten Felder in generischer Form abgelegt werden. Und darauf aufbauend evtl. einen erweiterten Export für interessierte Benutzer. Diese Zusatztabelle hat in meiner Vorstellung
- eine Spalte (oder mehrere) für die Zuordnung zum zugehörigen Datensatz in der bisherigen Tabelle
- eine Spalte "Attribut"
- eine Spalte "Ausprägung"

So ließen sich die aktuellen zusätzlichen Infos (und auch zukünftig hinzukommende) zumindest schon mal speichern, ohne dass sie stören, hoffe ich. Ob, wie und wann sie dann in die Benutzeroberfläche und andere Programmfunktionen integriert werden, kann dann immer noch überlegt werden...

Genau so eine Tabelle gibt es in Hibiscus bereits. Sie wird uebergreifend fuer die Speicherung von Meta-Informationen verwendet, die zwar irgendwie einem Datensatz zugeordnet sind, es aber zu aufwaendig waere, fuer jede dieser Informationen die entsprechenden Tabellen um neue Spalten zu erweitern. Den zweiten Namen in dieser extrem normalisierten Form zu speichern, geht bei den Umsaetzen aber aus Performance-Gruenden nicht. Die Umsatztabelle kann etliche tausend Datensaetze enthalten. Wenn da zu jedem einzelnen ein Join auf diese Meta-Tabelle gemacht wird, erhoeht sich die Ladezeit der Umsatzliste erheblich. Es waere auch keine sinnvolle Uebergangsloesung, weil eine aufwaendige Migration noetig waere, um die Daten irgendwann doch in eine Spalte in der Umsatz-Tabelle zu verschieben.

Die saubere Loesung ist schon, die Umsatz-Tabelle um eine neue Spalte zu erweitern. Ich habe es mal notiert, werde es aber in der kommenden Version 2.8.9 vermutlich noch nicht einbauen sondern in der darauffolgenden Version.

Die Art der Tabelle soll ja gerade verhindern, dass immer wieder zwingend neue Spalten erforderlich werden. Und zunächst mal nur sicherstellen, dass die Daten in der Datenbank landen, ohne bei jedem Abruf (sofern Bedarf besteht) das HBCI-Protokoll bemühen zu müssen, wie es hier als Workaround schon beschrieben wurde.


Mir würde es reichen, wenn die zusätzlichen Informationen überhaupt automatisch ihren Weg in die Datenbank finden, und zum Beispiel durch einen - von mir aus extrem langdauernden - "erweiterten csv-Export" zugreifbar gemacht werden könnten. Das stelle ich mir angenehmer und sicherer vor, als HBCI-Protokolle zu lesen.

Es mag ja sein, dass das für deinen Use-Case ausreichen würde. Wenn ich neue Features einbaue, muss ich aber das gesamte System, ggf. damit einhergehende Auswirkungen auf andere Stellen im Programm sowie die Zukunftsfähigkeit des neuen Features beachten. Sonst wird Hibiscus irgendwann ein unüberschaubares Flickwerk. Und bei diesem zweiten Namensfeld macht es aus meiner Sicht keinen Sinn, "erstmal" irgendeinen schnellen Workaround einzubauen, damit du es für deinen Use-Case nutzen kannst. Ich muss hier auch alle anderen User und die Wartungsfähigkeit des Programms im Blick behalten.

Ja, das verstehe ich natürlich. Meine Anregungen waren auch weniger aus meinem "Use-Case" geboren, sondern vor allem aus der Überlegung heraus, wie man bei neuen Informationstypen möglicherweise kurzfristig "Datenkonservierung" (nach den hier an verschiedenen Stellen genannten 90 Tagen wohl nicht mehr möglich) implemenmtieren könnte, ohne gleich sämtlichen Code abklopfen zu müssen. Wenn dies die Wartbarkeit des Programms zu sehr gefährdet, ist das natürlich keine gute Option.

Gab es inzwischen eine Anpassung, damit in den Umsätzen die Daten aus dem Feld "UltmtCdtr" angezeigt werden können? Wenn ja, wie kann ich das ändern und wenn nein, wann könnte ich damit rechnen oder ist eine solche Anpassung nicht geplant und es wird weiterhin "Cdtr" angezeigt?

https://www.willuhn.de/wiki/do…0_27112020
Gleich die erste Zeile.