Hi, I just tried to map my online banking accounts to gnucash accounts. Because of PSD2 online banking stopped working in gnucash 3.6. So I waited for 3.8. Steps: 1 Open Tools->Online banking assistant 2 Next button 3 Next button (Aqbanking was already configured.) 4 I see my two accounts. The column "gnucash account name" is empty for both. 5 I doubleclick on one of the accounts and select the correct gnucash account. 6 The column "gnucash account name" shows the selected account. The checkbox in the "New?" column is checked. Its not possible to uncheck it. 7 Next button 8 Apply button. Assitant closes. 9 Select my mapped gnucash account. Select Actions->Online actions->balance (or somthing else) 9 Messagebox "The online action "balance" is not available for this account" 10 If execute Steps 1 to 4 again. The column "gnucash account name" is still empty. Maybe this happens because I already had a mapping with a prior version of aqbanking and gnucash? Maybe I can clear the existings mappings somewhere? I use the sqlite backend btw. Regards, Thomas I had to configure aqbanking again.
BTW. The menu names and messages may differ because I translated them from german to english.
Now I got it to work again. I needed to do the following: - Open aqbanking-assistant. - go to accounts tab - select account and "Edit account" - press the button under "get SEPA information" under "special actions". No aqbanking gets the account information and gnucash can ask aqbanking for the limit of the online actions. I think it couldn't hurt if the error message hints the user to do this. The UI-error above remains. But the mapping was made. The UI of the online banking assistant just doesn't show it properly.
I played with this a bit (though with OFX, since I'm American) and found that the account linkages were getting written to the book and that the GnuCash accounts recognized that they were set up for online banking (if Actions>Online Banking... items aren't grayed out then it recognizes that it's set up). That indicates that the Online Banking Setup dialog has a problem reading the slots.
Created attachment 373565 [details] Patch for function aai_match_page_prepare Hi, the attached patch has fixed the UI issue for me. In function aai_match_page_prepare the hash table holding the mapped gnucash accounts is initialized with the references of the glib functions g_direct_hash and g_direct_equal. g_direct_equal seems to compare the object references for equality check which is too restrictive in this case. I have added a dedicated equal function (and hash function too) which uses the aqbanking unique id instead of the object reference. Regards, Peter
There was a new release of AQBanking about two weeks ago and a reporter of bug 797545 reported that it resolved his problems. It's in the Windows and Flatpak nightlies, please test and report back.
Hi John, I have just tested GnuCash freshly built on Debian Linux 10.3 from git (commit dd18128 from yesterday) with Gwenhywfar 5.2.0.0 and AqBanking 6.1.0.0 and the issue still persists. Beside the display issues of the account matching within the online banking setup wizard there are other problems with the aqbanking account matching in Gnucash, which I have tried to describe in my posting to gnucash-user@gnucasg.org on Sunday (see https://lists.gnucash.org/pipermail/gnucash-user/2020-February/089291.html for details): In order to reproduce the issue proceed as follows: Just assign a gnucash account to an aqbanking account by selecting the gnucash account from the account tree on the "Match Online accounts with GnuCash accounts" page of the online banking setup wizard. It will show the matched gnucash account afterwards in column "GnuCash Account Name" with its full path. Now proceed to the "Online Banking Setup Finished" page and press "Apply", which leaves the online banking setup wizard. Now call the online banking wizard again and proceed to the page "Match Online accounts with GnuCash accounts". With my gnucash version the column "GnuCash Account Name" will be empty now although the mapping is still stored within the SLOTS table. What is the (GnuCash) code base for the Windows and Flatpak nightlies? Do they contain changes which are not (yet) in the git maint branch? Regards, Peter
Thanks for testing. The nightlies are builds from the git maint and master branches at the time of the build, no pull requests included. I think your patch is an important improvement, depending on an external library's object ptr to be stable over multiple calls is obviously brittle and the AB_ACCOUNT_SPEC_UNIQUE_ID is what is stored in KVP.
That's good to hear. I'm currently working on a more comprehensive patch covering also the issue which I have mentioned in my posting (see above). I'm not yet satisfied with the solution but I may upload it tomorrow to serve as a basis for a discussion. I'm also not fully satisfied with the AB_ACCOUNT_SPEC_UNIQUE_ID as basis for the KVP, but currently I have no better idea. It may cause trouble if multiple users work with the same GnuCash file (at different point in times, of course), because the AB_ACCOUNT_SPEC_UNIQUE_ID will be stable only with respect to a single user (AqBanking configuration).
Well, stable to a single instance created by the AQBanking setup wizard. As long as that instance is copied around to all of the $HOMEs from which GnuCash might be run everything will work OK. I guess in an ideal world we'd use the IBAN, but in our real world that's not always readily available.
Created attachment 373585 [details] Improved patch for the matching of online (AqBanking) accounts to GnuCash accounts This is an improved patch for the matching of online accounts to GnuCash accounts. It consists of the following changes: Dedicated functions aai_ab_account_hash and aai_ab_account_equal in guncash/import-export/aqb/assitant-ab-initial.c to calculate the hash value of an AqBanking account and to test two AqBanking accounts for equality by comparing their unique ids, respectively. They are used in function aai_match_page_prepare to replace the functions g_direct_hash and g_direct_equal and in function clear_line_cb to to replace a comparison pf pointers. In function account_list_clicked_cb I have changed the logic such that the matched GnuCash account is removed from the AqBanking account if the account tree selection dialog is returned with the OK and the same GnuCash account. This implements a kind of toggle mechanism, which of course is far away of beeing intuitive, but which was easy to implement for me without changes to the UI. A better solution would be to enable the account selection tree to be left without any account marked on OK. The code in account_list_clicked_cb was already prepared for that. Another alternative would be an explicit "delete mapping" button on the list of matched accounts. With the existing implementation I have found no way to remove an erroneously mapped AqBanking account from a GnuCash account without assiging it to another GnuCash account. In callback function clear_kvp_acc_cb I have replace the setter functions, which have set the account unique id, the account number, and the bank code by a call to function gnc_account_delete_map_entry, which removes all 'hcbi' KVPs of the GnuCash account including also the 'hbci/trans-retrieval' value. I have figured out that it is not possible to clear the account unique id by the existing setter function: A zero integer passed to the function seems to be interpreted as a NULL value and does not lead to a change. With the previous change the last retrieval date for online transaction was cleared for every change to the online account matchings. For that reason I have tried to optimize function aai_on_finish that it does not traverse the whole account hierarchy for the clear_kvp_acc_cb callback function but calls is only for those GnuCash accounts which have lost their AqBanking account. I think in this case it is also justified that 'hbci/trans-retrieval' is deleted as well. I have also changed function test_acct_online_id_match to look for an already existing AqBanking account info (from the online account matching wizard) in order to derive and create a new online ID for the account without user interaction. This avoids asking the user for an assignment during the first online retrieval of the account balance or account transactions. For that reason I had to also include header "aqb/gnc-ab-kvp.h" in source file gnucash/import-export/import-account-matcher.c in order make use of the already existing implementation of the create_online_id function. This seams to be a little bit unclean to me with repect to the software layering. But I have no better idea. If you try to take over this patch for the stable branch please review it carefully. I'm neither an experienced C programmer nor a deep expert of the GnuCash architecture and I might have overlooked some drawbacks. At least the patch has solved all the issues which I have found in combination with the online account matching (see also https://lists.gnucash.org/pipermail/gnucash-user/2020-February/089291.html for more details).
Please break that up into separate commits (and therefore separate patches) for each issue. The commit for this bug should use the bug summary ("Bug 797540 - Mapping of aqbanking accounts to gnucash accounts doesn't work") as its commit summary. It will be much easier to review and provide detailed feedback if you'd make a github pull request out of the result.
Hi John, I will follow your advice and go for a pull request. Because I have never done this before it my take some time. Eventually, I will come back to you for questions. Regards, Peter
Hi John, I have just created pull request https://github.com/Gnucash/gnucash/pull/649. Please let me know if something is wrong or missing. If this is OK I will put the remaining fixes into another pull request. Regards, Peter
Comments on the PR. Thanks.
The PR is merged.
