GNOME Bugzilla – Bug 792452
Can't do SEPA Transactions via online-banking
Last modified: 2018-06-30 00:03:00 UTC
I try to fill out the dialog for SEPA transactions and get the following message at each character I input: "Your local bank account does not yet have the SEPA account information " "stored. We are sorry, but in this development version one additional step is " "necessary which has not yet been implemented directly in gnucash. Please " "execute the command line program \"aqhbci-tool\" for your account, as " "follows: aqhbci-tool4 getaccsepa -b %s -a %s" I also execute the command line program as described but no success. This also happens with version 2.7.3. I use the German version
I use aqbanking version 5.7.6beta
It also happens in version 2.7.6 at Debian
Created attachment 369816 [details] [review] Don't require both IBAN and BIC, updated error message. Here's a patch to allow having only IBAN and to fix the error message to tell the user to fix the account in Online Banking Setup. The need to run aqhbci-tools has been gone for a long time.
My mail to the de community: https://lists.gnucash.org/pipermail/gnucash-de/2018-March/010228.html As far as I understand the problem: Traditional intl. transfer used SWIFTs BIC to address the bank + account number. The EU started SEPA, where all information is put in the IBAN: <RR><CC><NBAN> Region, checksum, national account number. Many other countries adopted the IBAN: https://en.wikipedia.org/wiki/International_Bank_Account_Number#/media/File:IBANMap-World6.svg Until the national banking organisation explain to SWITF, how mapping between BIC and IBAN is done, there is a transistional period, where the target BIC must be sent additionally with the IBAN. On 2016-01-01 the transitional period was finished for the core SEPA countries (every blue on the map). Inside this room the BIC is no longer required. An intl. transfer is like a transaction: source-IBAN, target-IBAN, Amount&Currency, Description and other text. Now to Gnucash: Source IBAN, Source BIC, bank server address, ... are stored in the aqbanking configuration. As long as there is no IBAN found, the GC-dialog should fail as before. If IBAN is found, the process should continue. (are the parameters of aqb-calls correct without sender BIC?) Inside the SEPA room the transfer should not fail (if all other conditions are met like enough money in the account) I don't know, if Swift registered (red) means transition period is finished. For other countries, the transfer should /somewhere/ fail, requesting the missing BIC, if it is not autocompleted by the bank or SWIFT.
Of the two backends that AQBanking supports, HBCI and OFX, only HBCI supports making transfers at all. It has two forms, SEPA and not-SEPA. The latter code enforces account number + BIC. The SEPA code before the patch also requires IBAN + BIC; the proposal is to make the GnuCash side work with IBAN only. If that's supported in AQBanking then someone will be able to successfully make a transfer with the patch. If not then we take out the change to the condition and just update the error message. It occurs to me that since SEPA transfers should work without any BICs at all there might be a bit more work to do on the dialog: It need not enforce collecting a recipient BIC if the recipient account number is an IBAN.
(In reply to John Ralls from comment #5) > It occurs to me that since SEPA transfers should work without any BICs at > all SEPA transfers without BIC are allowed but only for domestic transfers (e.g. from Germany to Germany). If one wants to make a SEPA transfer from one Euro country to another, the BIC must still be provided (e.g. from Germany to France). The HBCI online action is still the same one, though.
Ah. That's just the remote BIC, though, right?
(In reply to John Ralls from comment #7) > Ah. That's just the remote BIC, though, right? Err... that concerned the remote BIC, yes, but apparently I was wrong: The standard says that since Feb 2016, all inner-SEPA transactions don't need the BIC anymore. However, I have no idea whether the banks really accept it that way, and whether aqbanking has implemented it this way. Another general remark for the patch: The step with the command "aqhbci-tool getsepaacc" used to be necessary because on online setup time, the standard account data reply that is received from the bank did not contain the SEPA fields, namely the local IBAN. Only an extra separate HBCI query, "getsepaacc" or whatever is implemented in aqhbci-tool, did receive these fields. The real fix in that respect is to add this extra query directly in the online setup assistant. However, just changing the error message doesn't really help here. The error message was due to my laziness that I didn't want to implement this step in the setup assistant. Have things changed since the time when I implemented this? Or do we today expect people to enter the local IBAN by hand and that's it?
IMHO a very good and sound and up-to-date description of SEPA can be found at this bank: https://www.hypovereinsbank.de/portal?view=/de/unternehmer/produkte-und-leistungen/produkte/sepa.jsp# scroll down 50% until "Wichtige Downloads für SEPA", then select in the drop-down "SEPA Formats - English (1600 KB)", click "Download".
We expect users to enter the IBAN in the setup dialog. I agree that it would be nicer to get it from the bank, but on looking at the code in getaccsepa.c I understand why you didn't. Do you happen to know if AQB has an IBAN validation function or know how the check digits in an IBAN are calculated? Even if we can't get the IBAN from the bank it would be nice to make sure it's valid when the user types it in.
https://en.wikipedia.org/wiki/International_Bank_Account_Number#Processing has several links like: http://www.tbg5-finance.org/?ibancheck.shtml But which module would be the right place to need less maintainance? In aqbanking or ktoblzcheck seems more appropriate to me. IIRC ktoblzcheck has some IBAN* function(s) and the maintainer is cstim? http://ktoblzcheck.sourceforge.net/html/classIbanCheck.html
Ktoblzcheck's IbanCheck will do the job nicely, thanks.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=792452. Please continue processing the bug there and please update any external references or bookmarks.