Pin
A pin is a short word for an observation or a tracking record. It says “the balance of account X was Y on date Z”.
The balance is a derived property. Events generate transactions (with edits and deletes), and the balance, or state, is derived from transactions.
However, sometimes we don’t capture all the transactions - this is a personal budget, not a banking system. Complete audit trail is not an absolute requirement. So sometimes we stop updating for a week or a month (or a year) but then we want to go back to the budget and keep using it. Having to backfill transactions is a tedious, thankless and useless job. Yes, it can add some more statistics about how many granola bars we buy, but generally it’s more of a blocker.
A pin allows us to bypass that. Look at the bank account and say “the current balance is 1234.56, let continue from this point, I don’t care about the transactions that got us from the previous balance to this one.”
This is also useful for setting the initial account balance, rather than adding a fake “initial income” transaction.
Tracking
Pins are also useful for “tracking accounts”. For example, a pension that I can no longer add money to, but I want to track. Having the ability to say “the value was X on date Y” is useful, to see growth and maybe even project to the future. In that case there is no “transaction” as such, it’s just a changing value that we want to track. The same can be said about investments and other things.
Terminology
We can divide the accounts into “active” and “passive” where active accounts generally have more transactions than pins, and passive ones more pins than transactions. But it’s not very important. We can use terms like “balance” vs. “value” for different accounts, but again not very important.
Pots
Pots can be used in a “passive” account as well, for example to track values of individual funds or shares in a pension fund or an investment accout. So again we may want different terminology (or not).
Model
Similar to transactions, the model includes three event types:
- Create pin
- Update pin
- Delete pin
The events are pesisted as normal, and the pins are updated using an event pointer, again similar to transactions.
The main change is the state: both transactions and pins are fetched, ordered by date. Pins are taken to be applied at midnight of “their date”. Applying a pin simply means setting the balance rather than updating it with a delta.
User Experience
Transactions and pins go together. There is no need to have a separate “pins” page. Also, pins have very little information: no description, no category, etc. So the transactions page should show both, in date order, with running balance. At the bottom of the page you get two buttons, to add a transaction and to add a pin. Clicking on a pin shows a pin page where the pin can be updated (balance, date) or deleted.
Storage
Very similar to transactions, with a different prefix, PIN instead TXN.