WishList

From GnuCash
Revision as of 14:44, 4 June 2006 by Ajkessel (talk | contribs) (→‎Usability WishList)
Jump to: navigation, search

Note: The main place for submitting enhancement requests is the bugzilla database, see Bugzilla. Use this query for a direct list of all currently open GnuCash items.

Projects

Some issues which are either big/important or for which some information has already been gaterhered have their own page:

Other issues which have been mentioned here but should be discussed in Bugzilla are:

Old discussions are archived on OldDiscussions.

Create a context-sensitive help system.

GnuCash can be an intimidating program, at times, in part because it exposes enough complexity from double-entry accounting to be dangerous. One way in which this could be relieved is a conditional-display context-sensitive help system. For first-time users, or on-demand, a sidebar or top-bar containing a short summary of the dialog or window being viewed could come into place. This help-pane should provide a very brief discussion of the goals and terminology used in the dialog, with hyperlinks to more detailed help.

Answer from current developer: This will probably be a lot easier after the Gnome2 port is completed, which will take well into mid-2005. After that, the Gnome2 internal context-sensitive help mechanism can be used for this.

Implement an option that permits to edit a report's preferences 'before' elaborating the report

This will be extremely useful in the cases where a user have many accounts and many transactions: in that case the elaboration of the report could last many minutes, and eventually produce a output that isn't what the user wanted to see.

GnuCash Wishlist

This page is intended as an edited list of enhancement requests for GnuCash. This page needs some heavy editing -- please go a head, sort and regroup items as you think.

Some Wishlist items

Reliability

The very first time that I started using Gnu Cash, after I had spent about an hour and a half entering receipts from my wallet, it crashed (when I tried to access Help, which Fink had not installed). Because I was used to Quicken, I had not expected to have to "Save" my work. At that time I did not know about Gnu Cash's faciility for manually replaying logs, so I swore, considered abandoning Gnu cash to return to Quicken, but reentered the data.

By the next day I had learned about Gnu Cash's logs. I am still surprised that the need to recover by repplaying a log is not automatically detected. It should be.

But even now, a month later, I still get about one Gnu Cash crash a week. Of the two occasions I have attempted to repplay the logs, one time succeeded and the other tiime failed.

I believe that this is a major shortcoming for Gnu Cash.

Quicken has a transactional model: every tiime you hit the ENTER key, what you have entered is stored to disk, probably in a log file. I have never lost data entered into Quicken, even though I have had crashes. Quicken does not even have the concept of "Saving" your work.'

Professor David DeWitt of University of Wisconsin Computer Science, a fairly prominent man in the database community, has said that he believes that this user level transactional behaviour, guaranteeing almost no loss of work, was one of the biggest factors in Quicken's success.

I do not know why users might accept the requirement of "Save" in a word processor, but not in an accounting program. But Quicken has set expectations here.

Improving Gnu Cash's reliability will require ensuring

  • the need to repplay a log after a crash is detected

but, also

  • an intense reliability testing program, inserting errors and ensuring recovery.

I know: this is Open Source. I am about to volunteer.

Easier Setup of Stocks

I like Gnu Cash's use of an arbitrarily nested accounts tree. I like beiing able to set up a separate subaccount for each stock in a brokerage account.

However, it is a bit painful to HAVE to do so... to have to set up a new coommodity for the stock, and then an account corrresponding to it.

Wish: I would like accounts such as brokerage accounts to be able to contain multiple commodity types, i.e. multiple stocks. I would like to be able to have a single transaction that deducts cash and adds a commodity like the stock purchased to the account.

I think it would be perfectly fine if this operated behind the scenes by creating subaccounts. With queries "are you sure?" I basically want to automate the process.

