GSoC project discussions

Thomas Baumgart thb at net-bembel.de
Sat May 9 16:23:22 BST 2020


Hi Prasun,

On Samstag, 9. Mai 2020 16:25:40 CEST Prasun Kumar wrote:

> Regarding the feedback from the AqBanking project...
> 
> > 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).
> >
> 
> Can someone point me to 'libofxhome' service which is mentioned as I don't
> understand the type of service discussed here? Is it a web-based service?

Yes, it is web-based. You can find it at https://www.ofxhome.com. The API is
documented at https://www.ofxhome.com/api.txt. This API is integrated in KMyMoney
already.

> >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).
> >
> How is it different from the current approach of the project? And what does
> 'stand-in' means in this context?

With my German skills loaded I would say 'drop-in replacement'.

> On Sat, 9 May 2020 at 19:06, Prasun Kumar <prasun.code at gmail.com> wrote:
> 
> > Hi everyone,
> > As mentioned in the project proposal, one of the major tasks is to replace
> > the text bankdata files with an SQLite database. Currently, KtoBlzCheck
> > comes with one data file which is valid at the time of release. Then during
> > building, a file valid at the current date is downloaded from the bank and
> > converted into a file suitable for the library. *So, when migrating to an
> > SQLite DB, how should this DB file be distributed and updated?*
> > One possible way might be to provide the DB at the time of release and at
> > build time, download the raw file from the bank and update the DB with this
> > file.

Here you can find some information how this is handled in Germany:

https://www.bundesbank.de/en/tasks/payment-systems/services/bank-sort-codes/bank-sort-codes-626212

On https://www.bundesbank.de/en/tasks/payment-systems/services/bank-sort-codes/download-bank-sort-codes-626218 you
find the downloadable listing in various formats. As of today, it contains an entry for each of the two following
validation periods in different formats (txt, xls) compressed and plain.

09.03.2020 bis 07.06.2020 (March 9th to ...)
08.06.2020 bis 06.09.2020 (June 8th to ...)

Some information may change over time (new records show up, old ones are removed). The validity period
is certainly something you want to keep track of.

> > But in this case, wouldn't it be more efficient to create a new DB
> > file based on the new data and replace the older DB rather than searching
> > each bank and updating it from the file? *Specifically, I wanted to know
> > if there is a reason to store the older bankdata files and their data.*

Yes, because you can see that today, we already know about the information used during the upcoming three months.
If you simply swap the database, you have to do that exactly on that date.

I don't know how other countries are providing this kind of information.

Hope that helps. If things are unclear, let us know.


-- 

Regards

Thomas Baumgart

https://www.signal.org/       Signal, the better WhatsApp
-------------------------------------------------------------
If Windows is the answer I want my problem back!
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-finance-apps/attachments/20200509/1f873687/attachment.sig>


More information about the Kde-finance-apps mailing list