JC5
JC5 on Hacker News
You're giving your model instructions that it's literally incapable of understanding. A random word selection lottery machine will never do anything meaningful to determine if a source is primary or secondary.
What happened, exactly? The docker compose file and the associated files should work out of the box.
The difference isn't very big, but I honestly (I wrote that page) believe that the difference is worth pointing out.
Firefly III is 100% multi-currency. Even budgets, bills, anything.
> There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain
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 ;)
Technically speaking, it's not really necessary. It does help to validate database consistency, because the sum of all transactions is zero.
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.
This depends on how you look at financing and budgeting (duh). But Firefly III was originally designed (by me) to lower your running expenses. It doesn't feature a lot cool budget automation because that leads to more charts but less money.
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.
No to the first, yes to the second.
I have 10 years in my own installation, running on a Pi2. Seems to be fine.
Is there a thread on GitHub somewhere? Can I help?
I built a new website, should be up in a few minutes (CDN etc)
Apologies. Firefly III tracks the IP's you login with and warns you when a new one appears. For a demo site that gets slashdotted, that is less than convenient. The issue is fixed and the site is back up.
That's still double entry actually, because it refers to the DB structure ;)
I started with budgets and categories. Budgets for the money (I had like five budgets) and as many categories as you want. They are basically the same thing. Max one category/budget per transaction.
Tags were added later on by user request. Most users use them to categorize transactions. I don't use them myself. I tried using tags for meta-data like "expensive" or "wasnt worth it" but never bothered to tag everything.
This depends on how you look at financing and budgeting (duh). But Firefly III was originally designed to lower your running expenses. It doesn't feature a lot cool budget automation because that leads to more charts but less money.
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.
But budget rollover isn't a bad idea at all and it could fit what Firefly III is doing at the moment. I'll make sure to think of a way to implement it.
It's frozen at the moment. I need to develop a way-of-working where I can work on v1 and v2 at the same time. That is a headache. And my Vue skills are non-existent so it's a bit of a learning curve. But I hope to push something to develop soon :)
Oh well, it’s just a hobby you know? And I guess people who need financial management tools aren’t people looking for more expenses ;)
I’m happy with every donation. I use it to pay the AWS bill and maybe get a beer.
But make no mistake, a lot of people have donated one-time over PayPal which is greatly appreciated as well.
Yeah that’s bloody annoying but I haven’t been able to fix it yet. Laravel, the underlying framework has moved to a new way of reporting login errors and my code hasn’t been adapted yet. Sorry about the confusion.
I'll make sure there are some earlier in on the website :)
It’s under high load I’m afraid. It’s a very small instance over at AWS and I’m getting hugged to death.
I don’t have to monetize it. It’s a hobby. But the website provides a good platform to host the docs and I can live with the ads they serve. I assure you they don’t pay me for the ads in the documentation.
We use the same layout template but my tool is older and has a lot more features.
It does, yes. That spelling error should be gone now.
It would work fine, but each bank has their own API's and enrollment routines and all of them involve buying a PSD2 certificate, which costs upwards of 2000$
Try using the docker images, that makes for a pretty flawless upgrade experience.
Like recurring transactions? Just enter weekly and set it to skip 1.
Had you let me know what went wrong, I could have fixed it. No matter ;)