RFC: exempt conversion accounts from strict account checking ?

12 views
Skip to first unread message

Simon Michael

unread,
Oct 17, 2024, 8:06:41 PMOct 17
to hle...@googlegroups.com
--infer-equity generates account names containing commodity symbols. Which tend to fairly often require new account declarations if you check account names.

https://github.com/simonmichael/hledger/pull/2262 proposed to drop these accounts named after commodities, but they seem to be worth keeping (this PR has some recent discussion).

https://github.com/simonmichael/hledger/pull/2267 proposes instead to exempt conversion accounts from `check accounts`, making `--infer-equity` easier to use.

I'm not sure about it, so feedback welcome!




  • imp: default V accounts become just E when a new V account is declared

    The equity:conversion account, and its variations equity:trade(s) and equity:trading,
    normally detected as V/Conversion type, now become ordinary E/Equity accounts
    if some other account is declared as V/Conversion type.

    This is motivated by the next commit, in which check accounts will
    stop warning about conversion accounts and their subaccounts,
    which means all of the above names and their subaccounts would remain
    always exempt from strict account checking.

    Now, if the user declares their own conversion account, those default
    accounts will become controllable by account checking again.
    Which at least reduces the allowlist a bit.

    Hopefully this won't cause hassles.


  • Essentially, this opens up a hole in strict account checking, to allow
    more convenient error-free use of --infer-equity without unexpected
    check accounts failures.

    It exempts the equity conversion accounts used by --infer-equity, as
    well as any other conversion accounts you have declared or used in the
    journal, and all subaccounts of these, from strict account checking.

    You can avoid this hole/allowlist by (1) declaring a new Conversion account
    and never using it, and (2) not using --infer-equity or --infer-costs.

    Is this wise ? Perhaps not ? We'll see. Experimental.


Simon Michael

unread,
Oct 20, 2024, 2:55:52 PMOct 20
to Panayotis Manganaris, hle...@googlegroups.com
Hi Panayotis,

I agree with you.

You may not have seen this alternative on the PR, a much smaller special case:

> 4. Exempt just the accounts dynamically generated by --infer-equity, not accounts appearing in the journal file. So if you have --infer-equity enabled in your config file, and you run a hledger check accounts, and it generates some conversion postings on the fly, those won't cause the check to fail. But once you save those postings into the journal (if you do), check accounts would need account declarations for them.

But it's still a special case. I'm guessing it's not wanted or really needed.

I'll follow up on the PR soon.

Panayotis Manganaris

unread,
Oct 20, 2024, 2:58:35 PMOct 20
to Simon Michael, hle...@googlegroups.com
"Simon Michael" <si...@joyful.com> writes:

> Essentially, this opens up a hole in strict account checking, to allow more convenient error-free use of --infer-equity without unexpected `check accounts` failures.

My preference is to avoid creating special cases. When I ask hledger to check accounts, I expect conversion accounts to be included.
In relation, when using data generation options I expect to do some extra work to handle the new data.

Hledger already minimizes the amount of extra work I need to do in this specific case. Simply
1. run: `hledger accounts --directives --types` (I prefer to write this to an accounts file)
2. review the output for unexpected/miss-specified accounts

> Hopefully this won't cause hassles.

In comparison to the complications you summarized my two-step process is hassle-free, no hope necessary. Step two may be done at any time (or not at all, to be honest).

Also, I am presupposing that I actually want to check my accounts here. If I don't, then none of this is necessary. If I do, then special handling could only trip me up.
The whole point of automated checks is to make me stop and think and I like how those brakes are applied as is.

The one additional feature I would value in this workflow is if an option to `hledger print` could be used to enable passing directives (or only specific directives) through.
As it stands, when I want to generate validated reports, I have to `cat` the accounts files in a subshell.

As an additional convenience, since I split my journal into years, it would be extra special if print with a period expression could somehow constrain the printed directives to those generated from the corresponding dates.
(If anyone's interested, I've set up a makefile to make step one easier with this sort of journal scheme.)

I've considered a set of contributions along these lines, but I'm being slow to get around to it. Still lots of Haskell to learn.

I haven't had a chance to read the issues yet. So excuse me if I'm being redundant.

--
Panayotis Manganaris, M.Sc.
I do not read encrypted mail. Contact ptm.22 on Signal secure messenger.

Simon Michael

unread,
Oct 20, 2024, 2:58:45 PMOct 20
to hle...@googlegroups.com, Panayotis Manganaris
And shoot, I just realised that your message a few days ago has not been delivered here; I thought it had. Approving it now.

Panayotis Manganaris

unread,
Oct 20, 2024, 10:14:28 PMOct 20
to Simon Michael, hle...@googlegroups.com
"Simon Michael" <si...@joyful.com> writes:

> still a special case. I'm guessing it's not wanted or really needed

You predict me accurately. It seems this would only effect config file users i.e. I don't think `hledger print --infer-equity | hledger -f- -s bse` could be effected without a config file present. If config files could change behavior to this extent, I would simply opt out of using them. Though that would be a shame because they're handy for e.g. setting `--close-acct=E:ocb`. So, I can't welcome this feature even in this form. (I do see you've finalized the PR in agreement).

However, I reckon Xitian9's proposal is more acceptable to my sensibilities:

> What about providing a way to "declare" arbitrary subaccounts of a given account? Then you could declare equity:conversion:*

I also wouldn't use this, but at least the user would have to write account declarations explicitly, quite obviously exempting sub-accounts from checks.

Perhaps these wildcards would be a suitable compromise. My only hesitation is that this convenience might give users an out before they get a chance to read enough of the manual to learn about the power of `hledger accounts`

Thank you for welcoming my comments, Simon. I appreciate hledger all the more and hope to contribute soon.
Reply all
Reply to author
Forward
0 new messages