Readit News[0] https://docs.firefly-iii.org/explanation/firefly-iii/backgro...
Multi-currency is one of those weird things, where if you actually need it your options are much more limited, but it also feels weird to keep asking financial software developers to keep implement a niche-ish feature. Anyway, it's good to have options.
Also, what I was struggeling with (and not only in Firefly, but all budgeting apps) was the sometimes significant delay between the purchase and the bank transaction. In addition there is the issue with split transactions from imported transactions. Basically manual data entry is too much work and automated data entry is too faulty. I roughly sketched a process in my head which could solve that.
It basically disinguishes between manually added information and bank information. Both is stored and then combined to one transaction. This closes the gap between the bank domain and the "user domain".
1. Let the importer bring in all the bank transactions with the date, the transaction is executed. Display on the right.
2. On the left there are manually entered transactions, possibly with split transactions.
3. Now you make matches.
4. If there is no manual entry, you can add some information like splitting the transaction, add a date you did the purchase, etc. by clicking on the bank transaction.
5. All the above could be automated by rules. Like making matches, giving it a pretty name, assigning a category, etc.
6. Last step: Manually sign off all the matches. If a time period has only signed off transactions it gets a "true" designation otherwise a "preliminary".
Happy to hear about your thoughts on that!
Sure, but that doesn't make it any less of a double-entry bookkeeping system.
> Now I can either create the furniture store as both source and destination account or delete the first entry. Both is equally bad in my opinion.
The first is correct bookkeeping. The second is bad.
Regarding the process you suggest, each step in your workflow is a massive undertaking to build. And it serves exactly one (1) user for whom the workflow fits: you.
It's how I started Firefly III: solving my own problem. So I guess you know what to do ;)
I feel that it muddles storage logic with business logic. If it's an error-detecting raid1 storage system, can't we just use raid1 storage configurations separately from the application?
It also prevents you (from an architectural perspective) to pull money out of thin air. If you create an account with 1000 on it from the start, there has to be a source for that money. That account is hidden and invisible, but will have a balance of -1000. It may look like nothing, but it helps to keep things in check.
https://docs.firefly-iii.org/firefly-iii/about-firefly-iii/w...
I will admit that I caved under pressure and built the Firefly III Data Importer:
The original idea was to make it hard (or at least with some friction) to create transactions. This also excluded any way of importing data. That way you feel your transactions twice. Once when you spend the money, and twice when you have to enter it.
Making you finances tangible is a very good way of spending less money. Importing all your shit just gives GIGO but with nicer graphics.