Wouldn't the introduction of a number of druids sort out all (or at least most) issues regarding how to handle/record the various transactions with stocks?
  • Create one druid that will have to use when you create your commodity. This druid should create all the needed accounts for all possible actions (buy, sell, dividend, re-invest dividend, add shares, remove shares, etc) which are used by GnuCash's reports.
  • Create one or more other druids that will take care of the purchasing/selling/dividend etc transactions. Something like Money or Quicken. GnuCash should of course fill in the appropriate accounts in the background when you press apply.
By enforcing this common use of accounts, if would be much easier to create reports I think.
--Bengt 20060405
Implied Stock Price History

When I enter a Buy or Sell transaction, it should be possible for the price recorded to be automatically entered into the price history.

Perhaps only optionally, since occasionally the price in a transaction has no relationship to the fair market value on that day. But at least optionally, since often it does.

Why not just store the stock quote as a buy/sell price. When you update the stock quote at the end of the day, you will get a Last Quote entry. If this is implemented, then when you import QIF files with stock purchase/sell your pricedb should be automatically updated with these prices.
-- Bengt 20060405

Multiple "Commodities" per Account

Many of my suggestions about easier handling of Brokerage and other stock market accounts would be addressed if it were permissible to have more than one commodity type per account.

E.g.multiple stocks, plus cash, in the same portfolio.

As mentioned above, I think it is great to implement this by subaccounts. Just automate and facilitate the handling.

Another situation that might be addressed by this includes keeping track of basis for capital gains reporting. Again, it is possible to do this by creating a separate subaccount for the accoount that holds the stock, but there's a lot of footwoork involved.

    NOTE: I can assure you that this will never happen -- it would be a HUGE architectural change. The Account is a core object that collects a single commodity type. Changing that would be not only a HUGE undertaking but would require changing every tool and report, not to mention changing the UI in non-insignificant ways. So, don't hold your breath for this -- I don't think it will ever happen.

    Instead, I think we just need better tools to help users set up Brokerage accounts, druids to create the appropriate subaccounts and attach them together. Perhaps we can simplify the UI by combining the multiple per-commodity sub-accounts into one view.. But under the covers you can't get away from the 1:1 mapping.

    -warlord 2006-03-01

Multiple Views - not just hierarchical account tree

Gnu Cash's arbitrarily nested account tree is a wonderful improvement over Quicken's accounts and categories. Deep hierarchy capability is better than 2 level hierarchy.

But multiple hieerarchical views is better still.

For example, one typically has several accounts associated with a piece of property, say /Asset/Real-Estate/Property1, /Expense/Real-Estate/Property1, /Liability/Real-Estate/Property1/First-Mortgage, etc.

Sometimes one wants to roll things up by asset/expense/liablity; sometimes one wants to look at /Property1/{Asset,Expense,Liability}; i.e. one often wants to pivot path elements in the tree.

One of the big reasons that I want to use Gnu Cash is the hope that I can code up this sort of flexible viewing of accounts and data.

Another examples: source of account / type of account / company holding account. I have several accounts that are associated with different employers, past and present: e.g. Motorola/401K, Motorola/Pension, Motorola/ESPP, Intel/401K, Intel/SERP, Intel/ESPP, Intel/Options AMD/401K, AMD/ProfitSharing, AMD/ESPP, AMD/Options.

Sometimes I want to see these by company.

At other times I want to see these by type - e.g. 401K/{Motorola,Intel,AMD}, Options/{Intel,AMDD} etc.

Similarly, some of these accounts are managed by various of the big finanicial firms.

E.g. AMD/Options is managed by eTrade OptionsLink. But I also have two other eTrade accounts.

Intel/401K is currently managed by Fidelity, although it has been managed by other companies in the past. But I have Fidelity accounts from several other sources.

Sometims I want to look at all of my Fidelity accounts at the same time

Fidelity/Intel/401K Fidelity/Motorola/Options

but note: it is not meaningful to place the admin in the path, since at any point in time Amd/Options only has eTrade as the admin.

Change Tracking

