On Sun, Jan 03, 2016 at 10:33:32AM -0800, Martin Michlmayr wrote:
> This is something I need to solve as well and I haven't come up with a
> solution yet that I'm 100% happy with. I've changed the title of the
Thanks for this.
> What I came up with so far is this:
> - For joint accounts, just use a normal Assets: account, e.g.
> - For individual accounts (e.g. credit cards on a person's name) or
> accounts at the same bank due to historical reasons, add the name
> of the person to the account name, e.g. Assets:Savings:Bank Martin
> - I don't think a general Assets:Martin: makes sense because that
> defeats th whole purpose of combining finances (it's no longer
> "yours" vs "theirs" when you're married).
I'm doing the same. In my hierarchy the person is invariably the leaf
in any given branch of the hierarchy --- although to be fair I think
that just happened naturally, rather than as the result of a deliberate
hierarchy design choice.
> - However, there are some things that belong to a specific person.
> Specifically, I track frequent flyer miles and other reward points
> and for that I created Assets:Rewards:Martin since a) all those
> rewards accounts are for a specific person and b) usually both
> people have the same accounts.
> I don't think this scheme is ideal since it's inconsistent
> (Assets:Rewards:Martin vs Assets:Savings:Bank Martin instead of
> Assets:Savings:Martin:Bank) but unfortunately I cannot think of a
> cleaner solution.
I understand the problem, but I don't think it is specific to the
"spouse account" scenario. It is rather a consequence of the more
general fact that forcing accounts into being a hierarchy is an
artifice. With the exception of the tier 1 accounts that come from
double entry theory (assets/liabilities/equities/etc.), accounts are not
necessarily hierarchical. Rather, they are points in a multi-dimensional
vectorial space. Out of it you can extract several possible hierarchies,
neither of which is satisfactory for all use cases.
IIRC Martin Blais had a document discussing this issue in more details,
reaching out to the fact that tags too should sometime be considered
part of the account "hierarchy" and sometime not.
My bottom line here is that you will never be able to find a single
hierarchy that is completely satisfying. So as long as the tools we use
force us to choose a hierarchy, you need to cope with the resulting
frustration the best you can. In this case you should probably just cope
with querying on the ":Martin" substring as you suggested.
> Furthermore, while in the US you can do joint tax returns, this is not
> how it works in many other countries. So I still have to know income
> for each person. I guess I could look for 'Income:' on accounts with
> 'Martin' in the name.
As a work-around for this, I currently rely on the fact that me and my
spouse work for different employer, so I visually distinguish on
Income:Employer1 vs Income:Employer2. But that of course is unsatisfying
as a general solution because spouses can work for the same employer, or
have part of their incomes coming from the same entity in contexts that
do not match the employer/employee scenario.
But I also add "Payer:" and "X-Payee:"  tags to all Income:*
postings, so that I can do stuff like:
ledger balance --group-by "tag('x-payee')"
ledger balance --group-by "tag('payer')"
and have incomes grouped by person or paying entity. BTW, if people here
have better suggestions for the naming of the "payer" tag, I'd really
: the heading "X-" is to avoid the special semantics that ledger
associates to the "Payee" tag, which I find really annoying
> But maybe a cleaner solution would be account meta tags  which
> would allow me to define an owner.
That would be very useful in general, and yes also provide another range
of workarounds (but not a general solution IMO) for the single hierarchy
> Also, I think my idea of re-write rules / ledger views  would come
> in really useful here to define a view that separates stuff out by
> person again. Unfortunately this is not possible with ledger at the
> moment (I guess a beancount plug-in would be possible).
I had forget about this one, but I'll look it up again.