GNOME Bugzilla – Bug 569200
I'd like to have *several* accounts (or hierarchical tags) per split
Last modified: 2018-06-29 22:16:42 UTC
Right now, in normal double-booking, each transaction has exactly 2 sides (source and target), and exactly 2 accounts (one for each side). This allows to say that my money went "from" my bank account 123 "to" Expenses:Infrastructure:Phone. That's the classical financial booking. However, that breaks down, if you have many different reasons for expenses, and need to track them. For example, I have phone, car and travel costs, *each* for private, business, and even a specific customer and a specific hobby. In other words: Infrastructure:Phone, Travel:Restaurant is the *kind* of expense. Private:Hobby:Development:Project Y, Private:Child:Martin and Business:MyCorpA:Customer:MyCustomerF are *reasons* for expenses. I want to know the phone costs in total ("kind" account), all costs for a customer or hobby ("reason" account), and the travel costs for a specific customer (intersection "kind" and "reason" account). I need this for taxes, invoices, and for my own information and financial planning. Can I affort another car? (kind account) How much did me cost this hobby? (reason account) How much can I tax-deduct? Proposal: Therefore, I'd like to be able to assign one side of a transaction to *several* accounts at once. It should be an arbitrary number of accounts (>=1), and the accounts are also arbitrary and hierarchical - this allows me to design the account system myself, and doesn't restrict it to the kind/reason examples I gave above, but allows me to e.g. invent a third hierarchy for tax deduction or whatever. Also note that it's important that they are hierarchies: I want the sums of all expenses for a company, all hobbies of me or my wife, all private costs etc.. I realise this is departing from classical financial booking, but I think it's a logical and inherently sensible extension of it which may even catch on beyond gnucash.
Correction of proposal: Allow n (n >= 1) accounts per "split".
My above statement about transactions having exactly 2 accounts was wrong. A transaction has n (n >= 2) splits, and each split has exactly 1 account. My proposal is to allow n (n >= 1) accounts per split. warlord and joslwah think that this would be a bad idea, but warlord proposes "hierarchical tags". Tags could work just like accounts - I would even call them "additional accounts" (not used for booking, but can be filtered for and used in reports), and reuse the account DB and UI code, but it doesn't matter, as long as they are hierarchical. So, for each split, in addition to 1 account, I could specify n (n >= 0) "additional accounts" or "hierarchical tags". I can then filter and report on them just like I can now on accounts, including showing them in the transactions UI, creating pie and sum reports for them etc.. It's important that they are efficient to enter in the transactions UI, because I'll have to classify all my transactions with them. I don't know how that UI would look like exactly.
<warlord> We could probably reuse the Account code pretty much as-is, just with a new "Root" account that's the TAGS root. (That's exactly what I meant)
I think this is the same thing as this very old enhancement request I found. In effect you'd like to assign additional sorting categories to your transactions or splits. Feel free to propose this, but keep in mind how long the old request has been lying around here without anything done about it. *** This bug has been marked as a duplicate of 113772 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=569200. Please update any external references or bookmarks.