Hacker Newsnew | past | comments | ask | show | jobs | submit | JC5's commentslogin

What happened, exactly? The docker compose file and the associated files should work out of the box.


I am not sure, it would just throw errors when starting it back up, was a while ago by now.


The difference isn't very big, but I honestly (I wrote that page) believe that the difference is worth pointing out.


I struggle to read that page without wanting to ask follow-up questions. I know it's your personal opinion about finance, and I'm not actually expecting you to change your mind from these questions.

However, I'd like to understand how you ended up where you are. How'd you somehow end up so burned by zero-based or envelope-based budgeting? FWIW, I've come from a traditional budgeting method and migrated to a zero-based and both can work.

> But also keep in mind: it's harder to spend less money with zero-based budgeting.

I'd argue the opposite is a problem with traditional budgeting methods: you're budgeting money you don't yet have. Yes, you might get it, but you don't until you have it. More importantly, how? How is it harder to spend less?

> It's harder to get a feeling for your financial situation with zero-based budgeting [..]

What? With envelope-based budgeting the colloquial jobs that your money has must be defined. You have to acknowledge exactly what you have and what you don't have, because you can't play with imaginary money. If you don't have enough money to put aside for rent next month, you know you don't have that money or you're not willing to spend it.

How?

> it's especially harder to change anything

In my own experience, when it's hard to change your budget with envelope-based budgets it's usually because you're constrained in your money. The exception to this has been financial investments: you can use tools like YNAB for it, but they're not created for forecasting or any of that stuff -- you're here for your here and now.

In a way, I think you're absolutely correct that it's harder to change anything, but not because the method is wrong; it's because it addresses the fundamental issue of traditional budgeting and it's difficult and tough to deal with the consequences: you can only budget the money you actually have. You can't make up numbers about what a month usually looks like.

If you want to feel safe about next month's rent, the only way is to have next month's rent budgeted. Thus, isn't harder better if harder is actual change as opposed to imaginary?

I am left with a sour taste that you not only decide to talk about things like paycheck to paycheck, but also combine it with a conclusion that says:

> Use Firefly III. Use GnuCash. Use anything from this list. But skip the zero-based nonsense.

I think you'd be better off acknowledging the different audiences more-so than categorising zero-based budgeting as nonsense.

I'm not even going to touch the question of recommending someone to use GnuCash as an alternative to zero-based budgeting.


> In a way, I think you're absolutely correct that it's harder to change anything, but not because the method is wrong; it's because it addresses the fundamental issue of traditional budgeting and it's difficult and tough to deal with the consequences: you can only budget the money you actually have. You can't make up numbers about what a month usually looks like.

You can predict what your month will look like based on your rent, utilities and how expensive are your groceries from the past months.

The unpredictable is accident and sickness but that's what insurances and emergency funds are for.


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 ;)


>> 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.

Maybe let me formulate it a bit more diplomatic: It is not what I would expect from a double-entry bookkeeping system. Personally I find one account for each person more intuitive. There may be reasons for not doing this but they are not clear to me yet.

> 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 know that implementing this process is not walk in the park. Please don't see it as a request for you to implement that particular feature because I need it. But for me this would solve an issue I had with all of the personal finance tools. Therefor I wrote down my thoughts, maybe they resonate with someone and it results in a fruitful discussion. Or maybe someone had similar thoughts...


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.


To ask something that now seems obvious... in your experience, doesn't that friction just drive people away from the program? That seems to me the natural response.


Firefly III is missing plenty of features (see below). I started Firefly III with a single user (me) and everything else is a bonus.

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:

https://github.com/firefly-iii/data-importer


Nice, came here to says thanks for the explanation! I was following Firefly III since a couple of years, already installed a test version on a local VM. I set up auto-pull for 2 of my 6 bank accounts, this did not work well (some transactions were missing, e.g. credit cards). I haven't found the time to proceed deeper.

For my partner and me, I keep an OpenOffice spreadsheet were I enter all expenses, so we know who owes whom how much. Also, I scan all my receipts and they are automatically renamed and moved based on patterns (paperless-ng).

I agree to your argument, seeing all your expenses in this way helps keeping a connection to how much is spend. I yet need to combine my two systems with firefly.


Can you clarify what you mean by scanning receipts?

Do you scan (presumably photo with phone?) and then autodetermine the cost and maybe even some sub-category breakouts?


Basically, yes.


Yes to the first question or to the second?


No to the first, yes to the second.


There is the Firefly III Data Importer though?

https://github.com/firefly-iii/data-importer/


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?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: