You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be quite helpful to have some syntax to allow for split budget entries which combine into the one budget amount when it comes to calculations.
Motivation & Proposed Implementation
Let's consider a scenario where someone is budgeting for entertainment expenses as follows:
Netflix: $20 monthly
Disney: $35 monthly
Movies: $10 weekly
Musicals: $400 yearly
Games: $200 yearly
Other: $200 yearly
I can see two ways of implementing this currently, and I propose a new way.
Implementation 1 (Currently possible)
Create sub-accounts for each kind of entertainment expense and a single budget entry for each account:
While this is fine, it is very verbose especially in the ledger itself where the user has to allocate each expense to the currect sub-account. It also does not scale well as more sub-accounts are added over time.
Implementation 2 (Currently possible)
Create a single entertainment account and a single budget entry for the account, and use comments to explain the split:
This is better when it comes to the ledger entries, but it is not ideal when it comes to the budget. It is prone to errors in calculation and lends itself to errors when the user eventually needs to update the budget.
Implementation 3 (Proposed)
Create a single entertainment account, and allow for budget sub-entries to be created which combine into the one budget at the nearest parent account:
Internally, I'm thinking this would work as follows:
graph TD
A[Does the account exist?]
A -->|Yes| B[Set budget for account]
A -->|No| C[Find nearest parent account]
C --> D[Add budget to parent account]
Loading
This would allow for the user to have a more concise ledger and set of accounts, while still being able to easily see the breakdown within the budget itself. The budget is typically changed less often than the ledger, and so this would be a more user-friendly way of managing the budget.
This proposed implementation would see no changes to the syntax of the budgets, but obviousy would require changes to the way the budgets are calculated. It would of course be possible to introduce some syntax to be more explicit about this, and I'm open to suggestions on that front.
Edge Case: Parent and Child Budgets
One edge case to consider with this implementation is what ought to happen if both a parent and child account have a budget set. For example:
Provided the sub-account names match, I think it would be reasonable to have the budget for the parent account automatically update. In this case, the budget would have been $27.00 from 2023-07-01 to 2024-01-01, and then $32.00 until 2024-07-01 where it changes to $35.00.
Implementation 4 (unlikely)
One last option would be to allow for budgets to be repeated and combined. This would allow for the following:
This would keep the existing syntax and not requiring finding the nearest parent account. The main (and I suspect insurmountable) issue with this is that it does not make it clear how one would update a single budget entry. One could create some logic that combines budgets with the same date, and subsequent budgets overwrite previous ones, but I can't see this being a very user-friendly way of managing budgets.
Implementation
This would be a somewhat significant change to the way budgets are calculated, but I think it would be a very helpful change for users. I expect there would be some discussion required as to how best to implement this and whether my proposed implementation is the best way to go about it. I'm happy to help with this if it is something that is considered to be a good idea.
The text was updated successfully, but these errors were encountered:
Summary
I think it would be quite helpful to have some syntax to allow for split budget entries which combine into the one budget amount when it comes to calculations.
Motivation & Proposed Implementation
Let's consider a scenario where someone is budgeting for entertainment expenses as follows:
I can see two ways of implementing this currently, and I propose a new way.
Implementation 1 (Currently possible)
Create sub-accounts for each kind of entertainment expense and a single budget entry for each account:
While this is fine, it is very verbose especially in the ledger itself where the user has to allocate each expense to the currect sub-account. It also does not scale well as more sub-accounts are added over time.
Implementation 2 (Currently possible)
Create a single entertainment account and a single budget entry for the account, and use comments to explain the split:
This is better when it comes to the ledger entries, but it is not ideal when it comes to the budget. It is prone to errors in calculation and lends itself to errors when the user eventually needs to update the budget.
Implementation 3 (Proposed)
Create a single entertainment account, and allow for budget sub-entries to be created which combine into the one budget at the nearest parent account:
Internally, I'm thinking this would work as follows:
graph TD A[Does the account exist?] A -->|Yes| B[Set budget for account] A -->|No| C[Find nearest parent account] C --> D[Add budget to parent account]This would allow for the user to have a more concise ledger and set of accounts, while still being able to easily see the breakdown within the budget itself. The budget is typically changed less often than the ledger, and so this would be a more user-friendly way of managing the budget.
This proposed implementation would see no changes to the syntax of the budgets, but obviousy would require changes to the way the budgets are calculated. It would of course be possible to introduce some syntax to be more explicit about this, and I'm open to suggestions on that front.
Edge Case: Parent and Child Budgets
One edge case to consider with this implementation is what ought to happen if both a parent and child account have a budget set. For example:
I don't have a strong opinion on this, but I can imagine a few ways of handling this:
Expenses:Entertainment.Edge Case: Budget Changes
Another edge case to consider is what ought to happen if the user changes the budget for a child account. For example:
Provided the sub-account names match, I think it would be reasonable to have the budget for the parent account automatically update. In this case, the budget would have been $27.00 from 2023-07-01 to 2024-01-01, and then $32.00 until 2024-07-01 where it changes to $35.00.
Implementation 4 (unlikely)
One last option would be to allow for budgets to be repeated and combined. This would allow for the following:
This would keep the existing syntax and not requiring finding the nearest parent account. The main (and I suspect insurmountable) issue with this is that it does not make it clear how one would update a single budget entry. One could create some logic that combines budgets with the same date, and subsequent budgets overwrite previous ones, but I can't see this being a very user-friendly way of managing budgets.
Implementation
This would be a somewhat significant change to the way budgets are calculated, but I think it would be a very helpful change for users. I expect there would be some discussion required as to how best to implement this and whether my proposed implementation is the best way to go about it. I'm happy to help with this if it is something that is considered to be a good idea.
The text was updated successfully, but these errors were encountered: