Support assertions which include subaccounts

[mathstuf]

I have the current accounts for each credit card:

credit:bank:card
credit:bank:card:bill

I would like to assert on the outstanding balance on each card, but there is no way to take the amount paid in bills to the card when asserting on its balance.

Is there a better way to structure the accounts? I'd really like a separate one for the bills to go to so I can see how much I've paid over time, but if there's some other way to do so with a merged account, that'd be fine too.

[simonmichael]

I agree we should have some way to assert on the subaccount-inclusive balance. (#195 is another balance assertions wish.)

I'm not familiar with how you're using the subaccount here. Can't you easily see what you've paid over time with a report ?

[simonmichael]

PS for example, I'm thinking of something like:

hledger register credit:bank:card amt:'<0'
hledger register credit:bank:card amt:'<0' -Q
hledger balance  credit:bank:card amt:'<0' -MA

[mathstuf]

On Sun, Oct 18, 2015 at 16:53:14 -0700, Simon Michael wrote:

I agree we should have some way to assert on the subaccount-inclusive
balance. (#195 is another balance assertions wish.)

I'm not familiar with how you're using the subaccount here. Can't you
easily see what you've paid over time with a report ?

As for how the accounts are used:

credit line -> card
card -> purchase
card -> purchase
card -> purchase
card -> purchase
credit line increase -> card

which all works fine. I also need an account to pay off bills. My
thought was to use a subaccount so that I can see it individually, but I
guess I could just use queries to get this information instead. Playing
around with it, it seems to be sufficient.

Setting the card == bill account and instead splitting the credit line
into a subaccount lets me assert on values matching the bills.

[mathstuf]

On Sun, Oct 18, 2015 at 20:56:43 -0400, Ben Boeckel wrote:

Setting the card == bill account and instead splitting the credit line
into a subaccount lets me assert on values matching the bills.

Maybe adding such a layout should be put into some kind of
documentation? I'd also be interested in recommended layouts for things
like refunds (where I use a :refund subaccount), 401k tracking with
shares, and other common patterns. For example, I'm now thinking that
refunds shouls use the same account, but managed using queries.

For example, here is how I handle increases in pledge values on
Kickstarter:

04-23=03-22 * Item - Kickstarter
    account for item        $99.00
    source account

04-23=04-04 * Item boost - Kickstarter
    account for item       $199.00
    account for item       $-99.00
    source account

Where the transaction date is that of the pledge or increase and the
clear date is when the kickstarter ended.

And then if the Kickstarter fails:

04-23 * Item failure - Kickstarter
    account for item      $-199.00
    source account

Having all the clear dates be the same ensures that no assertion is
problematic, but I can also accurately budget before it ends.

[simonmichael]

Maybe adding such a layout should be put into some kind of documentation?

Yes please! (But where ? Too big a topic to discuss here, but a good h/ledger cookbook is needed).

[mathstuf]

Well, some place on the website would be nice, but I think soliciting advice from the h/ledger lists on how others approach it would be a first step.

[simonmichael]

Back to the topic at hand - if you come up with a design for this, let me know. I assume I can't just make it work that way by default, because it would cause unexpected breakage and confusion when switching between Ledger and hledger.

[mathstuf]

Maybe use == or some other (currently invalid) token? Maybe =~ would work too, but maybe that is too perl/shell-ish.

[simonmichael]

I was going to use == for "all commodities, not just one" - how could we cover all four of these cases (or should we ?)

[simonmichael]

Well, answering myself, you could do the obvious:

=  - one commodity, exclude subaccounts (Ledger default)
==  - all commodities, exclude subaccounts
===  - one commodity, include subaccounts
====  - all commodities, include subaccounts

I think not, too hard to remember.

[mathstuf]

I don't think multiple commodities is needed; can't you just have multiple assertion transactions?

[simonmichael]

We need a way to say that no other commodities are present, too.