GNOME Bugzilla – Bug 548601
AqBanking Import: Obscuring zero balance windows after getting transactions
Last modified: 2018-06-29 22:08:59 UTC
Vincent Smeets <vincent.vsmeets@gmail.com> reported a problem when importing transactions using HBCI, which I hereby confirm (I can reproduce them). The original bug report: I am using Gnucash with HBCI with a chipcard to get access to my accounts on the German bank with BLZ 26650001. Before this version, I used the package(s) gnucash-hbci_2.2.4-2~hbci.1_amd64.deb from http://aqbanking.alioth.debian.org/debian/unstable/ which worked fine. Now when I get the transactions, the following happends: - Gnucash is getting the transactions from the bank. - The window with the transaction to match is opened, but directly pushed to the background. This window in now blocked/locked! - The foreground gets a dialog with the question "The bank has sent balance information in its response. Do you want to import it?". - After answering Yes: a new dialog is opened stating that the new balance is 0,00 and asking to correct the balance. (The value 0,00 is incorrect) - After answering Yes: a window/dialog is opened to reconsile the account. It wants to reconcile to the incorrect balance of 0,00. Now the background window isn't locked anymore. - Both windows can now be closed and the new transactions are imported. You can't reconcele them because the balance was incorrect. - Now I can start a separate action to get the online balance and reconcile the account. A separate action will report the correct balance and reconciling will succeed. There are two problems described here: First: When I get the online transactions, I also get a new balance reported. The value is however always 0,00. Is this an error of the bank or is Gnucash returning a value where there was no value sent by the bank? Second: In case a correct balance value is received by Gnucash, then the order of dialogs should be: Import and match the transactions and after that use the balance to reconcile the account. Now the dialogs for reconciling are blocking the import of the transactions. Thank you for your work. In case you need log files, just say what and how to produce them. Regards, Vincent Smeets
Just a note to add: I suggest a new configuration option which, when retrieving transactions from the bank, imports balances only if they are not zero (by default). If this option is active it shouldn't even ask to import zero balances on transaction retrieval.
Just for the records: The according Debian bug report is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495709
Created attachment 117041 [details] [review] Don't import unawaited zero balances The first problem described here should be possible to fix. The attached patch checks whether an unawaited balance is zero and simply ignores it in this case. This should be a sane solution even without a special configuration option, which would allow to import a very unlikely yet expected zero balances when retrieving *transactions* (i.e. not retrieving a balance *right now*). Actually I can't imagine someone really wants this. *g* The patch does not change the behaviour if the balance is non-zero. The second problem probably depends on the order in which the data arrive from the bank. As I understand it Gnucash has no means to influence the order in which the callback functions bal_accountinfo_cb() and txn_transaction_cb() get called by the underlying library AqBanking. But all this is based on assumptions made without deeper investigations. CAUTION: The patch still needs to get tested. I haven't tested it on my own yet. Micha
Gnucash crashes with this patch. :(
Created attachment 117045 [details] [review] Don't import an unawaited zero or NULL balance This patch now works for me.
Looks reasonable. I will probably merge the two if clauses and commit it later this week. Thanks!
If you're going to merge the two if clauses just make sure lazy evaluation is in force... :) Micha
That is C. Is there anything else to keep in mind?
No.
Oh, I forgot to mention: Applied to trunk as r17495 five days ago :-) Awaiting backport to branches/2.2 for inclusion in GnuCash 2.2.7. Thanks Micha.
Applied to branches/2.2 as r17544.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=548601. Please update any external references or bookmarks.