> >>>>> Martin Blais <[email protected]> writes: > > > It would be useful to build a list of real-world use cases of virtual > > postings and see if they can all be solved without or not - make a > > compelling argument about the need for virtual postings. > > I'd be interested to know your solution to the following problems, which were > the reason virtual postings were created in the first place. > > Problem The First > > I was a treasurer for my local religious community. We had 3 physical bank > accounts, and 5 virtual "community accounts". The physical accounts kept the > actual money, and represented our relationship with the outside world; the > virtual accounts indicated how that money had been allotted, and represented > our relationship with the community. The banks only cared about the real > accounts, and the community only cared about the virtual accounts. > > To prevent ridiculous amounts of double-booking, I invented virtual postings > so that money deposited by a transaction could immediately go to "two places > at once": both to the physical bank(s), and to the community fund(s). By > reporting with --real I saw only the world's view, and by reporting without > --real I saw the whole picture.
There is a crucial question to ask here, which divides this problem into two cases: "Are the virtual accounts straddling real accounts?" In other words, are each of the 5 virtual account's postings fully contained within the real accounts? If not, this is easily solved using subaccounts. Like this, for example: Assets:Real:Account1 Assets:Real:Account1:Community1 Assets:Real:Account1:Community2 Assets:Real:Account2 Assets:Real:Account3 Assets:Real:Account3:Community3 Assets:Real:Account3:Community4 This gives you three real accounts: Assets:Real:Account1 Assets:Real:Account2 Assets:Real:Account3 And five community accounts: Assets:Real:Account1:Community1 Assets:Real:Account1:Community2 Assets:Real:Account2 Assets:Real:Account3:Community3 Assets:Real:Account3:Community4 By looking at reports for 'Assets:Real:Account1', you are looking at the register of all real transactions. In practice, transfers between the community accounts there in will be few and easy to ignore when looking at the register. This _does_ hinge on the capability to display a register of transactions for a parent account that includes all of the postings of child accounts. (This is how Beancount renders a journal of transactions for a parent account by default.) If the community accounts straddle the real accounts, you just filter by the CommunityX bit. Imagine for a moment the worse case, that all real accounts have all community subaccounts (in practice this rarely occurs, BTW, real-world structure is always more constrained than this deliberately chosen "full-product of dimensions" example): Assets:Real:Account1:Community1 Assets:Real:Account1:Community2 Assets:Real:Account1:Community3 Assets:Real:Account1:Community4 Assets:Real:Account1:Community5 Assets:Real:Account2:Community1 Assets:Real:Account2:Community2 Assets:Real:Account2:Community3 Assets:Real:Account2:Community4 Assets:Real:Account2:Community5 Assets:Real:Account3:Community1 Assets:Real:Account3:Community2 Assets:Real:Account3:Community3 Assets:Real:Account3:Community4 Assets:Real:Account3:Community5 You can filter by just looking at the Community1 accounts: Assets:Real:Account1:Community1 Assets:Real:Account2:Community1 Assets:Real:Account3:Community1 Looking at the balance sheet / income statement / journals for this subset of postings will give you all the reports you need for project Community1. This is a common case: Imagine you and your wife/life partner are both working professionals and share a joint account for convenience of making common expenses (e.g. you're going to a restaurant together and one of you pays but you want to generally split the expense, you also use those joint funds to pay for individual expenses, etc.). You want to account for each other's contributions separately. You would get a real bank account and create two subaccounts in it: Assets:US:Bank:Joint:Husband Assets:US:Bank:Joint:Wife 'Assets:US:Bank:Joint' is the real underlying bank account. An expense paid from that debit card would be booked like this: 2014-05-19 * "Dinner together at favourite sushi place" Expenses:Restaurant 101.20 USD Assets:US:Bank:Joint:Husband -65.00 USD ; A bit extra for sake box Assets:US:Bank:Joint:Wife I've been using this for real and has worked for me so far. No virtual accounts. (digression not about virtual postings but answers auxiliary questions about them) Now this points to a more general idea that I've been pondering for a while: these "accounts" can often be seen as a set of flat dimensions, the fact that they have a hierarchy can get in the way. I tend to have accounts that look like this: TYPE:COUNTRY:INSTITUTION:ACCOUNT:SUBACCOUNT like this, for example: Assets:US:HSBC:Checking Assets:CA:RBC:Savings For these four dimensions, I actually like having most accounts (Assets, Liabilities and Income) specify them in this order. This does not always make sense though, especially for expense accounts; for those you wouldn't really want to have a COUNTRY dimension at the root. You want the general category only, so I'll have, for example: Expenses:Food:Restaurant Expenses:Food:Grocery but sometimes the dimensions get inverted too, like in my recent change about how to track taxation: Expenses:Taxes:US:TY2014:Google:Federal Expenses:Taxes:US:TY2014:Google:StateNY Expenses:Taxes:US:TY2014:Google:CityNYC ... Here the "institution" is Google, and shows deeper in the hierarchy. Finally, you often do want to have multiple types for the same or similar accounts, for instance, to track gains and dividends income from a particular investment account, you want a mirror of most of the dimensions except for the assets bit: Assets:US:ETrade:IRA -> Income:US:ETrade:IRA For instance: Assets:US:ETrade:IRA:Cash Income:US:ETrade:IRA:Dividends You see what I'm getting at... these components really operate more like a database table with values possibly NULL, e.g., type country institution account category -------- -------- ------------ --------- ----------- Assets US HSBC Checking NULL Assets CA RBC Savings NULL Assets US ETrade IRA Cash Income US ETrade IRA Dividends Expenses NULL NULL Food Restaurant Expenses NULL NULL Food Grocery Having to order your account components in a hierarchy forces you to decide how you want to report on them, a strict order of grouping from top to bottom. So I've been thinking about an experiment to rename all accounts according to dimensions, where the ordering of the components would not matter. These two would point to the same bucket, for example (changing the syntax slightly), Expenses|Taxes|US|TY2014|Google|Federal Expenses|US|Google|Taxes|TY2014|StateNY You could then display reports (again, the usual reports, balance sheet, income statement, journals) for "the subset of all transactions which has one posting in an account in <set>" where <set> is defined by values on a list of dimensions, a bit like a WHERE clause would do. Now, now, now... this would be a bit radical, now wouldn't it? Many of these accounts do point to real accounts whose postings have to be booked exactly, and I'm a bit worried about the looseness that this could introduce. One and only one account name for a particular account is a nice property to have. So what can we do to select across many dimensions while still keeping hierarchical account names? The first thing I did in Beancount is to create views for all unique account component names. For example, if the following account exists: Assets:US:ETrade:IRA You will see four "view" links at the root of the Beancount web page: Assets US ETrade IRA Clicking on the link selects all the transactions with a posting with an account where that component appears. (Views provide access to all the reports filtered by a subset of transactions.) You can click your way to any journal or report for that subset of transactions. This exists in HEAD today. You can draw all the reports where a particular component appears, e.g., "Google", as in "Income:US:Google:Salary" and "Expenses:Taxes:US:TY2014:Google:Federal". But this does not define "dimensions." It would be nice to group values for these components by what kind of thing they are, e.g., a bank, an instution, a country, a tax year, etc, without regard for their location in the account name. A further experiment will consist in the following: again assuming unique "account component names" (which is not much of a constraint to require, BTW, at least not in my account names), allow the user to define dimensions by declaring a list of component names that form this dimension. Here's how this would look, with the previous examples (new syntax): dimension employer Google,Autodesk,Apple dimension bank HSBC,RBC,ETrade dimension country US,CA,AU dimension taxyear TY2014,TY2013,TY2012,TY2011,TY2010 dimension type Assets,Liabilities,Equity,Income,Expenses (implicit?) You could then say something like "show me trial balance for all transactions with posting accounts where bank is not NULL group by bank" and you would obtain mini-hierarchies for each group of accounts (by bank, across all other dimensions). (With the state of my current system, I could probably code this as a prototype in a single day.) Addtionally, accounts have currency constraints and a history of postings which define a set o currencies used in them. More selection can be done with this (e.g., show me all transactions with postings that credit/debit CAD units). IMHO, all you're trying to do with these virtual accounts is aggregate with one less dimension, you want to remove the real account and group by community project. My claim is that there are ways to do that without giving up o the elegant balancing rules of the DE system. -------------------------------------------------------------------------------- > Problem The Second > > Another religious duty I compute is effectively tithing (we call it > Huqúqu'lláh, and it's computed differently, but that's another story). In > order to compute the tithe owed, I accrue 19% of every deposit to a virtual > account, and then subtract from that account 19% of every needful expenditure. > The total remaining at the end of the year is what I owe in tithe. > > This tithing account is not a real account, as it exists in no financial > institution; but it is real enough as a personal duty. By using virtual > account, I can track this "side-band" Liability, and then pay it off from an > assets account when the time comes. If I report with --real I will simply see > how much I've paid to this Liability; and if I report without --real I see how > much Huqúqu'lláh is presently owed. If you have a single employer/source of income to pay the tithe on, or a single place where the income gets deposited, it's not much of a problem: just a create a subaccount for it. Let's look at it from the POV of the deposit account: Assets:US:BofA:Checking Assets:US:BofA:Checking:Tithe 2014-05-19 * "Booking tithe" Assets:US:BofA:Checking -300 USD Assets:US:BofA:Checking:Tithe 300 USD This again depends on the ability to render a journal that includes all subaccount postings. You can easily visually ignore these transactions in your Ledger, presumably you'll be doing it monthly or at the most weekly. When you transfer the money out for the donation, do it from the Title subaccount, e.g. 2014-05-19 * "Fulfilling my obligation" Assets:US:BofA:Checking:Tithe -1200 USD Expenses:Title The problem is that if you have multiple accounts to compute the tithe for, you can repeat this pattern, e.g. Assets:US:BofA:Checking ; Employer deposits Assets:US:BofA:Checking:Tithe Assets:US:Lulu:Cash ; Book royalties Assets:US:Lulu:Cash:Tithe Assets:US:WellsFargo:Checking ; Contract revenue deposits Assets:US:WellsFargo:Checking:Tithe This is the same problem and solution as before: you want to select all transactions with subaccount "Tithe" in them and produce various reports on this subset. Just select those transactions, you don't need virtual accounts. > Those are the only things I've actually used virtual accounts for, and was the > reason I added them. I've tried other schemes, like double-booking, but they > became unwieldy enough that I had to give up on them. I have a feeling > tagging might lead to a similar measure of complexity. The point is, is has > to be simple enough that I can keep up with it regularly, and yet rich enough > is expressivity that I'm able to solve the whole problem. Virtual accounts > ended up fitting this bill for me perfectly in these two cases. To me, tagging is just another mechanism to select a subset of transactions. Tagging is most useful when the list of transactions do not share something else in common, like an account, or expenses related to a project. A good example is a trip whose expenses are varied and from which the assets used are numerous, e.g. various credit cards, cash, debit accounts, maybe from various people. Tags are perfect to marking all those transactions as belonging to the same set. The executive summary: I think you can do everything by finding a way to select a relevant subset of transactions from non-virtual accounts. -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
