Corresponding Bugzilla item: https://bugzilla.gnome.org/show_bug.cgi?id=509267

Where's ctrl-z when you need it? There's several aspects to this. Naive undo would include being able to remove some typing or a paste operation you did to a field that you didn't intend. Sophisticated undo would let you reverse a transaction that you messed up without having to hunt for what account it's in now. Even more sophisticated might be multiple levels of both Undo and Redo, and a hint in the menu next to each about what would happen if you chose that option.

This is another simple time-saver that's probably been mentioned elsewhere but may be worth listing here for tracking purposes.

Corresponding Bugzilla item: https://bugzilla.gnome.org/show_bug.cgi?id=657215

As I recall reading on the GnuCash mailing list(s), developers will not include support for currencies that do not meet ISO requirements. Therefore, to use the likes of Ithaca hours or bitcoins, users have to rather inappropriately treat them as stocks, virtually exchanging them for an official currency before conducting real transactions. Either that or users must rely on the XXX placeholder currency, which has its own limitations.

I propose that GnuCash include some functionality for users to define custom currencies that behave just like regular official ones. This functionality would allow for users to point GnuCash to where it can find exchange rates with other currencies or to manually specify them. It would also allow for users to peg the value of their custom currencies to officially recognized ones.

I hope the developers will consider my suggestion.

Corresponding bugzilla item: https://bugzilla.gnome.org/show_bug.cgi?id=545160

I'd like to suggest using type ahead search when specifying which account
should be used in a transaction.

Just to give an example i have the following expenses accounts:

Expenses:Auto:Repair
Expenses:Auto:Gas
Expenses:Boat:Repair
Expenses:Boat:Gas

I would like to type "rep" and have Gnucash suggest all matching accounts. In
this case:
Expenses:Auto:Repair
Expenses:Boat:Repair

If I start typing "a" it should show
Expenses:Auto:Repair
Expenses:Auto:Gas

In short it should work like the label selection widget on Gmail.

I have a pretty deep expenses structure (matching different budgets I have set
up) which makes typing all the different levels tedious even if I can
":"-complete.

Corresponding bugzilla item: https://bugzilla.gnome.org/show_bug.cgi?id=700804

It would be really helpful if GnuCash had the facility to move transactions before or after a particular transaction of the same day, i.e. to change the ordering manually by some buttons or similar. If time could be mentioned in seconds then we could do that to rearrange the transactions.
But easier would be to have Up and Down arrows to rearrange transactions by just selecting on the arrow and clicking on up or down.
If the moved transaction reaches the beginning or end of the set of the same day's transactions, the transaction date of that transaction could be incremented or decremented OR could stop right there OR could cycle from the bottom top or top bottom depending on which arrow button you were clicking on to move the transaction.

I hope I was able to explain my point.

Thanks for your consideration

One problem with Gnucash is that a user may accidentally change a transaction in a previous month or year. For example, it is possible to delete a transaction that should not be deleted. Also, if a user enters the wrong date in a new transaction (e.g. when typing the date, the year is wrongly entered) the transaction will enter the register in a previous period, but the user may not know where it went. Thus the accounts could be in error due to an accidentally deleted transaction or incorrectly entered transaction.

In my experience training people to use Gnucash in the non-profit sector this has frequently happened.

SUGGESTED SOLUTION:
Add a feature where the entries in a month may be locked and password protected. Thus, after the data-entry clerk enters all the transactions for a month into Gnucash, the finance manager locks all the transactions with a password unknown to the data-entry clerk.

The lock would not prevent reports from being generated or data from being viewed, it would only prevent data from being changed in the locked period.

If subsequently, transactions in a previous month need to changed, the finance manager's password will be needed to unlock that month.

Such a lock could prevent both accidental changes to the accounts in a previous period and intentional attempts to manipulate the accounts to the data entry clerk's personal advantage.

Gnucash needs a robust cashflow forecast with graph, where one can select which accounts and show future cashflow for 30, 90, 180 and 360 days based on scheduled transactions (both credits and debits) that have not yet been entered. e.g. my pay comes every 2 weeks, I get some extra income in June and August that I can estimate, and I have some bills that are every month, others twice a year... I need to know when things will "pile up" requiring a transfer from higher yielding savings accounts into checking. Microsoft Money had a great forecast with a graph so one could identify to the day when balances would run low and plan ahead for transferring money from other accounts. The wiki wishlist for GnuCash has a very detailed explanation of how cash flow forecasting could work, also suggesting the ability to create estimated cashflow from past transactions (which Money could do), but for my part a starting place would be known scheduled transactions that haven't yet been entered. Being able to modify single occurrences of scheduled transactions would also be great without having to edit the entire series (e.g. most months my utility bills are X but I know the electricity bill is higher in the 3 months of summer so).

The current version of GnuCash doesn't have a paradigm for Credit notes.

For clarity: with a credit note, I mean the opposite of an invoice, or a
"negative" invoice, depending on the view you prefer.

This report is created as a follow-up to the mailing list thread called "GDA:
status", although most of this thread deals with GDA and not Credit notes. The
relevant part of this thread starts May, 27th 2008.

According to Derek, it's not possible to simply remove the negative totals
error check. The internal logic relies on value+accounttype to determine
whether a transaction is an invoice or a payment.

Reworking the internal logic would be the first step to solve the CN issue.
Once the internal logic no longer depends on value+accounttype, the restriction
could be removed and a basic form of credit notes are possible.

In the longer run there would be some "nice to have's" of course:
* separate and combined reporting in invoices and credit notes
* different wordings on printed invoices and credit notes (required by Belgian
law by the way: invoices need to state clearly: Invoice, while credit notes
need to state: Credit note)

Finally more obvious GUI hints to the creation of credit notes would be helpful
as well. I am thinking of
* the business menus would have to mention Bill/CN and Invoice/CN, or broaden
the term to "Sales documents" and "Purchase documents"... I know these aren't
very nice for menus, but they just serve as suggestions. Someone else may think
of better words.
* Inside the "New invoice/bill" dialog (which may also have to be renamed), an
option could be added to specify whether the new document will be an invoice or
a credit note.
* The dialog in which the actual invoice/CN transactions are entered could then
continue to use positive values at all times. The internal logic can determine
the real sense of the final transaction based on A/P vs A/R together with the
document being invoice or CN
* A slight variation on the last suggestion is that even an invoice or a CN can
be positive or negative. The sense of the final transaction then simply depends
on three parameters: AP vs AR, invoice vs CN and sign of document total. Note
that although a negative invoice and a positive credit note have the same
mathematical effect, but Belgian law doesn't consider them the same (although I
personally consider this pure nitpicking).

* Instead of renaming the current menu items, it is also possible to add
another (set of) menu items specifically for CN's (New CN, Search CN,...). This
would eliminate the need for additions to the two dialogs that follow (some
name mangling not considered here).

Final note: until this would be implemented, Derek suggests a (somewhat awkward
but working) work around:
A Process Payment gives you that "Negative" number. What you would
do is Process Payment to, say, your checking account. Then after
the transaction gets posted you can go in and change it from Checking
to Income. Make sure you only change the account, not the AMOUNT.
Changing the amount will throw off all the numbers.