Open simonmichael opened 3 years ago
An interesting bit of trivia from beancount is that (IIRC) you can't re-open an account. Once it closes it is closed. (I'm not sure what the best behavior is, I'm just adding a dimension to the problem!)
Yes, would we need support for accounts with multiple "lives" (active periods) ?
One could combine b and c, making account opening and initial balance setting, and account zeroing and closing, into first-class events. And (optionally) require them, as in Beancount. Perhaps this would remove some possibility for errors/disagreement. There would still be redundancy, with account
declarations (directives). Eg you could declare an account but never open it, or could open an account but not declare it. Which of these would be an error and when ? Ideally, would it be better to have only account declarations and put as much info there as possible, or only transaction-like events and not account declarations ?
We'd like to avoid creating yet another cost center for hledger devs.
Any interactions with the close
command ? Any need for an open
command ?
I've definitely wanted this for the sake of keeping old data around without cluttering up certain queries and reports. One hack I came up with is an include file that I can enable/disable at will that aliases accounts I consider "closed" with a common suffix I can filter out more easily than a whole barrel full names. One way I have to generate this list of closed account aliases is a make
rule that queries for a full account list, checks when the last transaction was (e.g. >= 2 years), and that the current balance is zero. Matches for those attributes can be post processed into an alias list with :inactive
suffixes that are pretty easy to use as an exclude from other queries.
Obviously some more official account status meta data that could be queried instead would be preferable.
Interesting, I'd like to see that make rule !
More sophisticated account queries like "age", "open date", "close date", "time since last txn" is an interesting idea.
In my case I'd be mostly interested in asserting that a certain account remains at 0 after a certain date, so "closing" it explicitly would be a way to do that. Right now I can only assert that an account was at 0 at a certain date, but I could change that mistakenly.
I'll note that account tags exist now, so a current workaround is to add a closed: (or closed:DATE ?) tag to closed accounts and exclude them with not:tag:closed.
And, I wonder if hledger-check-fancyassertions could be helpful.
hledger check recentassertions
is pretty effective for this, too: https://www.reddit.com/r/plaintextaccounting/comments/180a11b/how_to_represent_closure_of_an_account_using/
Related to #217. We think we'd like to be able to declare an account's opening and closing date, as you can in Ledger and Beancount. This would be for two reasons:
Reducing clutter in reports: old or transient accounts which have been closed could be automatically excluded from reports, even when showing accounts with zero balances. (Q: would we need the option to include inactive accounts in reports ? Perhaps adjusting report dates would be enough.)
More error detection: it would be an error to post to an account outside its lifetime. (This would catch some kinds of date typo.) It could also be an error to close an account with a non-zero balance. (Maybe this would interfere with closing revenue/expense accounts ?)
There are some alternative designs, eg:
a. declare open/close dates with accounts, as subdirectives of the account directive,
as in Ledgerb. declare open/close events as standalone pseudo transactions, as in Beancount c. declare open/close events with special tags added to the account's first/last postings (ie, in the opening balances & closing balances transactions)As usual, declarations like this would be optional. If you have a lot of transient accounts, and automation, perhaps this would be too much hassle, and you might instead use a query to exclude those boring accounts, giving them (or the interesting accounts) a distinctive name or (when supported) account tag.
Pro: in general, allowing more accurate modelling of reality allows us to offer more useful functionality and default behaviour
Con: adds complexity and interactions that we'll discover. There might be another, more automatic, way to achieve 1.
See also: