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.

Allow multiple users, in a business to access the database at the same time so that multiple transactions can be entered or updated simultaneously, and do so with remote access capabilites like Terminal Server (Windows) or X-Term sessions (Linux/Unix) .
This is a feature in many commercial programs and this is exactly why many business users of such programs are not using GnuCash.
If GnuCash wants to secure donations from the business community beyond the home or individual operating as a business, this feature will make GnuCash extremely attractive to a market that routinely pays $3,000 to $5,000 for products lke Quickbooks Pro with $850-$1,000 per year support contracts.

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.

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.

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.