#53 hold
Randy Becker

Create Account Groups for Imported Categories with Subcategories

Reported by Randy Becker | August 16th, 2009 @ 09:30 PM

It looks like Account Groups can be used are very similarly to the hierarchical structure of Quicken's categories. It would be nice if importing from Quicken automatically created account groups based on categories with subcategories. Of course, that would probably also mean adding support for nested Account Groups, and including an Account Group's name in the auto-completion box during data entry.

Comments and changes to this ticket

  • Virgil Dupras

    Virgil Dupras August 17th, 2009 @ 08:43 AM

    I'm not sure that the QIF format includes group names. If I'm not mistaken, they're part of the account name (like "group name:account name"). If #55 is to be implemented, the need for such a feature is greatly reduced, as you can just add a group, multi-select your accounts (which are next to each other because the group name comes first), and drag&drop them.

    As for nested groups and group-in-completion, I'm not sure about it, I'd need good use case for it. I remember Quicken, and I remember I disliked the way it handled account/groups. Is the current 1-level group system inadequate for some use cases?

  • Randy Becker

    Randy Becker August 17th, 2009 @ 05:54 PM

    Yes, they are implemented as part of the account name, but they function almost exactly like moneyGuru's account groups. Specifically, Quicken will let you aggregate accounts together that share a common prefix, just like moneyGuru will change the graph view based on whether an account group's account are disclosed.

    The only major difference is that Quicken allows for multiple levels of hierarchy, rather than just one. It's admittedly a little OCD, but I track Entertainment:Music:Song vs. Entertainment:Music:Album to see whether I spend more buying albums or individual songs, among other things. The deepest actual example I have is similar - Entertainment:Video:TV:Episode vs. Entertainment:Video:TV:Season.

  • Virgil Dupras

    Virgil Dupras August 18th, 2009 @ 09:55 AM

    I think that tags #36 would achieve the same thing as sub-categories, without the added complexity. One big problem I see with this feature is auto-completion. How should it be handled? If I want to type "Entertainment:Music:Song", I certainly don't want to type the whole thing. What then, auto-complete on every word? If I type "s", the field would go like "Entertainment:Music:S[ong]"? What happens if I then type "e", the whole field changes and goes to "Entertainment:Video:TV:Se[ason]"? What if a category also starts with "se"? That seems like a very confusing auto-completion.

  • Randy Becker

    Randy Becker August 25th, 2009 @ 05:49 PM

    I'm not sure that tags are a good idea. Double-entry accounting has an elegantly simple mental model: every transaction is a transfer between accounts. I think that adding tags would break this, and add complexity, but I'm not certain that I really understand how tags would work.

    I think auto-completion is something that could be improved, whether or not subgroups are added. Right now, alternate completions are offered in an order I don't find predictable. If instead, completions were offered in lexicographical order, it would be straightforward to use Quicken-style account names to auto-complete efficiently.

    Coming from Quicken, I was surprised that auto-completion didn't include the group name. I think this is the right decision, however, because account groups are not themselves accounts, unlike in Quicken. This Quicken quirk can be emulated, however, by creating an account with the same name as the account group. Doing it that way also keeps a clear distinction between accounts and groups. Accounts are the things between which money is transferred; groups are helpful for organizing accounts and manipulating graphs.

    The auto-complete in Quicken worked well enough. At least, it was predictable. It auto-completed one group name at a time, starting at the highest level categories. For example, when I type "en", it completes "Entertainment," with the "tertainment" part selected. If I press the right arrow, I can type a colon and it auto-completes the first sub-account: "Entertainment:Audiobooks," with the "Audiobooks" text selected. Pressing the down arrow instead of the right arrow would cycle through other completions of the typed (unhighlighted/selected) text. In this case, typing "en" followed by the down arrow results in "Entertainment:Audiobooks" with "tertainment:Audiobooks" selected.

    Adding support for subgroups wouldn't make things more complicated for anyone that didn't need to use them. I don't think Quicken's default list of categories, for example, includes any subsubcategories. Having account groups is really useful. They let you quickly include or exclude accounts in a given view, which makes "reporting" incredibly intuitive and tactile. Adding subgroups would just be to take the existing interface one step further in the direction it has already gone.

    Admittedly, there would be less of a need for account subgroups if #55 were implemented. Selecting entire pseudo-subgroups (accounts named a la Quicken) would be easier, since accounts are sorted lexicographically within account groups.

  • Virgil Dupras

    Virgil Dupras August 25th, 2009 @ 06:43 PM

    I'm not sure about tags either. I don't have enough use cases for it to convince me. My own use case is to separate "business" transactions from "personal" transaction, instead of having to create duplicate accounts, like "Business Software", "Personal Software". One thing is certain, if they were implemented, they wouldn't break the double-entry principles. A transaction would still be a transfer of money between 2 or more accounts. The only difference is that additionally, there would be the possibility to attach labels to it. You could see tags as a special "Memo" field, which would be indexed for use in the search field.

    The way auto-completion works right now is that the suggestions are sorted in "last time used" order. This means that the accounts you use the most are usually placed first in the suggestion list. It prevents seldom used accounts to "poison" the auto-complete list. Sure, it makes it less predictable, but I think that it makes the whole system more efficient in the end (the way to describe how Quicken's auto-completion works seems very inefficient to me).

    If the main benefit of nested groups is the ability to quickly exclude/include accounts, then I'd rather implement #55 than this ticket.

  • Virgil Dupras

    Virgil Dupras September 5th, 2009 @ 07:10 PM

    • Tag changed from import, quicken, suggestion to feature, import, quicken

    [not-tagged:"suggestion" tagged:"feature" bulk edit command]

  • Virgil Dupras

    Virgil Dupras April 30th, 2010 @ 09:11 AM

    • State changed from “new” to “hold”

    Nope, I don't think this ticket can work, especially because of the incompatibility between Quicken's nested groups and moneyGuru's 1-level groups. With #55 being scheduled for implementation, post-import re-organization should be pretty easy.

  • Geoffrey Lowney

    Geoffrey Lowney November 8th, 2011 @ 04:03 AM

    • Milestone order changed from “0” to “0”

    I understand there is less need for this given your change to allow multiple accounts to be selected at the same time. I also understand the difficulty around Quicken's multi-level sub-accounts (e.g. Auto:Loan:Interest & Auto:Loan:Principle), and your not necessarily wanting to open the door to multiple levels of Account Groups. But I wonder if it wouldn't be reasonable to create a single level of Account Groups from the first level of Quicken categories when subcategories are detected. That is, given my Auto example, the program could create the Auto group automatically, and then put Loan:Interest and Loan:Principle inside. Perhaps this is not a big deal in the general sense, but as users try to switch over I expect many will need to re-import their Quicken data many times, and re-creating the account groups would be a pain. Obviously I could just "tweak" my copy of the code for this, but I wonder if you have any additional thoughts on this.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Shared Ticket Bins

People watching this ticket

Attachments

Pages