On Fri, Aug 26, 2016 at 11:04 PM, Alok Parlikar <[email protected]> wrote:
> Hi Martin,
>
> I understand that generally balance assertions are relevant only for
> balance sheet accounts. However, I have a use case to use them on Income
> and Expense accounts, and I wonder what your advice would be on going about
> writing these assertions.
>
> I'd like to assert that, say, between 1 Jan and 31 Dec 2015, the "balance"
> in Income:Interest is XX. I have declared this amount in my tax return and
> would therefore like an assertion to prevent this amount changing
> "accidentally" in the future. The other purpose of doing this is to help
> with reconciliation at the end of the year. Example: a broker sends me what
> it's record of Income:ShortTermGains is, and I'd like to make sure my
> entries of the gains add up to the same value.
>
This is a valid use case and shares some aspects with budgeting constraints.
If you think about it, budgets are about avoiding too much of a delta over
a time period on an asset account.
This is very congruent with the general properties of accounts:
- Assets/Liabilities: Are snapshots, and we generally care only about the
particular value of them at a single point in time.
- Income/Expenses: Are changes, and we generally care only about the
changes over some interval over time.
A balance sheet is a snapshot of assets/liabilities accounts at a single
point in time (incl. net income).
An income statement is a report of differences of income/expense accounts
over a particular interval.
We have an assertion type for assets/liabilites accounts ("balance"
directive).
It only begs that we ought to also have an assertion for changes to
income/expenses accounts.
(And budgets are an application of the latter to the accounts of the
former.)
I see a couple of ways of doing it:
>
> 1. Writing assertions of actual balances rather than the "this years
> balance". Easiest to do, but makes the entries hard to read.
>
> 2. Writing a plugin that adds entries for each year and matches against
> given targets.
>
> Is there a simpler way? Or an alternative approach to handle the use case?
>
The Right Thing (TM) to do IMO is to design a new directive and implement
that in the core.
In the meantime, you could use the Custom directive type to prototype it in
a plugin, have your plugin run some code to check the difference.
One interesting question is how to carry this out efficiently (think: if
there are many many such constraints to be applied). Not sure it's so
important for a proof-of-concept though.
Thanks
> Alok
>
> --
> 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 post to this group, send email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beancount/010bc7ff-fa41-4720-8524-f40badd2f791%40googlegroups.com
> <https://groups.google.com/d/msgid/beancount/010bc7ff-fa41-4720-8524-f40badd2f791%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/CAK21%2BhOjjT-A1OYboDvVECQ-_xAr%3DUSUuLNS-XWJVt8%3DV%3DL5Sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
