simonmichael / hledger

Robust, fast, intuitive plain text accounting tool with CLI, TUI and web interfaces.
https://hledger.org
GNU General Public License v3.0
2.85k stars 307 forks source link

Allow arithmetic expressions in balance assertions #861

Open sequba opened 5 years ago

sequba commented 5 years ago

It'd be nice if one could write:

2013/1/2
  a    $1  = $2 + $2
  b
amitaibu commented 4 years ago

Here's a real world use case for why and how we would use this feature: We have credit line in our bank of for example $100 - meaning we are able to go $100 below 0.

So, if our balance shown in the bank is 0, than we look at it as if we in fact had $100. The reason we do this, is that if for example our balance was $-60, then we would treat it as $40 - and it won't be in the red.

The way I would have wanted to use it, would be in a CSV rules file, have something like:

fields date, description, bal
balance (%bal +100)
alerque commented 4 years ago

@amitaibu I'm not sure your use is a good case study for this feature. I for one wouldn't lift a finger to "fix" that case because I strongly believe it isn't broken.

So, if our balance shown in the bank is 0, than we look at it as if we in fact had $100.

But you wouldn't actually have $100, so why should the app be expected to report it as such? What you actually have below $0 is a liability debt to the bank in the amount that they have extended you credit. If you really insisted on misrepresenting your financial status you would just add an entry showing a $100 deposit into the account. Of course with double entry accounting you would balance that against a liability account, say for the credit your bank extends. Summing that with your actual account would show the correct real balance.

I'm not saying math expressions shouldn't be allowed –I would find them useful– but perhaps you should address that case study another way with existing tools such that the values are what they say on the tin. :wink:

amitaibu commented 4 years ago

Yeah, I guess my above (simplified) example isn't passing correctly what I'm doing which is a mix of keep tracking of past events and some forecasting. I'll hide that comment, as it probably just adds noise - sorry about that, and thanks @alerque for pointing it out.