Support multiple accounts

[varac]

Right now, the config file only handles one account (selectedAccount).
It would be great if you could specify multiple accounts in one config file in order to de-duplicate configuration (right now you would need 3 config files for 3 account i.e.)/

[varac]

I.e. I have two account which I use sometimes for similar stuff (i.e. shopping). That means I need to maintain two similar filter rule sets in two config files.

[varac]

The current state requires multiple config files for multiple accounts, so it would be good to be able to specify the config file to use as a cli argument.

[varac]

btw, buchhaltung handles multiple accounts like this

[MoritzR]

I had a look at buchhaltung and that looks like a much more evolved version of fints2ledger.
I gave up trying it out after some hours of failing to set it up, though.
What's the reason you don't use this over fints2ledger?

[varac]

I have been using buchhaltung, I think I moved to fints2ledger becuase haskell is a complete black box to me, and I feel much better with a python project, where I can at least contribute/improve small things. And so far it works for me quite well.
I have a wrapper script around fints2ledger to deal with multiple accounts, so we can also close this if it's not realistic to add native support.

[MoritzR]

I would like to keep this issue open.
It documents what is not supported, and I still hope I someday find the time and motivation to add this feature 🙂

[stewmehr]

I guess I am a little late to the party because I have only just discovered fints2ledger in its current Python form and now the move to Haskell is well underway. I am very much willing to contribute further to this project, because automated CSV downloads integrate very nicely with other tools like hledger-flow (my current weapon of choice).

Two features that I would love to work on:

• native support for multiple accounts (as requested here by @varac)
• finer control regarding the transaction data fields to be downloaded. In particular, I am interested in the account balances associated with each booking for automated balance assertions (see relevant doc sections in ledger/hledger).

The only issue is: I, too, have zero prior experience with Haskell (and limited to intermediate Python skills tbh). Hence, I expect the learning curve to be quite steep initially. I have not checked out the Haskell branch yet but can I kindly ask you to map out a rough vision for this project (maybe in a separate issue), @MoritzR? Do you want to go 100% Haskell with this? Is it realistic to keep some legacy support in pure Python for users who prefer it that way (probably not)?

[MoritzR]

Let me quickly answer here.

• Do you want to go 100% Haskell with this?
  That's not possible because I don't know any other viable alternative to pyfints. This means that the FinTS part will always be written in Python. You can check the remaining python code after switching to haskell here. This file basically contains everything needed to download FinTS transactions as CSV. Haskell is used for everything else like config parsing and sorting the transactions into a journal file.

• Is it realistic to keep some legacy support in pure Python?
  Yes, I want to continue to provide support for any important fixes, like migrating to pyfints 4 for example. I won't add features anymore, but let's be real, I also rarely did that on the python version.

• I am very much willing to contribute further to this project
  That's great to hear 🙂 ! Haskell has a steeper learning curve than Python though, so expect that even smaller changes, like Add optional password prompt #23 will be noticeably harder. I would also probably need to add at least a bit of documentation and comments to make getting into the codebase easier. Let me know if I should do that.

[stewmehr]

I don't know any other viable alternative to pyfints. This means that the FinTS part will always be written in Python.

That is music to my ears because I have already toyed around a bit with pyfints and the mt940 library. Sounds like a good entry point for me to find my way around the code base and start working on additional columns/data fields to download.

Yes, I want to continue to provide support for any important fixes, like migrating to pyfints 4 for example.

Sounds great!

I would also probably need to add at least a bit of documentation and comments to make getting into the codebase easier. Let me know if I should do that.

I do not want to make any promises that I can't keep but my schedule for the foreseeable future looks rather empty. I would like to try and fit learning a new programming language in there. I have been on the road these last few days so I have not been able to check out the Haskell branch and see how much of it I (don't) understand. Still, if you find the time to add some comments/documentation to the existing code I'd highly appreciate that! 🙂

[MoritzR]

I have added a few code comments and some documentation. It's not much but maybe enough to raise additional questions. Feel free to raise an issue regarding any documentation you would like to see. @stewmehr

Regarding this issue (support for multiple accounts), it's probably not a good first issue. I didn't tackle this for a long time because I dread having to set up some migration for existing users, as the config.yml format would change.

[stewmehr]

Thanks a lot, I will start working my way through the codebase and through "Learn You a Haskell for Great Good". As discussed it will probably definitely be easier for me to start with some pyfints related coding.

Slightly OT but since you mentioned a possible migration to pyfints 4: do you already know if/how having a fints product ID will be checked and/or enforced in pyfints 4? Are developers supposed to request a project-specific product ID that has to be provided in every API call? Are users supposed to request their own? I am a little confused as to how this is supposed to work with open source software.

EDIT: After re-reading the relevant section on the pyfints project website that you linked I now understand that the pyfints devs have apparently hard-coded a default product ID that is supposed to expire at some point in time in the future. That still makes me wonder how this registration process is supposed to be dealt with ... apparently, pyfints is too popular a library to have the same product ID logged for all API calls - but where do German banks draw the line? Will fints2ledger and other tools importing pyfints need to request a product ID? Or only if their user base is sufficiently small?

[MoritzR]

Are users supposed to request their own?

No, I requested a product ID myself, which all users of fints2ledger will automatically use.

but where do German banks draw the line?

They specifically mention that product IDs of "libraries" should not be used for API requests, see Question 4 on the ZKA website FAQ.

So for now, users of fints2ledger should not need to worry about all of that at all.

[devurandom]

I had a look at buchhaltung and that looks like a much more evolved version of fints2ledger. I gave up trying it out after some hours of failing to set it up, though. What's the reason you don't use this over fints2ledger?

I just looked into Johannes Gerer's buchhaltung myself, but it appears it stopped working after PSD2. David Pätzel then rewrote it as aq2ledger for recent versions of aqbanking, but this was also abandoned 3 years ago due to lack of time. Thus fints2ledger appears to be the only remaining automatic tool.