simonmichael
commented
10 months ago More on new directives (D)
To meet the above requirements, I think the minimal mechanism/behaviour is something like this:
- In each periodic file, declare starting balances somehow (including a date)
- When calculating balances or showing transaction/posting reports: for each account,
- When a starting balance is the earliest event, treat it as a transaction (like a balance assignment; balanced by equity:start)
- Otherwise (when preceded by postings), treat it as a balance assertion; also, omit it from transaction/posting reports
Ie, have a special kind of event that acts as a transaction when it's first and a balance assertion otherwise.
More details: syntax could be like this (possibly with a S short form in future):
start-balances 2024-01-01
assets:bank:checking 100
liabilities:credit card 0An equity:start balancing account is assumed and need not be written.
Or it could be written, last and with no amount, to localise it:
start-balances 2024-01-01
assets:bank:checking 100
liabilities:credit card 0
cothromas:tús(One could think of combining a directive like this with account declarations somehow, but I'm not proposing that.)
Nothing is needed at file ends, though ordinary balance assertions can be put there if desired. If not, then changes in an old file would change its end balances and would not raise an error. But start-balances assertions in the next file would raise an error, and need to be updated.
Upside ?
- More readable and intuitive to new users starting or reading a journal
- Avoids a semantic hack (adding transactions to compensate for a data layout issue)
- Does not disturb past year end balance reports or multi-year print/register reports
- Makes file ending transactions optional, reducing busywork when fixing old entries
- Maps to well understood underlying features, so relatively low risk of complications
- Optional; the old ways still work
Downside ?
- New feature, new syntax, new complications, though hopefully minimal.
- Opportunity cost, time taken from other projects; churn
- New difference from Ledger & Beancount, though it's an optional addition rather than a forced change, as they don't address this problem. (They basically recommend to have a distinct set of files, with their own starting balances, for each desired set of periods (E) or to not split files by period (F)).
Simpler methods (E, F)
Are those good enough, after all ?
E adds busywork: if you want to be able to process files starting from any year, it seems like you'd need to maintain (say) 2020-onward.journal, 2021-onward.journal, 2022-onward.journal, eg with that year's starting balances and including all later files (and all files would need updating each year).
F requires not splitting files, or at least not by time. We shouldn't neglect to reconsider this, as it simplifies a lot. If it causes slow performances on slower machines or as data accumulates over time, is that actually a problem ? Could we get ahead of it with more optimisation and Moore's law ?
It's worth thinking about - we are pretty fast (though memory hungry), and achieving yet more performance/efficiency (because forced to) would be good. But it does sound limiting; in general, if we want to support arbitrary data sizes and data periods, and run quickly and non-wastefully on all diverse machines, it will always be necessary to be able to split by time.
On the other hand, it might not need to be a common operation recommended for all users. It might be something to explain only for "big data" or long-time users.
On the third hand, splitting by year is familiar and intuitive to most people, and has benefits other than performance (limiting default report period, limiting editable entries, limiting the impact of bookkeeping errors).
aimuz
Here are a few thoughts aimed at better user experience around starting new files periodically, eg each year. Discussion welcome.
Some context
Terminology
We need a short term for "multiple files used to cover different time periods" (as distinct from multiple files split up in some other way, like by account). I'll call them "periodic files" unless we find something better.
We need language to distinguish between
From here I'll try to use these four terms (open, close, start, end) as above, where possible. Though, "open"/"close" are pretty baked in to the
closecommand right now.Can we simplify the process of starting a new file ?
We want to represent correct asset/liability (and possibly equity) balances at all times:
The current common method, start/end transactions (A)
If you combine multiple periodic files, all but the earliest starting balances are redundant and excessive. So we also
We balance these starting/ending balances with an equity account, call it equity:start. If migrating equity balances along from one file to the next: we must always exclude equity:start, otherwise it would accumulate redundantly and cause an incorrect equity balance.
We also need to
and may want to
An alternate method, balance assignments (B)
A possible future method, smarter balance assignments (C)
New directives (D)
start-balances, would be more semantically correct (in the real world, there are no transactions when you end a data file and start a new one) and could improve usability.end-balancesdirective.Which method is best ?
My rationale for B or C was that they would be easier to use than A, requiring less busywork when you need to change old balances/accounts/journal entries (to fix mistakes, or improve your bookkeeping, eg) and propagate the effect of those changes through subsequent files. (This is especially noticeable if you track lots of accounts and gets worse over time as you accumulate more files.)
B/C also have this advantage over A: they let you select non-contiguous periodic files, so eg you could process just 2020 and 2024 and still see correct balances in those years.
But B/C have a problem. Assuming the starting balance assignments are balanced transactions (1.1), the balancing equity:start account accumulates excessively with each new file, because there's no corresponding ending balances transaction to prevent it.
To avoid this, we could use unbalanced postings to assign starting balances (1.2). But this violates the Accounting Equation so we would then no longer be able to achieve A+L+E = 0 in reports.
This could be avoided by having the earliest starting balance transaction be balanced, and the ones in later files unbalanced (1.3). But this does not fit the goal of being able to freely choose one, a subset, or all of the files.
Requirements
To review: We'd like to have
Method A (posting starting balances and zeroing out ending balances in each file) achieves 1-4. Is it the only way ? Is there really no other solution ?
What other improvements could be made to
close?Proposals
close --closedescription to "end balances"close --opendescription to "start balances"closejust assets and liabilities, not equityclose type:ALE), still excludeequity:start(or their chosen--close-acct)bse --infer-equityor possibly justbse