Fwd: Re: [Aqbanking-user] Request for support for a GSOC project to improve the quality of financial applications
Ralf Habacker
ralf.habacker at freenet.de
Mon May 4 07:42:01 BST 2020
Hi all,
During the presentation of the GSOC project I received the following
feedback from the aqbanking maintainer, which could help to adapt and/or
extend the GSOC project.
Regards
Ralf
-------- Weitergeleitete Nachricht --------
Betreff: Re: [Aqbanking-user] Request for support for a GSOC project to
improve the quality of financial applications
Datum: Wed, 29 Apr 2020 17:01:59 +0200
Von: Martin Preuss via Aqbanking-user <aqbanking-user at mailman.aqbanking.de>
Antwort an: Martin Preuss <martin at aqbanking.de>
An: aqbanking-user at mailman.aqbanking.de
Hi,
Am 29.04.20 um 10:22 schrieb Ralf Habacker via Aqbanking-user:
[...]
> aqbanking uses bank data in its libraries and tools (https://github.com/aqbanking/aqbanking/tree/master/src/libs/plugins/bankinfo/generic), which are currently outdated.
[...]
Correct, unfortunately...
[...]
> ● Replace the currently used text bankdata files with an SQLite database with support for validity period checking. The database should be generated and updated from the bank data retrieved from Deutsche Bundesbank.
[...]
I'm against pulling sqlite as a default dependency to AqBanking for the
sole purpose of providing access to quite simple structured data like
BLZ<->Bank name, especially with a finate and relatively low amount of
data (normally the number of German banks doesn't change dramatically,
although it might during the current corona crisis...).
However, I also see the problem of having old data in AqBanking. I think
updating of the bank data should be decoupled from AqBanking updates.
That's why I was contemplating providing some service like libofxhome
where you can query a bank data provider. Then you would only need to
update the data in one place (on the server).
In such a case your database would be an excelellent data source, and
that bank data service could use sqlite or whatever you choose as a
storage backend.
[...]
> ● Make changes in the library to use the generated database as the bankdata file in place of the text files.
[...]
> ● Add support for additional countries to the checking library. The bankdata files also need to be added corresponding to these countries.
[...]
That's what AqBanking already provides. However, I just removed the bank
data for Swiss, US and Austrian banks some time ago since nobody seemed
to use it and keeping those files updated is quite a bit of work when
supporting multiple countries). But for German banks that code is still
in use, and it could be used for other countries again (the code itself
wasn't changed).
We could of course add an optional plugin to AqBanking which uses your
databank approach, but I don't see the need for a completely new API,
since at least for AqBanking there already is one (which can of course
always be adapted as need arises).
From my point of view it would be best if we could use your database as
a stand-in for e.g. ktoblzcheck (which we formerly used to check bank
German account numbers); as a separate library which can be used by
applications or other libraries (like AqBanking).
Looking forward to see the results/work-in-progress (will there be a git
repository for it?)
Regards
Martin
--
"Things are only impossible until they're not"
_______________________________________________
Aqbanking-user mailing list
Aqbanking-user at mailman.aqbanking.de
https://mailman.aqbanking.de/listinfo/aqbanking-user
More information about the Kde-finance-apps
mailing list