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

[Peter Zimmerer]

Hallo Rainer,

ich hatte mich an das Verhalten schon (fast) gewöhnt. Jetzt habe ich mir
die Verarbeitung aber doch noch mal genauer angeschaut:

Die Ursache des Problems liegt wohl in Aqbanking und zwar in der
Funktion AH_Job_HandleResults_Empty. Eine Umsatzanfrage, die im
angeforderten Datumsintervall keine Umsätze liefert, gibt keinen
Rückmeldungscode 0020 (Auftrag ausgeführt) zurück sondern stattdessen
den Rückmeldungscode 3010 (Es liegen keine Einträge vor). Dieser wird
aber in der o.g. Funktion nicht als erfolgreich angesehen. Vielleicht
hängt das Rückmeldeverhalten auch noch von der Bank(-Software) ab.

Der beigefügte Patch sollte das Problem lösen. Zumindest erhalte ich
dann bei mir in Gnucash bei der Consorsbank auf eine leere Umsatzabfrage
wie erwartet die Meldung "Es liegen keine Buchungen für die gewählte
Zeitspanne vor.".

Gruß,
Peter

Am 20.05.20 um 23:55 schrieb Rainer Dorsch via Aqbanking-user:
> 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
> 
> 
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : empty_transaction_list.patch
Dateityp    : text/x-patch
Dateigröße  : 705 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20200521/b85472a5/attachment-0001.bin>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20200521/b85472a5/attachment-0001.sig>