The v3 goals & design document expresses an openness to some kind of
support for budgeting semantics.
Beancount does not support budgeting constraints explicitly, but I think it
> would be possible to extend the balance assertion semantics to cover this.
>
> The current balance assertions check (a) a single commodity, and (b) that
> the amount is precisely equal to an expected one. Balance assertions should
> be extended to support inequalities, e.g.,
>
> 2020-06-02 balance Liabilities:CreditCard > 1000.00 USD
>
> and perhaps we could check for the total inventory like this
>
> 2020-06-02 balanceall Assets:Cash 200.00 USD, 300.00 CAD
>
> I'd be curious to hear what would work best from users who do budgeting
> and design a minimalistic expression language to support that use case
> (though I'd try to keep it as simple as possible to avoid feature creep)
>
I left a brief comment on the document based on my personal experiences
with budgeting. Martin asked for more detail & the mailing-list felt like a
better medium for that, so here it is.
I think that Martin's insight is a good one: there is a lot of similarities
between a balance statement and a budgeting constraint and it is tempting
to reuse the syntax (possibly with some extensions, as suggested above).
The more I think about, the more I think it should be a new directive,
rather than reusing the balance directive. The primary reason I say that
is: people are mostly going to want budgeting constraints to be in a
single, primary currency with magical currency conversions happening
underneath the covers for them. If your Expenses:Vacation budget is
USD$1,000 you're not going to be impressed if beancount tells you "you only
USD$500, congratulations you are under budget! Of course, you also spent
€1,500 and £750 on that vacation...."
I personally have finances & spending split across three currencies but
only think about budgeting relative to a primary currency. I would be
annoyed if I had to budget ₫79,000 because Spotify bills my Vietnamese
credit card separately from the AUD$9.99 I am billed by Netflix Australia
on my Australian credit card. I just look (plus a few others) at all that
as "eh, about USD$50 a month on digital streaming services".
But trying to make the existing balance statement handle currency
conversions seem fraught and not especially useful. It seems more less
confusing and error-prone to keep it as an exact equality assertion.
An additional reason to keep them separate: balance assertions are
"eternal" and hard errors but budget constraint violations are "ephemeral"
and soft warnings. If my beancount file violates a balance assertion then
that means my accounting is messed up and I start going through bank
statements to see what I did wrong. Then I edit my beancount history to
make things right. The balance assertion error goes away.
When I violate a budget constraint....I take note of that and decide eat at
home for the rest of the month. I definitely don't want beancount,
everytime it runs, to tell me "hey, back in November 1982 you violated the
budgeting constraint for Expenses:Restaurant".
Keeping them separate makes it easier to give them different runtime
behaviour. Maybe only show budget constraint violations from the the past
30 days. I dunno.
So my suggestion would be:
1. Keep balance directive mostly as-is. Add support for complete (and not
just partial) assertions. Consider supporting intra-day or end-of-day
balance statements. But I'm not sure they need to actually support
inequalities.
2. Add a budget directive that only accepts a single currency (i.e. doesn't
support the "complete assertions" syntax). Perform implicit currency
conversions to that currency. The amount is (implicitly, by reporting &
plugins) treated as an inequality but I'm not sure any syntax is required
to denote it.
(nb that even though these are different directives in the user interface
for clarity they might be unified into a single code path since, as
Martin's document points out, they share so many similarities)
That means a balance-statement is '=' and a budget-statement is '<='. My
proposal means there is no way to denote a '>=' assertion in beancount. I
can imagine uses cases for a '>=' assertion ("I don't want my emergency
fund to ever drop below $5,000") but they are purely theoretical for me so
I'm hard-pressed to care much about them. I'll leave it to others to argue
that maintaining full inequality support is a worthwhile goal :)
--
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/efde02e1-d9e4-463a-a5c3-73fd0430f5c7o%40googlegroups.com.
