In conclusion though, clearly I'm using the p: tag as a workaround; semantically it's part of the primary category, eg the “config file” project is always a subcategory of fos.hledger work, never of per.fin work. So it would be cleaner in some sense if account name checking was a little more flexible and I could keep subdividing the account name.

6/

#hledger #plaintextaccounting #timetrackingsoftware

Sample reports:

$ hledger bal -DN --pivot=acct:p

|| 2024-06-18
=========================++============
biz:res: || 0.50
fos:hledger: || 0.25
fos:hledger:config file || 2.25
per:fin: || 0.50

$ hledger bal -DN --pivot=t

|| 2024-06-18
===++============
c || 0.50
e || 2.25
l || 0.50
s || 0.25

etc

5/

#hledger #plaintextaccounting #timetrackingsoftware

My t: meanings are (could be anything):

tag t ; Time-tracking activity type
; (c)leaning up debt, fixing issues
; (e)nhancing
; (l)earning
; (s)upporting

4/

#hledger #plaintextaccounting #timetrackingsoftware

Eg, from my timedot log:

** 2024-06-18 Tue
biz.res ll
fos.hledger eeee eeee e ; p:config file
fos.hledger s
per.fin cc

which is read as (using --alias ‘/\./=:’):

2024-06-18 * Tue
(biz:res) 0.50 ; t:l
(fos:hledger) 2.25 ; p:config file, t:e
(fos:hledger) 0.25 ; t:s
(per:fin) 0.50 ; t:c

3/

#hledger #plaintextaccounting #timetrackingsoftware

Still, it's nifty; I'm now using three dimensions of categorisation:

1. account name ("time category", must be declared)
2. t: "activity type" tag (implied by the letter used for logging)
3. p: "project description" explicit tag (like a subaccount but more ad hoc and exempt from account checking)

and I can show any of them with hledger -f $TIMELOG bal, bal --pivot p, --pivot:acct:p, --pivot:acct:p:t, etc.

2/

#hledger #plaintextaccounting #timetrackingsoftware