GNOME Bugzilla – Bug 339504
hbci does not import data
Last modified: 2018-06-29 21:02:10 UTC
Please describe the problem: in version 1.9.4 and 1.9.5 hbci is not working. The connection with the server produces the same output, but while in 1.9.3 the dialog to assign the transactions to accounts is shown, nothing happens now. Steps to reproduce: 1. choose Online Actions - Get Transactions from the Actions Menue 2. type Password 3. Actual results: nothing Expected results: Dialog "Generic import transaction matcher" is opened Does this happen every time? yes Other information:
Thanks for reporting this bug. However, I cannot reproduce this here -- HBCI "Get Transactions" was working fine with every 1.9.3, 1.9.4, 1.9.5, current SVN. Also, there hasn't been any HBCI-related changes between 1.9.3 and now. I therefore doubt whether this is related to the gnucash code. So let's find out where this comes from. Did you change anything in your installation of aqbanking or gwenhywfar recently, e.g. did you update any of them? Also, which type of HBCI security medium do you use -- PIN/TAN, keyfile, chipcard? When you start gnucash-1.9.5 from the command line and try the HBCI functions, do you get any messages on the terminal (that appear because of the HBCI function)? If yes, please copy them here. Also, you said you "type password", so I guess you mean the "HBCI log window" appears and shows some log messages. Is this correct? The point is that if you get as far so the HBCI question "please type password" appears, then from the gnucash side everything is functioning correctly. In the "log window", can you please unmark the checkbox "close this log window after connection finished" so that the log window stays open, and can you then copy&paste the log message to here? This usually doesn't contain any private information.
I use the PIN/TAN method. I changed from 1.9.3 to 1.9.4 to 1.9.5 and back to 1.9.3 several times and while the output in the log window is the same for all versions, only in version 1.9.3 the dialog "Generic import transaction matcher" is opened. So maybe the data from the hbci server is not parsed correctly? It looks as if the connection to the server is closed successfully and only then the error occurs. I have not changed aqbanking (1.0.8) or gwenhywfar (1.11.0) since I compiled version 1.8.11 and everything works up to version 1.9.3 Here is the output from the log window. I hope it's not a problem that the output is in german. Dialog mit dem Server eröffnen Aufträge werden vorbereitet Aufträge werden gesendet Verbindung hergestellt mit xxx.xxx.xxx.xxx (Port 443) Auf Antwort warten HTTP-Status: 200 OK Antwort erhalten HBCI: 3060 - Teilweise liegen Warnungen oder Hinweise vor (HBMSG=10336) (M) HBCI: 0020 - Der Auftrag wurde ausgeführt (S) HBCI: 3914 - Für Sie wurde eine neue TAN-Liste erstellt. (MBV07390100001) (S) Received account: xxxxxxxx / Sichteinlagen Aufträge werden vorbereitet Aufträge werden gesendet Verbinde erneut Auf Antwort warten HTTP-Status: 200 OK Antwort erhalten HBCI: 3060 - Teilweise liegen Warnungen oder Hinweise vor (HBMSG=10336) (M) HBCI: 0020 - Der Auftrag wurde ausgeführt. (S) HBCI: 0020 - Die gebuchten Umsätze wurden übermittelt. (S) HBCI: 3914 - Für Sie wurde eine neue TAN-Liste erstellt. (MBV07390100001) (S) Dialog mit dem Server beenden Aufträge werden vorbereitet Aufträge werden gesendet Verbinde erneut Auf Antwort warten HTTP-Status: 200 OK Antwort erhalten HBCI: 0100 - Dialog beendet (HBMSG=10346) (M) SWIFT: Reading complete stream SWIFT: Parsing data Abgeschlossen. Output on the console from command gnucash --debug 3:2006/04/23 23-55-13:aqbanking(16113):wcb.c: 118: Logging this: 2/6 SWIFT: Reading complete stream 3:2006/04/23 23-55-13:aqbanking(16113):wcb.c: 118: Logging this: 2/6 SWIFT: Parsing data
I'm confused. Do I understand correctly: It works with 1.9.3, but it does *not* work with 1.9.4? There has been one single change in the hbci-related code, http://svn.gnucash.org/trac/changeset/13687, but this should really *only* affect whether the log window automatically closes every time or (after the change) it stays open if any warning has been displayed during the connection. Nothing here is related to the question how the received data is being processed or not, which in turn will display the "generic transaction matcher" dialog. According to the gnucash code, there shouldn't be any difference here between 1.9.3 and 1.9.4. However, in my opinion an aqbanking >= 1.3.0 should probably required by gnucash anyway. This will soon be a requirement of gnucash. If the error is still there, I would kindly ask you to upgrade your aqbanking to 1.3.0 or newer (aqbanking-1.3.0 requires gwenhywfar-1.16.0) and the most recent is aqbanking-2.0.0 (requiring gwenhywfar-2.2.0). The good news for you is that there isn't a separate aqhbci package anymore with aqbanking>=1.3.0. More information on that upgrade also on http://linuxwiki.de/GnuCash and http://wiki.gnucash.org/wiki/Upgrade_from_1.8.9_to_1.8.10_and_HBCI_online_banking_support
I can confirm this behaviour, but it seems it's not gnucashs fault. I use aqbanking 2.0 and gwen 2.2, in both versions (1.9.3 and 1.9.5) of gnucash it shows up the following error messages on console when reading transaction data: 3:2006/04/27 20-50-10:gwen(26243):netlayer.c: 1608: Not connected 3:2006/04/27 20-50-11:gwen(26243):netlayer.c: 1608: Not connected 3:2006/04/27 20-50-11:gwen(26243):nl_ssl.c: 404: Socket is inactive: disconnected (4) 3:2006/04/27 20-50-11:aqhbci(26243):dialog.c: 628: Could not disconnect from bank (-6) However the reading out in 1.9.3 works anyway and the import dialog pops up. version 1.9.5 got more restrictive with the introduced loglevel check. when I switch back return (i->msgBoxError != 0) || (i->min_loglevel < AB_Banking_LogLevelNotice); to return (i->msgBoxError != 0); in GNCInteractor_hadErrors, gnucash 1.9.5 works for me too. Maybe it's only a dirty workaround and the real problem should be fixed in gwen or aqbanking, but I don't know how to track that down. On the other hand qbankmanager and kmymoney2 are working well and ignore these errors too.
Congrats, Marcel in comment#4 ! Your proposed workaround in the loglevel check pointed out to me that my statement in comment#3 was incorrect, and the code I had introduced in fact broke the transaction download. I'll commit a fix to this immediately. Fixed in r13867 and the upcoming 1.9.6.
Thank you for the quick fix, I checked out the trunk version and hbci now works again. I updated aqbanking to version 2.0, which was really a pain, but that's another story.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=339504. Please update any external references or bookmarks.