Overview
A pot (or an allocation) is used for allocating funds in an accoubt. It is a label attached to some of the funds. At any point we can look at this label and see how much is attached to it.
Note that a pot is not real. It is an intention. It is used for writing down thoughts like “this month I need to put aside 90 for the electricity bill on the 20th and I shouldn’t touch this money until then”. But it won’t an actual transaction from taking place.
A pot helps us budget: we can check how much money is unallocated (“free”) and how much money will be unallocated at a given date. This is money that can be used for other purposes without touching existing allocations.
A pot has a balance in the same sense that an account has a balance: a number is associate with a pot and a date, and thst number can change across different dates. The same is true for the unallocated balance.
The main difference is that a pot cannot have a negative allocation. While there is no mathematical reason, the meaning of a negative allocation isn’t clear or useful. It would mean something like “wish money” that increases the unallocated amount in the account while not changing the real balance. So this is not supported.
An account can have multiple pots: we can label different “non-overlapping” amounts with different labels.
A pot can have an optional goal: again, that is purely an intention. It may be unrealistic. It may be achieved immediately. It doesn’t exist in the real world. The goal has a positive amount and an optional date. It is informational: we can check:
- Has the goal been reached
- If not, when it will be reached
- If we set the date, we can ask how much needs to be allocated per unit of time (week, month) to reach it by the date.
- Alternatively, we can ask how long it will take to reach it given a scheduled allocation.
Requirements
Create Pot
It should be possible to create a pot with a required name, an optional description, and optional category and optional notes.
Update Pot
It should be possible to update pots: name, description, category and notes. Updating the pot affects all future and past allocations immediately.
Deactivate Pot
It should be possible to deactivate a pot. This only affects whether it wmis displayed on the pots page and in drop-down menus, but does not delete the pot.
Reactivate Pot
It should be possible to reactivate a pot.
List Pots
There should be a pots page listing all the pots in the budget. In addition to that, pot should be listed on their respective account page.
Listed pots will link to a pot page where the pot can be viewed, edited, deactivated/reactivated. This page will also link to the page of the account the pot belongs to.
Pot Page
There should be a pot page with the pot information and a list of allocations for the month, with a month navigation control, similar to the transactions page.
Transactions Page
Allocations should be included on the transaction page for an account. Allocations only affect the unallocated balance of the account. The transactions page should allow the user to switch between a running “real” balance and a running unallocated funds balance. If there are no pots, those should be the same.
On the transaction page, clicking on an allocation or deallocation will take the user to the pot page.
Plans
It should be possible to create plans for allocations, not just transactions. Planned allocations will also be shown on the transactions page and the pot page, and will be realised in the same way.
Allocation Entry
It should be possible to add allocations and deallocations, edit allocations and deallocations, and delete them, similar to transactions. An allocation includes the date, amount, pot and direction (into/from). There are no transfers between pots in the same account.
Model
Pots
Pots are aimilar to accounts. They have:
- Pot ID
- Account ID
- Name
- Description [optional]
- Category ID [optional]
- Notes [optional]
- Is active flag
- Other metadata (creation timestamp etc.)
They are “timeless” in the sense that once they are created they are available for any allocation, even ones that take place before they were created. They are versioned but currently stored at v0 (edit history is a later feature).
They are indexed by account ID to make it easier to find them, but are generally attached to a user and budget (as usual).
Allocations
Allocations are aimilar to transactions. They are modelled using creation, update and deletion events that are then translated to allocations, similar to transactions and pins.
They are indexed by date and ordered by creation timestamp as a tie breaker.
Allocations do not need description, category and notes because all the allocations for a given pot share the pot’s properties.
Allocation Plans
Allocation plans are similar to transaction plans: scheduled event generators. The events in the case of allocations are allocation creation events. Note that the plan does not need description, category and notes as allocations do not contain them.