A series of related ideas that will improve register readability and create a tagging mechanism
Add a notes column (narrow by default) to the "main" register display line. Monitors are wider and adding a narrow column should not hamper those who prefer double-line mode to see notes. But allowing for a notes field effectively doubles the number of transaction per screen for those for whom seeing notes is important. I have modified my source code to accomplish this, the chnage is trivial to implement.
Allow users to associate a foreground color with an account, that color whould be used for the acount name when displayed in a register. By allocating different colors to different types of accounts, it makes the displaying of only leaf names much more viable as an option when viewing a register, again making more efficient use of screen display space. (Not to mention color being a better way to convey the type of an account in a listing (category, checking, brokerage, tag, etc). Background color serves a different purpose and would not work will in the register listing.
3 Get rid of the blank line at the end of a split transaction listing. Add a menu option for "Add split" that would add a blank line when needed. All those blank lines make the register listing less readable (useless "noise") and decreases the efficient use of screen space.
Add an "auto-expand" view mode as a variant to "auto-split". Auto-expand would be like Basic-Ledger except for split transactions, which would be output in split mode (all the split transactions, not the "current" transaction as in auto-split). Auto-expand seems much more useful to me than auto-split).
Differentiate between a blank dollar amount for a transaction and a 0 dollar amount. Blank means unknown amount, 0 means 0 amount. Auto download of transactions is very limited in which institutions it works with. A viable alternative is using scheduled transactions for transactions that occur at regular times (interest payments, credit card payments, etc). It would be useful to be able to have transactions in the register that show blank dollar amounts (meaning an amount has not yet been determined) and ones that show a $0 amount (the amount is known but is 0, say a credit card payment that is zero for that month).
Add the capabilty to order/reorder splits.
Have a new way of outputting a split transaction where all but 2 of the splits have blank dollar amounts. The top line of the output would be the transaction as it would be listed if the blank-amount splits were not present. Under that line would be the blank-amount splits, output as in split mode. This creates a versatile mechanism that among other things can be used to implement tags without radically changing the basic infrastructure in Gnucash. Consider a bunch of tag "accounts": TAG:tag1, TAG:tag2, etc. To tag a transaction, add a split with TAG:tag1 as the account and leave the amount blank. When the transaction is displayed, it will show up the same as if it was not tagged except there will additional line(s) for each tag associated with the transaction.
In addition to associating a file or URL with a transaction, add the capability to link two transactions. Each transaction would be associated with the other. (I would make this separate from the file/url association so there could be both but if simplicity demands it, would settle for it to essentially be a third option in the association mechanism.) This would also require a mechanism for deleting the link. This creates an alternative mechanism for creating a tagging effect, but tagging that associates a dollar amount that is different than (or the same as) the transaction dollar amount. (If it does not make sense to have a balancing entry for the amount tagged, that balance amount can always be dumped in to a Trash account for that purpose.) In my case, I like to think of my assets as being "foreground" (for day-to-life) and "background" (reserves for emergency and retirement funds). When I move funds between fore and back, in addition to the actual transaction I like to create a matching transaction such as one between accounts FORE-OUT and BACK-IN. I can do that now by making the transaction a split transaction, but that results less readable split-transactions in the listing. What I really want is two transactions that are linked together.
Items 1-6 relate to register readability and making more efficent use of display space. Items 7-8 build upon existing infratructure to create a general purpose mechanism that among other things would support tagging. Some of the 1-6 are important in making 7-8 more valuable.
Because most of these use existing infrastructure and are in some case just a change in output format, I suspect the package of ideas could be implemented with minimal effort. I have already implemented item 1, it was trivial, see the post
"Notes column in SingleLine display" on the gnucash/nabble board, http://gnucash.1415818.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=377531
Arch Harris
shared this idea
-
AdminJohn Ralls (Developer, GnuCash) commented
1. Turn your code into a PR or attach it to a bug request. Patches on the mailing list tend to get lost. Derek's suggestion that the change could be limited to a single file was I think about personal use. To actually make this a feature I'd prefer that it be a preference item similar to the Action/Number switch, but in this case it would be a regular preference since it's just display.
2. Interesting idea, but your presentation is a bit unclear: You begin with having a color associated with each account, not too hard; then a color associated with each account type, which is a little harder if you mean the types that already exist, like STOCK and BANK and a lot harder if you mean to have user-assignable account types--let's call them groups to distinguish from the hard-coded types--and UI to manage them.
3. Huh? Only the transaction being edited has a blank line and in that case it probably is needed. Removing it won't save much screen real estate and having to use the menu or a shortcut every time one wants to add a split would be pretty annoying.
4. Another interesting idea, but since one can examine a "split transacion" easily enough with a click or two I'm not sure it would be much of an enhancement.
5. Use a variable in your scheduled transaction template and the since-last-run dialog will ask you for an amount to plug in when the transaction fires. A transaction must have an amount in order to post; if you don't know the amount you're not ready to post it.
6. Splits are orderless. The set of splits is a description of a state, not a sequence. Making them ordered in the display would require adding a hidden order field to the schema and code to set the field while the transaction is being edited and to read it when the transaction is displayed in split mode.
7. No, overloading accounts to create tags would be a poor design, a violation of the single-responsibility rule.
8. The main use-case for this would be to link capital gain transactions to their corresponding sell transactions, and the Lots facility does that though not in a way that's visible to the user and there's no way to do the same thing manually. IMO a split transaction is a better way to represent a transfer from a reserve account to a current account and then spend the money. It will already appear as two entries in the current account because of the two splits.