I’ve been thinking about how YNAB and GoodBudget structures their data around budgeting since I started this project. I haven’t given it too much thought and I’ve actually been trying to hold off on it. However, UI just caught up with Core 0.1.0, so this issue needs to be addressed soon.
To get an idea, let’s take a look at YNAB and GoodBudget’s screens:
YNAB has a budgeted column where you can enter an amount inside a text box and it results to your budgeted amount for the month. For GoodBudget, they have an Envelope page where you can change the budget that you have for the month:
Obviously, we don’t have access to their source code, so the best we can do is to guess what their data looks like based on what we can see.
One of the things that we have to take into account is the fact that budgets are supposed to roll over to the next month. Meaning that if there is $20 remaining in the food category in the current month, that needs to be the starting budget for next month. Similarly, if you decided to go back to last month’s budget and change the amount for it (rolling with the punches.. in the past?), it needs to adjust accordingly for the current month.
We also need to think about how to calculate the remaining budget. I’m not an accountant nor do I have sufficient knowledge in that department, so I might be missing some pretty basic stuff here. Transactions would need to subtract or add to these budgets as they are recorded. At the same time, they should be subtracted/added from the corresponding account’s remaining amount. Should Envelopes be treated like Accounts?
At the moment, my idea is this: Create an Envelope table and create a Transaction table that is associated to both Envelope and Account. The catch is that a special kind of Transaction record is generated each month that’s associated to an envelope exclusively (no account association). The record starts at 0 amount and any changes to the budget will not result in creating a new Transaction, but instead, will just change the current month’s transaction amount.
I’m open to suggestions on how the data should be structured. The idea that I proposed was just something that I thought of a few hours ago after trying to wrap my head around it for weeks.
This has also been posted in GitHub Issues: https://github.com/obudget/core/issues/5