New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow account types (asset, liability..) to be declared #877

Merged
merged 3 commits into from Oct 10, 2018

Conversation

Projects
None yet
3 participants
@simonmichael
Owner

simonmichael commented Sep 27, 2018

From hledger list:

I'd welcome your thoughts or review on #877,
which fixes the long-standing dependence on english account names in bs/cf/is.
...
I forgot to provide a clear example. The idea is you declare the types of your five top-level accounts. In english, the standard account names are recognised automatically so this would be redundant, but you could write:

; account types are ALERX. At least two spaces between account name and type.
account assets       A
account liabilities  L
account equity       E
account revenues     R
account expenses     X

While in french, you could write, if you were using names from https://fr.wikipedia.org/wiki/Plan_comptable_g%C3%A9n%C3%A9ral_(France)#Cadre_comptable :

account Comptes de capitaux        L
account Comptes d'immobilisations  A
account ???                        E
account Comptes de produits        R
account Comptes de charges         X

I'm not sure where Equity fits in the french chart of accounts. Does this point out a weakness in this ALERX scheme ?

@hpdeifel

This comment has been minimized.

Collaborator

hpdeifel commented Sep 28, 2018

Nice! I use german account names and the hardcoded english names were always annoying to me. I have a custom shell alias that passes --alias to hledger for all ALERX accounts but had to remember to use it only for bs, is and friends as I wanted to see the german names in bal or reg...

Replacing those aliases with account declarations worked really well in my limited testing, but I haven't tried to do anything fancy with non-toplevel accounts.

About the syntax:

What's the reason for using single letters (ALERX) instead of just spelling out the words (Assets, etc...)? After all you're probably going to need this only once per journal, so the extra typing overhead wouln't be significant. On the other hand i think complete words be much more readable (especially if you don't know the english names off the top of your head and wonder what those letters might stand for).

I also kinda hate the syntactic significance of one vs. two spaces, especially because the difference between

account Einnahmen  R
account Ausgaben   X
account Vermögen   A
account Schulden   L

and

account Einnahmen R
account Ausgaben  X
account Vermögen  A
account Schulden  L

is just that "Einnahmen" isn't considered a revenue account. But I think that ship may have already sailed.

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Sep 28, 2018

Thanks for the feedback.

What's the reason for using single letters (ALERX) instead of just
spelling out the words (Assets, etc...)? After all you're probably
going to need this only once per journal, so the extra typing
overhead wouln't be significant. On the other hand i think complete
words be much more readable (especially if you don't know the
english names off the top of your head and wonder what those letters
might stand for).

  • Since the goal was to fix anglocentrism, I figured single letters
    would be more pleasant for non-english-speakers than a bunch of
    english words.

  • I figure these will be used more often than we'd think - you might
    have multiple journals for different purposes, you might set up a new
    chart of accounts each year - so reading and typing out the full words
    repeatedly would feel tedious.

  • if you write the full word there can be confusion about spelling.
    ASSET or ASSETS ?

I take your point that some folks might find the full word, even if
not in their language, clearer than just the first letter.

Should we allow a choice then ?
(A|L|E|R|X|ASSET|LIABILITY|EQUITY|REVENUE|EXPENSE), case insensitive ?

I also kinda hate the syntactic significance of one vs. two spaces,
especially because the difference between

account Einnahmen  R
account Ausgaben   X
account Vermögen   A
account Schulden   L

and

account Einnahmen R
account Ausgaben  X
account Vermögen  A
account Schulden  L

is just that "Einnahmen" isn't considered a revenue account. But I
think that ship may have already sailed.

I hear that. Double space is pretty baked in to *ledger at present,
and we use it in a few places by now. I'm open to other ideas.

Another option is to support comments and tags like txns/postings:

account Assets ; type:A

I want to add this, but I felt we should also have a shorter syntax
for such a common declaration. The above feels a bit boilerplatey.

Another option is one-letter tags:

account Assets      ; A:
account Liabilities ; L:
account Revenues    ; R:
@tonyxiao

This comment has been minimized.

tonyxiao commented Oct 9, 2018

could this be used to associate generic tags with accounts?

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 9, 2018

simonmichael added some commits Sep 27, 2018

journal: account directives can declare account types
Previously you had to use one of the standard english account names
(assets, liabilities..) for top-level accounts, if you wanted to use
the bs/bse/cf/is commands.
Now, account directives can specify which of the big five categories
an account belongs to - asset, liability, equity, revenue or expense -
by writing one of the letters A, L, E, R or X two or more spaces after
the account name (where the numeric account code used to be).

This might change. Some thoughts influencing the current syntax:
- easy to type and read
- does not require multiple lines
- does not depend on any particular account numbering scheme
- allows more types later if needed
- still anglocentric, but only a little
- could be treated as syntactic sugar for account tags later
- seems to be compatible with (ignored by) current Ledger

The current design permits unlimited account type declarations anywhere
in the account tree. So you could declare a liability account somewhere
under assets, and maybe a revenue account under that, and another asset
account even further down. In such cases you start to see oddities like
accounts appearing in multiple places in a tree-mode report. In theory
the reports will still behave reasonably, but this has not been tested
too hard. In any case this is clearly too much freedom. I have left it
this way, for now, in case it helps with:

- modelling contra accounts ?
- multiple files. I suspect the extra expressiveness may come in handy
  when combining multiple files with account type declarations,
  rewriting account names, apply parent accounts etc.
  If we only allowed type declarations on top-level accounts, or
  only allowed a single account of each type, complications seem likely.
bs/bse/cf/is: use account type declarations if any
These commands now detect the account types declared by account directives.
Whenever such declarations are not present, built-in regular expressions
are used, as before.

@simonmichael simonmichael merged commit e4215c0 into master Oct 10, 2018

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 10, 2018

Experimentation will continue, but this is now merged.

@hpdeifel

This comment has been minimized.

Collaborator

hpdeifel commented Oct 14, 2018

Sorry for the slow replies.

* Since the goal was to fix anglocentrism, I figured single letters
  would be more pleasant for non-english-speakers than a bunch of
  english words.

I still think that as a non-native english speaker, I'll have no clue what "ALERX" stands when I need it and would have to look it up in the documentation. Also, I'm not going to need those often, so spelling them out would be absolutely fine.

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 18, 2018

Noted. A new wrinkle: we might drop the A letter/ASSET word syntax in favour of some tag like

account asset ; type:A

and the same would apply there, we could allow type:ASSET.

Pro:

  • less special syntax. You don't need to declare many types so the extra typing/noise is not a big deal.
  • more Ledger compatible (presumably)
  • easier to make ledger-mode compatible (just need to teach ledger-mode to ignore comments when autocompleting)

Unknown:

  • upper case or case insensitive ?
  • ok to reserve very common "type" for this tag name for ? What word is left for account type as in "checking/cash/credit card/brokerage/..." ?

@simonmichael simonmichael deleted the sm branch Oct 18, 2018

@simonmichael

This comment has been minimized.

Owner

simonmichael commented Oct 19, 2018

On Oct 19, 2018, at 9:01 AM, Carel Fellinger wrote:

PS: type:a doesn't ring a bell here, so please use type:assets

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment