Agree, for example I also have balances on every 1st January to be sure I do not change the past accidentaly.
Máté. On Sun, Jul 26, 2020 at 6:38 AM francois PEGORY <[email protected]> wrote: > Martin said: > Balance check needs to be applied on the tail end of time series only. > > I am not sure. If a balance apply at a definite date, it should always > apply at this date even if if the time serie goes beyond > It important for example for to catch the error where you put the wrong > date in the past. > Or if you add a transfer with a wrong account. > > Regards > > Le sam. 25 juil. 2020 à 07:53, Martin Blais <[email protected]> a écrit : > >> On Mon, Jul 6, 2020 at 7:31 AM Justus Pendleton <[email protected]> >> wrote: >> >>> 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. >>> >> >> Two really good points. >> In summary: >> - Budgeting needs a new type of balance check with automatic conversions. >> - Balance check needs to be applied on the tail end of time series only. >> >> >> >>> 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 :) >>> >> >> Other question: How does forecasting interact with budgeting? Is it >> necessary? >> >> >> >> >> >> >> -- >> 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/CAK21%2BhMZFnH6%2BVoNGN29JVhsoHShKJ66FRf-nYhHWt4i5tYoBw%40mail.gmail.com >> <https://groups.google.com/d/msgid/beancount/CAK21%2BhMZFnH6%2BVoNGN29JVhsoHShKJ66FRf-nYhHWt4i5tYoBw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CALUWbLc3BUQUgw7%2Bsyv7Dumsy_h_fa0Gb0Wt2bK6NW9GPQLJVQ%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CALUWbLc3BUQUgw7%2Bsyv7Dumsy_h_fa0Gb0Wt2bK6NW9GPQLJVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CABOOhz99Vc6SEXEFTHuieRN3%2BDy0WsWYf2i3jpV7V-sGvQPVLg%40mail.gmail.com.
