+1 to this idea and Stefano's well reasoned response, leaf accounts are an annoying trade-off I often make too. I agree that the metadata approach seems best and totally backwards compatible to older parsers. It would be nice to have the open and closing plugins respect these leaf accounts and not complain if a channel subaccount isn't opened for each payee.
As for bql you could potentially use an option that let's the user decide whether channel subaccounts should be folded or not. If you want to get really fancy could let them specify a default leaf folding optionally in the query and then add case by case exceptions in the query also. Probably not worth the effort to give that level of control. On Wed, Jul 27, 2022, 01:19 Stefano Zacchiroli <[email protected]> wrote: > On Sun, Jul 24, 2022 at 12:25:45PM -0400, Martin Blais wrote: > > One of the topics we've discussed in the past is regarding the use of > > subaccounts over payees. > > As a general comment: +1 on the fact that this divide between payees > (or, more generally, per-posting metadata) and sub-accounts is a > problem. I consider sub-accounts to be better in general (they are more > controlled and easier to query), but they come with additional burden > (e.g., you need to declare them, open/close them, etc.) Having to > constantly decide "is this worth a sub-account" is for me recurringly > annoying. > > > Another idea, one that we never discussed, is the idea to have a > > special marker as part of the account name, marker which would > > automatically identify a portion of an account name as being a leaf, > > e.g., > > > > 2018-05-01 * "VISIT PATREON.COM/INSAN FRANCISCO CA" > "OPSNT_CMEVT > > 1234567890" > > Liabilities:US:Amex -10.00 USD > > Expenses:Online:Media/Safecast 3.00 USD > > Expenses:Online:Media/AbroadInJapan 3.00 USD > > Expenses:Online:Media/OnlyInJapan 2.00 USD > > I like the idea of having a given prefix of an account marked as > something under which you can freely create new leaf sub-accounts. But > why does it need an additional core concept and syntax? There might be > advantages, which I'm not seeing yet, but the cost of doing so seems to > be pretty high --- both in terms of code for the codebase and cognitive > overhead for users. > > It seems to me that the same idea can be implemented, as you suggested > earlier on, with a directive associate to the, in the example above, > "Expenses:Online:Media" account, which says "this account can contain > any number of leaf sub-accounts". > > Anyway, this is totally worth exploring, as it's an annoying problem in > the current state of affairs. Thanks for raising this. > > Cheers > -- > Stefano Zacchiroli . [email protected] . upsilon.cc/zack _. ^ ._ > Full professor of Computer Science o o o \/|V|\/ > Télécom Paris, Polytechnic Institute of Paris o o o </> <\> > Co-founder & CTO Software Heritage o o o o /\|^|/\ > Former Debian Project Leader & OSI Board Director '" V "' > > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/20220727081845.bh7uwx7yyi5xgiea%40upsilon.cc > . > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CACGEkZv2jH%2Bu7Ps5XkKkcmH1ko1vYH_YuYi331nT6HHBL_Zy0Q%40mail.gmail.com.
