Thanks for this, but I wonder if you have read the previous thread I
linked to fully?  It discusses what I believe (from admittedly only a
quick scan) are the same techniques you describe here, and the problems
I ran into with those.

Or did I miss something?

Thanks again, I do appreciate any alternative approaches, it seems quite
likely I've missed a better way.

On Fri, 20 Oct 2017, at 23:58, Michael Cooper wrote:
> Ah, I misunderstood your original problem, apologies.
> 
> Dodging your question again (since I really don't know the answer), I've
> also found that storing values in non-leaf accounts gets me into all
> sorts
> of trouble. It generally is confusing and my automation doesn't
> understand
> it. If this example were in accounts, I would do this:
> 
> 2017-10-01 * Opening Balance
>     Assets:CurrentAccount:Real  $1000
>     Equity:OpeningBalance
> 
> 2017-10-02 * Savings
>     Assets:CurrentAccounts:Savings  $100
>     Assets:CurrentAccounts:Real
> 
> This works with the "assert account(...).total" style of assertion, but
> totally fails with the Reconcile method I posted (it thinks that there is
> $0 in Assets:CurrentAccounts). The assert style still doesn't show you in
> what direction it is wrong, unfortunately.
> 
> Alternatively, this sounds sort of like the envelope-budgeting system I
> use. Would something like the below be interesting for you?
> 
> 2017-10-01 * Opening Balance
>     Assets:CurrentAccount    $1000
>     (Budgets:SpendingMoney)  $1000
>     Equity:OpeningBalance
> 
> 2017-10-02 * Savings
>     [Budgets:Saved]          $100
>     [Budgets:SpendingMoney]
> 
> 2017-10-03 * Reconcile
>     [Assets:CurrentAccount]  $0 = $1000
> 
> The "Budgets" subtree are accounts made entirely of virtual transactions
> to
> track how money has been allocated, whereas the Assets subtree is about
> where money really is. I have scripts that help make sure that in
> transactions like 2017-10-01 the amount that the asset increases by
> balances with the amount the budgets increase by. I then have rules to
> automatically pair up Expense and Budget transactions.
> 
> On Fri, Oct 20, 2017 at 1:46 PM John Lee <j...@pobox.com> wrote:
> 
> > Hi Michael
> >
> > If you take a look at my previous thread here from a week or so back
> > you'll see the problem you run into when trying to apply that to the
> > transactions I posted in this thread.
> >
> > https://groups.google.com/forum/#!topic/ledger-cli/bqu-qNr6cjM
> >
> > Consider:
> >
> > 2017-10-01 * Opening Balance
> >     Assets:CurrentAccount   $1000
> >     Equity:OpeningBalance
> >
> > 2017-10-02 * Savings
> >     Assets:CurrentAccount:Savings   $100
> >     Assets:CurrentAccount
> >
> > 2017-10-03 * Assertion
> >     [Assets:CurrentAccount]   $0 = $1000
> >
> >
> > That final balance assertion fails for the same reason I mentioned in my
> > second post in the earlier thread:  that assertion refers not to the
> > summed-up total of everything in *or under* Assets:CurrentAccount (as
> > you'd see in the output of ledger b Assets:CurrentAccount), but the
> > amount that lives in that *exact* location (which you might write in a
> > balance command as
> > '^Assets:CurrentAccount$').  So $1000 errors, and $900 does not.  That
> > means I can't record the total balance of that real account, which is
> > what I'm after.  That's what motivated my use of assertion value
> > expressions, with which I guess I've either run into a bug, or I don't
> > understand something (see my previous post in this thread).
> >
> > I get the impression that transferring between subaccounts in this way
> > suggested here earlier, is a bit of a dark corner of ledger that's not
> > terribly well supported?
> >
> > I'm keen to hear about other approaches, but so far I'm running into
> > roadblocks whichever way I try to tackle using ledger the problem I set
> > out in that first thread (which is the same basic problem I'm trying to
> > solve here in this thread, though my question here was about a detail).
> >
> > I guess I should either dust off my very dusty C++ and try to fix it, or
> > try one of the ledger spinoffs like beancount... maybe there are
> > beancount / hledger people here who can comment re whether those systems
> > have ways to tackle the problem from the thread linked above?
> >
> > On Thu, 19 Oct 2017, at 23:54, Michael Cooper wrote:
> > > This isn't a direct answer to your question, but this is how I do these
> > > kind of balance checks:
> > >
> > > 2017/01/01 * Opening Balance
> > >     Assets:Checking    $1000
> > >     Equity:Opening
> > >
> > > 2017/01/02 * Savings
> > >     Assets:Savings  $100
> > >     Assets:Checking
> > >
> > > 2017/01/03 * Reconcile
> > >     [Assets:Checking]  $0 = $900
> > >     [Assets:Savings]   $0 = $100
> > >
> > > 2017/01/04 * Savings
> > >     Assets:Savings  $100
> > >     Assets:Checking
> > >
> > > 2017/01/05 * Reconcile
> > >     [Assets:Checking]  $0 = $800
> > >     [Assets:Savings]   $0 = $200
> > >
> > > This works well. I read these reconcile transactions as "If $0 is added
> > > to
> > > the account, the balance should be $800".
> > >
> > > If I instead change the last reconcile to "[Assets:Checking]  $0 = $700"
> > > (that is, make it $100 off) I get this error:
> > >
> > > While parsing file "/home/mythmon/tmp/foo.ledger", line 18:
> > > While parsing posting:
> > >   [Assets:Checking]  $0 = $700
> > >                           ^^^^
> > > Error: Balance assertion off by $-100 (expected to see $800)
> > >
> > > This shows me both the value I said it should be ($700), the value Ledger
> > > says it should be ($800), and the difference ($-100). All of these end up
> > > being very useful at different times.
> > >
> > > I leave these in my ledger files. This gives me both a history of
> > > balances,
> > > and also a sort of test suite. If I change the organization of my files,
> > > change rules, or do other refactoring, these assertions give me
> > > confidence
> > > that I didn't break anything.
> > >
> > > -Michael Cooper
> > >
> > >
> > > On Thu, Oct 19, 2017 at 3:43 PM John Lee <j...@pobox.com> wrote:
> > >
> > > > An example that currently has me puzzled: the first assert below
> > passes,
> > > > and the second fails.  I'm interested both in learning why in this
> > > > particular case, and more important, learning how to use ledger to
> > debug
> > > > problems like this in general.
> > > >
> > > > 2017-10-01 * Opening Balance
> > > >     Assets:CurrentAccount   $1000
> > > >     Equity:OpeningBalance
> > > >
> > > > 2017-10-02 * Savings
> > > >     Assets:CurrentAccount:Savings   $100
> > > >     Assets:CurrentAccount
> > > >
> > > > assert account("Assets:CurrentAccount").total == $1000
> > > >
> > > > 2017-10-03 * Savings
> > > >     Assets:CurrentAccount:Savings   $100
> > > >     Assets:CurrentAccount
> > > >
> > > > assert account("Assets:CurrentAccount").total == $1000
> > > >
> > > >
> > > > This surprises me because if I comment that last assert out and run
> > > > ledger b '^Assets:CurrentAccount$' I get $800, and ledger b
> > > > '^Assets:CurrentAccount:Savings$' prints $200 -- which adds to $1000,
> > > > and indeed ledger b '^Assets:CurrentAccount' prints $1000.  Bug??  How
> > > > can I see what ledger *thinks* the total is when it evaluates the
> > > > assert?
> > > >
> > > >
> > > > On Thu, 19 Oct 2017, at 23:13, John Lee wrote:
> > > > > Sometimes the assert expressions I'm adding to my ledger file fail
> > and I
> > > > > don't immediately know why.  If I have something like this:
> > > > >
> > > > > assert account("Assets:CurrentAccount").total == $123.45
> > > > >
> > > > > and I'm wrong about the total, then I'll just be told that I'm wrong,
> > > > > and not what the correct value is.  What's the easiest way to get
> > ledger
> > > > > to compute and print the correct value?
> > > > >
> > > > > Maybe there's a way to print out account values at a given point in a
> > > > > ledger file?  In particular, maybe there's a way to print the values
> > of
> > > > > value expressions as the ledger file is evaluated by a command like
> > > > > balance?
> > > > >
> > > > > I realize it's good to be able to see what the answer is before one
> > > > > writes it down, but sometimes it just saves time to have the computer
> > > > > work it out so you can see quickly what you did wrong.
> > > >
> > > > --
> > > >
> > > > ---
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Ledger" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > an
> > > > email to ledger-cli+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > >
> > > --
> > >
> > > ---
> > > You received this message because you are subscribed to the Google Groups
> > > "Ledger" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to ledger-cli+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Ledger" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to ledger-cli+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> 
> -- 
> 
> --- 
> You received this message because you are subscribed to the Google Groups
> "Ledger" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ledger-cli+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ledger-cli+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to