Gnucash / aqbanking / DKB Debit

Das ist wohl ein spezifisches Problem von Gnucash. Im Datensatz gibt es einen "Zahlungsempfänger" und einen "Alternativen Zahlungsempfänger". Offenbar trägt Dein Programm grundsätzlich den Zahlungsempfänger in die Datenbank ein. In dem steht - was letztlich auch stimmt - immer DEUTSCHE KREDITBAK AG drin. Denn der Betrag wird ja ins Debit-Karten-System der DKB bzw. von VISA umgebucht. Im Alternativen Zahlungsempfänger steht dann der Händler drin, der die Kreditkartenbealstung eingereicht hat. Also z.B. "PETER SIMMEL HAND.GMBH/MUENCHEN//DE".

Andere Programme - wie z.B. Subsembly Banking trägt sofern beide Angaben im Datensatz sind, in dem direkt sichtbaren Empfänger den Alternativen Empfänger und zusätzlich noch in ein anderes Feld den Zahlungsempfänger ein.

Insofern liefert die DKB die nötigen Angaben durchaus, aber eben in einem Feld, das Dein Programm offenbar ignoriert. Ich fürchte, da muss eine kleine Programmänderung her.

Bei der Girocard wird übrigens der Zahlungsempfänger immer im ersten Feld eingetragen, da ja das der direkte Empfänger ist.

Danke an msa und infoman, beides gute Hinweise.

6.5.3 lt https://www.aquamaniac.de/rdm/projects/aqbanking/files

des weiteren auf CAMT stellen

CAMT ist nicht mysteriös

CAMT ist das aktuelle Dateiformat für die Übertragung von Umsätzen seit SEPA. Seit dem gibt es ja diverse neue Felder, die es im alten Dateiformat (MT940, manchmal auch STA genannt) nicht gab. Seit SEPA mussten diese neuen Daten irgendwo untergebracht werden. Dies geschah beim alten Format durch Einfügen der neuen Feldinhalte in dem Verwendungszweck zusätzlich - was aber eine sinnvolle Auswertung und Übernahme in die lokale Umsatzdatenbank erschwerte bzw. unmöglich machte. Deswegen das neue Format, das inzwischen von fast allen Banken unterstützt wird und in dem die einzelnen Felder wieder ordentlich eingestellt sind und erkannt werden können.

Ob ausgerechnet Dein Programm im Falle der DKB mit dem neuen Format die Anzeige richtig hinbekommt kann ich nicht sagen, da ich das nicht nutze. Allerdings kann man sagen, dass in eigentlich allen anderen Programmen dieser Weg zum Erfolg führt und warum sollte es bei aqbanking anders sein - wenn die ja CAMT offenbar auswählbar haben. Vielleicht meldet sich ja noch jemand mit aqbanking und DKB - aber ich habe da eher wenig Hoffnung, weil hier wohl nur sehr wenige Nutzer dieses Programms schreiben.

Vielen Dank für die Erklärungen bisher. Ich habe mich nun doch schonmal ans compilieren gemacht. Wer wie ich, das äußerst selten macht muss natürlich einige Pakete nachinstallieren das melden die 'configure' Befehle aber.
1 & 2 sind durchgelaufen (Standardanweisung aus der Readme-Datei)
bei 3 bin ich noch am rätseln, da gnucash, die "Normalinstallation 3.8x', (nicht flatpack, die ist ja abgeschottet) immer noch 6.0.1, und nicht 6.5.3 meldet.
aqbanking-cli zeigt auch nur eine Fehlermeldung an, Habe wohl etwas vergessen. Rätsel aber noch, woran es liegt, dass aqbanking nicht richtig eingebunden ist.

Tips willkommen , auch wenn das hier kein "Installationsproblem" Forum ist.
Gruß
Crom

Danke an Infoman, auch wenn ich erstmal meinen Pfad weitergegangen bin, sogar mit Fortschritten.

* Das "INstallationsproblem" saß wohl zunächst einmal vor dem Monitor.
* Heute griff gnucash nämlich auf aqbanking 6.5.3 zu
* da war warscheinlich letzthin irgendetwas nicht aktualisiert bzw. eines der Programme lief noch und hatte die alte Bibliothek dadurch gesperrt oder im RAM -
* aber nach dem booten lief es.

Also schon mal gelernt - nach der aqbanking update vielleicht einmal booten wenns nicht läuft

Habe dann auch das nun unmysteriöse CAMT-Häkchen gesetzt
* und musste noch die BIC meiner Bank in aqbanking händisch nachtragen (da meine Installation die Bank-Datenbank nicht hat ... hmmm... warum auch immer... und ich beim erstenmal aqbanking wohl zu faul war, alles einzutragen, was sich nun per MOB90000000066-Fehler rächte... kurios dass es ohne "CAMT" aber ging)
* und dann rief gnucash die Kontoumsätze ab!

DIe eigentlichen gewünschten Informationen (den alternativen Zahlungsempfänger) hat gnucash aber trotzdem nicht im Angebot ... grrr... also derzeit Ziel (noch?) nicht erreicht.

Hat jemand noch einen Tipp?

Beste Grüße
Crom

hibiscus wäre ja auch eine Alternative, dort funktioniert es
siehe ua. diesen Thread wo es ja genau um die DKB debit-Problematik ging topic.php?t=25281

die dortige bzw. grundsätzliche Lösung:
neuster Software-Stand (da neue Funktionen/Felder benötigt werden - die bspw. bei h/j jedoch schon seit geraumer Zeit vorhanden sind)
Umstellung auf CAMT (neustes/aktuelle Format des Datenaustausch - siehe https://de.wikipedia.org/wiki/Camt-Format )
BPD/UPD löschen (nicht Konto/Kontumsatz) bzw. den Bankenzugang neu anlegen (damit Basis-Daten von Bank neu abgerufen werden)

... hat mich noch nicht ganz losgelassen:

Ich konnte zumindest verifizieren dass die Information in aqbanking enthalten ist
aqbanking-cli request --account=<hier Kontonummer einfügen> --fromdate=20220701 --transactions
hatte eine Zeile: "char ultimateCreditor="Aral Station xxxx".

Witzigerweise fand ich googelnderweise (nach "ultimateCreditor"), dass gnucash ab 4.12 diese information einbezieht
https://bugs.gnucash.org/show_bug.cgi?id=798385
und den gelösten Bugreport dafür in den Releasenotes für 4.12.... und konnte den Codeabschnitt sogar im Quellcode finden...

Da sitzt der Programmierfehler doch mal wieder vor dem Monitor... help welcome

(Nachtrag: auch bei der GnuCash-Flathub-version 4.12, die ich gerade ausprobiert habe, ist die information weiterhin nicht enthalten)

Bei dem Zeit-Einsatz kannst eine kommerzielle Software oder halt eine Alternative verwenden wie bereits oe. topic.php?p=164101#real164101