Re: Managing combined books for spouses

[Stefano Zacchiroli]

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
> thread.

Thanks for this.

> What I came up with so far is this:
> 
>  - For joint accounts, just use a normal Assets: account, e.g.
>Assets:Savings:Bank
>  - 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:" [1] 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
appreciate them.

[1]: 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 [1] 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
imposition.

> Also, I think my idea of re-write rules / ledger views [2] 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.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

-- 

--- 
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.

Re: Managing combined books for spouses

[Martin Blais]

On Mon, Jan 4, 2016 at 4:51 AM, Stefano Zacchiroli  wrote:

> On Sun, Jan 03, 2016 at 10:33:32AM -0800, Martin Michlmayr wrote:
> >  - 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.
>

That's the right way to look at command-line accounting: the contents of a
ledger are really nothing more than a giant stupid table of posting rows.
The account is just one particular column in the row. Meta tags are just
more implicitly defined columns.

Querying implicitly joins the attributes of the transactions to the tables
of postings, so you can use them directly.

Journals are listings of subsets of rows. Balance sheets and income
statements are aggregations where the key is "account". That's it.

-- 

--- 
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.

Re: Managing combined books for spouses

[o1bigtenor]

Greetings

I deplore top posting but as I have little specific (albeit general I
do) to say to what is described I will post separately.

Before any comments, I am not an accountant nor an expert on ledger
nor any other record keeping type program!

Even before I got married a number of years ago I found it necessary
to track expenses and all the other goodies for the number of small
entities (not companies by formal incorporation but by activity) and
in the process came up with this solution that is not simple but does
do the job, and I think well.

I started from the GIFI codes (both the USA and Canada use them but
they do somewhat differently). They are a 4 digit code for use by
incorporated entities for reporting financial information to taxation
entities.

What I did was add further digits, like this - - .yy.yy.yy   use
it something like this (using and asset account followed by an expense
account to illustrate). (I'm not sure all 6 digits are necessary but
that was my design choice.)

Asset account
1002.60.40.01

1002 - - - designates Deposits in Canadian banks and institutions -
in Canadian currency
.60 - - -  designates a particular institution
.40 - - - - designates a personal savings account (same number is used
 with all the different institutions)
.01 - - - designates a particular savings account (some institutions
have multiple accounts available

Expense account
9763.10.01.02

9763 - - -  designates Machinery repairs (Agricultural equipment would
be a different number for a non-farm business)
.10 - - - - designates vehicles
.01 - - - - designates trucks
.02 - - - - designates a particular truck

So when I need information for the tax authorities I poll using the 4
digit codes and when I want informaiton for my management (costing and
expenses) I use whatever level needed to supply what I need.

I started my account list using what was provided by the taxation
authorities. From this I developed by document (list) which is now 33
pages in length.

I do my accounts using a textfile program called leafpad which makes
for easy copy and paste which I use often.

Dee


On Mon, Jan 4, 2016 at 3:51 AM, Stefano Zacchiroli  wrote:
> 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
>> thread.
>
> Thanks for this.
>
>> What I came up with so far is this:
>>
>>  - For joint accounts, just use a normal Assets: account, e.g.
>>Assets:Savings:Bank
>>  - 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 

Re: Managing combined books for spouses

[Martin Michlmayr]

* Mark Scannell  [2016-01-03 05:40]:
> I was thinking of that, and I may use alias' as I have a lot of
> abbreviations. The challenge is that I have my partner's books, my
> books, and then our joint books. As our finances are gradually being
> treated as one, I'd like to be able to have Assets -> mine, Assets
> -> hers, Assets -> ours, Expenses -> mine|hers|ours, etc.

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
thread.

What I came up with so far is this:

 - For joint accounts, just use a normal Assets: account, e.g.
   Assets:Savings:Bank
 - 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).
 - 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.

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.  But maybe a cleaner solution would be account
meta tags [1] which would allow me to define an owner.

Also, I think my idea of re-write rules / ledger views [1] would come
in really useful here to define a view that separates stuff out by
person again.  Unfortunately this is not possible with leader at the
moment (I guess a beancount plug-in would be possible).

I'd like to hear how other people manage this.

[1] http://bugs.ledger-cli.org/show_bug.cgi?id=1070
[2] http://bugs.ledger-cli.org/show_bug.cgi?id=714
-- 
Martin Michlmayr
http://www.cyrius.com/

-- 

--- 
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.