exempt conversion accounts from strict account checking ?

[simonmichael]

--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 commodity-named accounts, but they seem to be worth keeping (that PR has some related discussion).

This PR proposes instead to exempt conversion accounts from check accounts, making --infer-equity easier to use.

• dev: cleanups

• dev: refactor, clarify detection of cost/conversion postings

• dev: refactor: clarify journalAccountTypes

• 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.

• imp: check accounts now always allows conversion accounts [#2247]

  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.

[simonmichael]

Now that I've toiled over this, I'm not sure if it's the best idea.

I expect this to be a usability improvement and not problematic in practice.

But any apparent weakening of checks just gives a bad impression, justified or not.

All comments welcome!

[simonmichael]

Some alternatives..

1. Keep the status quo. If you use --infer-equity and check accounts, you must add the two account declarations required for each commodity pair you exchange. Possibly make maintaining account declarations easier somehow.

2. PR #2262, drop the commodity-named conversion accounts. (Too big a loss, ruled out.)

3. This PR 2267: exempt all conversion accounts from check accounts. You don't have to declare them unless you want to.. but if you misspell them, check accounts can't warn you about it.

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.

5. Drop the per-commodity subaccounts used by --infer-equity; just keep the :COMMODITYPAIR accounts. That makes single-currency reporting just a little harder, but also means only one account declaration is needed per currency pair exchanged, not two.

... ?

[Xitian9]

What about providing a way to "declare" arbitrary subaccounts of a given account? Then you could declare equity:conversion:* (as an example). This would basically weaken the strict checking to provide certain exempted areas (subaccounts of a given account).

I would find this more useful generally, as I tend to use a limited number of top-level accounts, but go a bit nuts with subaccounts. (I have 768 accounts of depth 7). Strict checking is infeasible for me, but I would still love a way to make sure I haven't mis-spelt "restaurants" yet again.

[simonmichael]

What about providing a way to "declare" arbitrary subaccounts of a given account?

I am interested in things like this too. I haven't had a clear idea that seemed like a sure win. Explicitly allowing wildcards below certain accounts sounds like a good thing to try.

[simonmichael]

Here is related discussion on the mail list.

I started this thinking it was a small tweak but it turned out to be bigger than expected. I think this exception in check accounts is a bad idea after all, and I'll drop it.

It did force some useful cleanup though, so it's not a loss. I will push the other commits, up to and including "imp: default V accounts become just E when a new V account is declared". So in the end we're strengthening check accounts, not weakening it.

[simonmichael]

So in the end we're strengthening check accounts, not weakening it.

Correction, disregard that comment. We're keeping check accounts strong, as it was before. No change to check accounts.