hrj / abandon

:relieved: Simple and Robust Accounting
Apache License 2.0
184 stars 26 forks source link

Support for commodities / units / currencies #124

Open hrj opened 7 years ago

jaa127 commented 7 years ago

I stumbled to Unit library written in scala Squants. It seems to be doing lot of stuff which would be handy with units / currencies.

In any case, it would be good to be able support at least following use cases: 1) "units" where there is constant conversion between units e.g.:

hrj commented 7 years ago

Agreed @jaa127

My design notes:

Optional

jaa127 commented 7 years ago

How about if there is formal account definition at the begin of parsing process (e.g. begin of ledger file or provided by config-file). This would allow to assing all kind of metadata to accounts (e.g. #108, #60), and define default unit / commodity per account.

It would also be handy, if you could mix commodities inside account. For example you could have cash in multiple currencies, and to have multiple cash accounts to be able handle multiple currencies is kind of inconvenient. It should also be desided how mixed commodities (tree) balances are handled in case of different commodities.

hrj commented 7 years ago

How about if there is formal account definition at the begin of parsing process (e.g. begin of ledger file or provided by config-file). This would allow to assing all kind of metadata to accounts (e.g. #108, #60), and define default unit / commodity per account.

Agreed; though I think we can build this later, once the core support for currencies is in place.

It would also be handy, if you could mix commodities inside account. For example you could have cash in multiple currencies, and to have multiple cash accounts to be able handle multiple currencies is kind of inconvenient. It should also be desided how mixed commodities (tree) balances are handled in case of different commodities.

I think all this is handled by my idea of using special account names. Basically, we already have a tree structure, and currencies can be just represented as children. It seems simpler from both user's and developer's point of view. It avoids the need to create a separate structure inside every account. I am not sure why you think it would be inconvenient. If you can give an example in a .ledger format, it would be useful to me.

jaa127 commented 7 years ago

I am not sure why you think it would be inconvenient. If you can give an example in a .ledger format, it would be useful to me.

The main reason is that there is need to maintain multiple separate accounts just for commodities.

Real example: There is car trip from Finland to Norway via Sweden. Finland is Euro (EUR), Sweden is Krona (SEK) and Norway is Krone (NOK). In each country I byu fuel and some other car related stuff.

If this is done without commodities as leaf accounts, then it could be something like this:

2017-02-01 car stuff in finland
    e:car      1 EUR ; general purpose car stuff
    e:car:fuel    20 EUR ; fuel
    a:cash

2017-02-01 car stuff in sweden
    e:car        10 SEK    ; general purpose car stuff
    e:car:fuel    200 SEK ; fuel
    a:cash

2017-02-01 car stuff in norway
    e:car       10 NOK   ; general purpose car stuff
    e:car:fuel  200 NOK ; fuel
    a:cash

If commodities are leaf accounts, then this gets really messy. Especially if I didn't know that I will visit Norway and Sweden by car, when Chart of Accounts was established....

hrj commented 7 years ago

Chart of Accounts is a good point. Out of curiosity, how do you define it in abandon currently? Or is it a concern for the future? Perhaps we can make currency accounts exempt from Chart of Account?

Hmm, from your example, I have another doubt:

2017-02-01 car stuff in sweden
    e:car        10 SEK    ; general purpose car stuff
    e:car:fuel    200 SEK ; fuel
    a:cash

What if a:cash has a balance of 100 SEK? Should abandon

  1. deduct 100 SEK from a:cash and try to deduct the remaining 110 SEK by converting from another currency?
  2. Or should it just allow the amount of a:cash to get negative?
  3. Or should it flag an error?

With the currency-as-leaf-account design the answer is 2. If there is an always-positive constraint set for a:cash it would result in 3.

hrj commented 7 years ago

Answering my own doubt:

If 1 is desired, then the transaction entry can be:

2017-02-01 car stuff in sweden
    e:car        10 SEK    ; general purpose car stuff
    e:car:fuel    200 SEK ; fuel
    a:cash    -100 SEK
    a:cash:_EUR

(balance adjustment would be done from EUR currency).

This will work with any design (leaf-currency-account or otherwise).