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 - - xxxx.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 <z...@upsilon.cc> 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 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.
--
---
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.
