GNOME Bugzilla – Bug 113772
Add categories for more reporting flexibility
Last modified: 2018-06-29 20:32:26 UTC
Enhancement request: Please add user-definable categories which may be applied to each transaction, and also used as a filter for generating reports (could work similarly to keywords in Bugzilla). A possible solution is to use the "notes" field in each transaction. Reports filter transactions by account and by date range. Adding user-definable categories would allow more narrow selection. Example: my business sells clothing at retail events (fashion shows, street fairs, etc), and I want to track sales by event. Currently, I create an account for each event, and I am generating a clutter of accounts that are date-specific (e.g. "Revenue from May 11 Show"), which will eventually need to be swept into an "old sales" account because I will be overwhelmed with accounts. I would rather create one account whose purpose is timeless, and tag each transaction with a category (perhaps multiple categories), and later search or generate a report by category. Because sales events can overlap in time, generating reports simply by date range doesn't help me to understand where my revenue is coming from. Multiple categories will allow me to track orthogonal issues, such as "sales event" and "product type". Will also need a way to search for transactions by category (to view or change categories), and a way to see all categories in use (to locate mistyped categories).
*** Bug 569200 has been marked as a duplicate of this bug. ***
I need these categories to be hierarchical, and n (n >=0) per split. Personally, I see these categories as accounts. See bug 569200 for more info.
*** Bug 576525 has been marked as a duplicate of this bug. ***
*** Bug 165174 has been marked as a duplicate of this bug. ***
*** Bug 610778 has been marked as a duplicate of this bug. ***
There have been a lot of requests and discussions on this subject. Based on discussion in the mailing lists, I think there are also a lot of misconceptions about it. I think some people see that as going against the principle of double booking. Also the term "categories" reminds people of the quicken categories and therefore does not get a very good reception! I want to add my comments here because I too would love this feature. I am currently using a work-around I describe at the end... 1) This has nothing to do with quicken categories. Quicken categories are a half backed attempt at expense/income accounts. This is not what this is about. If we have to compare this feature to a quicken feature then it would be classes. But let's just forget about quicken please... 2) This is about adding features to perform analytical accounting: that is the ability to tag and report transactions along limitless user-defined dimension codes. In ERP and some accounting systems that implement the feature, these "categories" or "classes" are often called "dimensions" and maybe this should be the term, or event better "analytical dimensions" to be precise and avoid any quicken comparison (enough with quicken already!). 3) Analytical accounting is traditionally used for various tasks such as: - project or job costing: all transactions related to a particular project are tagged with a particular dimension, allowing to easily extract all expenses on a particular project for instance. - Grant/Budget accounting: if you are a non-profit organization, your are required to tag specific expenses that will then be reported to the funder as "charged" to a particular grant, although in your GL the grants are just reported as income for instance without needing to attach specific expenses to them. - Department costing: expenses for each department are tagged in order to help track budgets or project for next year or .... 4) Analytical accounting has NOTHING to do with double entry accounting. Double entry is essential to ensure your main ledger is properly balanced and all transaction properly accounted for. Analytical accounting (as its name implies) is only used for managerial analysis -- in fact accountants have usually no direct need for it and it has no legal/tax implications. 5) Yes, you can implement analytical accounting by using transitional accounts in you main chart of account (as Craig Lawson describes in his original post), but it is unnecessarily burdensome, as it multiplies the number of transactions that in fact should not be reported in the general ledger. As Craig Lawson says here in his original post, these are not accounting matters but "orthogonal" often time-bound managerial issues: how much stuff did we sell at event XYZ, what are the total expenses on project ABC. In fact, as Craig correctly points out, a single transaction can be and is often assigned to several dimensions: for instance an rent expense for a showroom (booked in the "rent" expense account--rent is the NATURE of the expense) could be tagged as related to the marketing department (a department dimension) and event XYZ for instance (an event dimension). Multiple assignments is almost impossible with GL accounts. 6) Analytical "accounts" do not balance in the same manner as GL accounts AND NEITHER SHOULD THEY as this is not their purpose. That said some checks can be put in place if necessary. For instance, if the rule is that all expenses have to be assigned to a "department" dimension then it is easy to ensure it is so; any expense not assigned need to be checked and fixed. But again, this has nothing to do with double-entry accounting. It is not incompatible with it: it functions in a completely parallel, orthogonal dimension. 7) The current work-around I am using is to create my dimensions has a bunch of accounts under a new high-level structure (Dimensions for instance). Then I create a sub-account for each type of dimension Departments, Projects, Events, etc). Finally under each sub-account I create sub-accounts for each actual dimension. These accounts will never have any money in them so they will not interfere with the real GL accounts. Instead, I simply use them to add additional splits pointing to the dimension accounts (with no amount) to any GL transaction I want to tag. For instance: I want to tag a $1000 rent expense to the 'Marketing' department dimension and 'ABC Street Fair' event dimension; I create the following split. Account Debit Credit Assets:Current Assets:Checking Account $1000 Expenses:Rent $1000 Dimension:Events:ABC Street Fair Dimension:Department:Marketing Then I can actually use the "Transaction Report" to see all transaction related to Dimension:Events:ABC Street Fair for instance. - Go in Reports-Transaction Report, then in the Report Options, go to the accounts tab. - Select all Report Accounts EXCEPT the dimension accounts and sub-accounts. - In the Filter accounts, select the dimension you want to report on (e.g. Dimension:Events:ABC Street Fair). - In the filter type, select "Include Transactions to/from Filter accounts"). - Change Display, General and sorting options as needed. - Now you have a transaction report for all transactions attached to the ABC Street Fair dimension.
This request is also one of the favorites in uservoice: http://gnucash.uservoice.com/forums/101223-feature-request/suggestions/1543027-transaction-classifications IMHO this is the wrong way. Please read a book about costing. The traditional way is to have 3 account classes for this: type of cost tax gas : cost location / cost centre department A department B : cost unit / cost objective product A1 : Then you move the costs whith their different breakdowns through this classes. Finally the cash flow report gives you the desired results.
> Then you move the costs whith their different breakdowns through this classes. That sounds like an awful workaround. I'll have 3 transactions for every transaction. I'd like to have only transaction, and assign it 3 target accounts, that would be a lot faster and simpler. In theoretical terms, these are different aspects (gas, department, product etc.), and I see no reason why I can't assign 3 aspects to transaction side. Please see bug 569200 for a longer explanation why this is needed.
Hi, I was also looking for this feature. It is really useful for short-term projects or activities. For example, I have different accounts like Food, Beer, Transportation. And when I travel to another city, for example, I would like to continue filling my expenses to these categories, but also mark all as NY-expenses, for example. So later I can simply search for all NY expenses as well as compare NY and non-NY food expenses.
Right. In fact, that's when accouting and GnuCash gets most interesting: Compare food in NY with food in France, or compare your truck's gasoline with your Porsche gasoline, but still to be able to see easily how much you spent for food or gasoline (no matter which category) in total.
If GnuCash was not constrained to using a flat data file format it would be a nearly trivial matter to implement a system of 'classes', 'dimensions', or 'tags'. I believe that there cannot be a nice implementation until the underlying data structure resembles a relational database. Vincent Dawans presents a very nicely stated summary in comment 6. I think that his suggested work-around also has merit. However, it does not handle the issue of applying different 'dimensions' to individual split lines, which I would consider essential in an actual implementation. Thus I would suggest that this discussion can continue as a debate about what features should be included in GnuCash, but a call to action must start with moving GnuCash along the migration path to a relational database file structure. GnuCash is already on that path, but the progress is painfully slow.
David, are you a developer working on GnuCash? If not, please avoid such statements. I'm a developer, but not of GnuCash, and I have to disagree. Even in a flat file structure, it's trivial to represent several dimensions, by just adding them as additional lines to the transaction. Same with the in-memory data structures. Pseudo-File: Account Name At Wells Fargo ... Category Name Mary Parent Person Description Expenses for our child Mary Category Name Virgin ... Statement Amount 35,23 Currency Euro Time 2014-01-20 Source-Account Bank:Family:At Wells Fargo Target-Account Expenses:Phone:Mobile Target-Category Person:Mary Target-Company Company:Virgin
Sorry, that's supposed to read: > Target-Account Expenses:Phone:Mobile > Target-Category Person:Mary > Target-Category Company:Virgin
*** Bug 671605 has been marked as a duplicate of this bug. ***
As a (fed up) Quicken user who is trying to move to GnuCash, I too would need some way to filter transactions that is separate from the Account classification in order to use GC in my work. I'd suggest accomplishing this by a fairly simple change: the ability to search all or selected accounts for transactions containing a specified string (in any field), and the ability to use the resulting lists of transactions in reports. The search ability is very useful for a number of things, for example looking for transactions of a specific amount when trying to find something that it is in the wrong account. But such a search capability could accomplish what most people want to do when they ask for, in essence, Quicken Tags (or Classes). Borrowing from Twitter, transactions could be assigned "hashtags" by putting "#xxx" anywhere in any field of a transaction. Doing it this way is intuitive and can be done using GC in its present form. I'm not an expert in GC so there may be a way to do this already that I just haven't found yet. But it looks like it would fit in as a new tab in the Filter function. It can be very simple and still be useful. -jimc
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=113772. Please continue processing the bug there and please update any external references or bookmarks.