[gnucash-de] [Aqbanking-user] Transaktionsabruf funktioniert unter Gnucash nicht

[Rainer Dorsch]

Danke Peter,

das hat mich zumindest auf die richtige Spur gebracht.

Der letzte Abruf war bei mir hier zu alt, beim manuellen Datum stand 2009 (!). 
Als ich das geändert habe, hat es funktioniert.

Leer-Abrufe bei Diba führen aber zum gleichen Problem. 

Interessanterweise werden Leerabrufe bei einem DKB Konto korrekt erkannt und 
angezeigt.

Gruß
Rainer

Am Mittwoch, 20. Mai 2020, 21:01:08 CEST schrieb Peter Zimmerer:
> Hallo Rainer,
> 
> ich vermute, das ist nur eine irreführende Meldung in Gnucash.
> "rejected(5)" tritt bei mir immer dann auf, wenn der Umsatzabruf leer
> ist - also seit dem letzten Abruf keine neuen Umsätze hinzugekommenen sind.
> 
> Ändert sich denn das Verhalten, wenn Du beim Umsatzabruf in Gnucash das
> Von-Datum statt auf "Letztes Abrufdatum" explizit auf den Datumswert der
> letzten erfolgreich abgerufenen Buchung setzt? Die Buchungen von diesem
> Tag müssten dann bei einem erneuten Abruf wieder mit übertragen werden
> und dafür sorgen, dass der Umsatzabruf nicht leer ist.
> 
> Gruß,
> Peter
> 
> Am 20.05.20 um 19:01 schrieb Rainer Dorsch via Aqbanking-user:
> > Hallo,
> > 
> > ich habe hier einen seltamen Fall, bei dem dem der Kontostandsabruf
> > tadellos unter aqbanking-cli und gnucash funktioniert.
> > 
> > Der Transaktionsabruf funktioniert mit
> > 
> > aqbanking-cli request -b <BLZ> -a <Konto>  --transactions
> > 
> > tadellos, aber unter gnucash erhalte ich einen rejected(5) Status.
> > 
> > Folgendes log erhalte ich von gnucash:
> > 
> > Encoding queue
> > Sending message
> > Mit Server verbinden...
> > Hostname "fints.ing-diba.de" wird aufgelöst...
> > IP-Adresse ist "194.127.138.150"
> > Verbindung zu "fints.ing-diba.de" wird aufgebaut
> > Verbunden mit "fints.ing-diba.de"
> > Verwende GnuTLS Default Ciphers.
> > TLS: SSL-Ciphers ausgehandelt: TLS1.2:ECDHE-RSA-AES-256-GCM:AEAD
> > Verbunden.
> > Nachricht senden...
> > Nachricht gesendet.
> > Message sent
> > Queue sent
> > Waiting for response
> > Antwort wird empfangen...
> > HTTP-Status: 200 (OK)
> > Antwort empfangen.
> > Beenden der Verbindung zum Server...
> > Verbindung beendet.
> > Response received
> > HBCI: 0100 - Der Dialog wurde beendet. (M)
> > HBCI: 0020 - Benutzer abgemeldet. (S)
> > Dialog wurde nicht abgebrochen, PIN scheint gültig zu sein
> > Datei wird eingelesen...
> > Lese SWIFT Dokument 1
> > Analysiere SWIFT Daten
> > Importieren SWIFT-Daten
> > SWIFT-Dokument erfolgreich importiert
> > Lese SWIFT Dokument 2
> > Analysiere SWIFT Daten
> > Data imported, transforming to transactions
> > Buchung wird hinzugefügt
> > Buchung wird hinzugefügt
> > Buchung wird hinzugefügt
> > Buchung wird hinzugefügt
> > AqHBCI abgeschlossen.
> > Unlocking customer "1772"
> > 
> > Ich nutze die offiziellen backports Pakete von Debian 10 (vielen Dank,
> > Micha!).
> > 
> > rd at h370-wlan:~$ dpkg-query -W|grep aqbanking-tools
> > aqbanking-tools 6.1.3-1~bpo10+1
> > rd at h370-wlan:~$ dpkg-query -W|grep gnucash-common
> > gnucash-common  1:3.10-1~bpo10+1
> > rd at h370-wlan:~$
> > 
> > Hat jemand irgendeine Idee woher die Diskrepanz kommt?
> > 
> > Danke und Gruß
> > Rainer


-- 
Rainer Dorsch
http://bokomoko.de/