Accounts get sold from one company to another. Employers change the adminsitrators of retirrement accounts - tooday its Fiddelity, tomorrow eTrade. Even within the same company, account numbers get changed: eTrade renumbered everyone last September.

It would be good if Gnu Cash allowed us to keeep track of such changes. Instead of just a single acccount number, it might allow the account number to be versioned. Similarly contact info.

Mysellf, I like wikis - link too arbitrary text, perhaps with particular fields. Or, the model of old InfoCentral: an account is a relationship between a company like Fidelity and a human. There may be multiple such relationships. Rellationships don't last forever.

Export an API

I would like to see a simple libgnucash, for a programmer's interface to the program. I'm not sure how much work this would really take, but I would find it pretty useful to be able to query an accounts present value, list transactions, enter transactions, et cetera programmatically.

--Jdoverholt 11:31, 3 Dec 2005 (EST)

See:

Minor wishlist items

Account Tree Fields, Reordering

I would like to be able to see the Total value in the reporting currencyy as the leftmost fieldd in the account tree.

Of course, overall a general mechanism to specify field ordering in such displays.

Some wishes after working with GnuCash for a short time:

  • Be able to select more accounts at one time, making it possible to delete many accounts at once.
  • Make the delete key (on the keyboard) work for deleting accounts.
  • Be able to drag-and-drop accounts to another place
  • When accounts are changed in the main window, the accounts in the transaction screen (general ledger?) are not updated.
  • The - (minus) key on the keypad can not be used for entering dates, which is an annoyance.

Sjoerder 07:33, 10 Nov 2005 (EST)

Disclaimers

I (andy@patten-glew.net) am taking the liberty of starting a wishlist for Gnu Cash here. I am, of course, starting off with a personal wish list of features that I have found. I do not expect my personal wishlist to have any weight, unless others have similar requests.

I would not be at all surprised to learn that there is an official place for such feature requests. I have not found such an other place and, since I am a longtime wiki user, I think that it is a good idea to create such wishlists in a wiki, where people can brainstorm on features.

I would not be at all surprised to learn that some of the features I am wishing for are present in Gnu Cash, probably under some name other than what I was looking for. In which case the wish can be considered a bug report against the documentation and help system.

My background: I am not an accountant, although I have taken accounting courses, was married to a CPA, and have picked up a lot of accounting along the way. I am a long-time user of Quicken (>10 years). I only started using Gnu Cash about a month ago, frustrated at Quicken and Microsoft Money's lack of features and programmability. I am using Gnu Cash 1.8.9 on an Apple iBook G4, running OSx. (In case anyone is interested, I bought the iBook largely to run Gnu Cash, having been frustrated by Linux on laptops.)

While I am a long-time wiki user - I started off using the Ward Cunningham's original wiki at http://www.cc2.com as an XP wannabe, have evangelized wikis at both Intel and AMD, and have used moin-moin, zwiki, usemod, and, mostt heavily, twiki - I am new to mediawiki, so apologize for inappropriate formatting. In particular, I have not been able to figure out how to create lists in this wiki yet.

Grace as a charting engine

We have replaced guppi with GOG, but it might still be worthwhile to consider moving to grace, a graph producing utility with a nice GUI. See the gallery for an almost insane multitude of possible graph styles including 3-D. Output to SVG, PNG, PS, PDF

Grace is available only as an external program. Even its available C interface is only a means to drive an external sub-process, see http://plasma-gate.weizmann.ac.il/Grace/doc/UsersGuide.html#ss6.2 . That's pretty much the knockout criterium for gnucash, where we want the graphs to appear as widgets inside of the Gtk windows. Additionally, grace is only X and doesn't match into the Gtk GUI toolkit that gnucash is based on (in terms of data types, callbacks etc). Second knockout criterium. The only useful combination here would be that gnucash offers an export feature which exports only the raw data, so that people who want to view this in their favorite "graph producing utility" (grace, gnuplot, matlab, whatever). But that's a different feature. Sorry, but this WishList item has to be considered WONTFIX. --Cstim 06:18, 2 January 2006 (EST)

Commonly Requested Improvements

End of financial year close issues

The standard way to run a set of books in a business is to enter transactions as they occur, or in batches daily or weekly, and then reconcile those transactions with statements and reports that come a few weeks later. For example, you may keep track of the deposits and withdrawals to a checking account on an event basis, but certain fees and adjustments may be missed until a bookkeeper receives the monthly bank statement, usually well into the next month, and reconciles the statement with the GL account.

Furthermore, many reports are performed after periods end, such as a monthly report on payroll to determine what tax to deposit, a quarterly report on payroll to complete government forms, and a full Income Statement (P&L) after a year has ended. These reports are inaccurate if performed during the period in question; they must necessarily be done afterwards, and often, after the period is reconciled.

This state of affairs requires that you keep your books for past periods open for a while before leaving them. Many accounting programs that limit your open history allow you to have 24 months open - 2 years - and support the ability to close the last calendar year when you are ready.

Imagine running your books - personal or business - to December 31. Now, you face January, and you want to be able to reconcile your statements for various accounts that will arrive in January for December or for October-December (Q4), and you want to be able to run reports on December, Q4, or the whole preceding year, for a little while, perhaps at least until tax day. However, you also want to be able to drop the last year after that, because the data takes up space and processing time, and you need not work with it all the time. You have a choice - you can open a new account and populate starting accounts, which is a nuisance and means you have to update the starting numbers any time you go back and change the old file, or you keep going in the same file and just accrue more and more data. The former is error-prone and the latter is slow.

What is needed is a built-in function of the application that can drop a chosen set of months at the beginning of the data set and summarize the activity into the starting balances for the remaining data so that an obsolete year can be cleanly dropped later on in the next year. This allows the application to support continous operation.

Invoice printing including font choice and Fancy invoice customisation

The Fancy Invoice is mostly customizable, now, as of 1.9.2. At least the contents of the report are obtained from the data as opposed to hard-coded in the report. Ideally we should just integrate something like e-guile and allow users to generate the HTML template with embedded guile.

Connecting with PalmOS
See: Pilot-QOF, list of external software interfaces
Choosing a customer or vendor when doing invoices or payments is clumsy

This also applies to choosing an invoice, and perhaps other things. As it is now, a user has to go to Business->Customers->Find Invoice, fill in search criteria, press the Find button, click an item in the results, and finally click the View/Edit Invoice button.

Why not instead make the path Business->Customers->Open Invoice, and open a dialog with a type-ahead search (similar to choosing accounts in the ledger fields) on the invoice number (or customer name, or vendor name, etc.) by default. A button somewhere in the dialog could open a more comprehensive search function.

Come to think of it, I'm almost always looking for unposted invoices in my books. So maybe a default dropdown list containing only unposted invoices? I guess a good way to summarize this RFE is to make opening a customer, vendor, invoice, etc. for editing a two-click operation -- maybe even a one-click operation if we add dropdowns to the toolbar (should be customizable).

Cheque printing
Quickbooks import capability
Multi-user version
Language

I would maybe like to suggest as a requested feature that the language settings be part of the preferences menu option as a better way of setting the operating language of GnuCash. I would like to invoice clients in both French and English.

Usability WishList

Move close button to tabs

Personally I'd like Edit->Preferences->General->"Show close button on notebook tabs" to be enabled by default, and have that option remove the 'big' Close button. Input from a usability expert is desired.

Closing tab should focus the next tab to the left

Closing tabs in gnucash has unexpected behavior: focus is shifted to the first tab. To be consistent with other tabbed applications (e.g., Mozilla), focus should shift to the tab immediately to the left. The current behavior makes it cumbersome to close a bunch of tabs in a row--you close the tab, and then need to move to the next open tab, then close, repeat, etc..

Retrieved from "https://wiki.gnucash.org/wiki/index.php?title=WishList&oldid=2028"