Ability to upload or take picture of evidences (receipts, invoices, etc) to desktop or mobile version.

This would be great and seems to apply equally to expense vouchers!

Well from a coding perspective it's simple: add a single entry to each transaction, vendor and customer called "documentID" or - even better - "documentID_list" (python-esque).

As all Bills, Credits, Invoices etc happen within a transaction, they can be automatically attached by key. As you display an invoice, you have access to all related customer, vendor and transaction documents through a simple relationship-key lookup. In reverse, for any vendor you can call up all related documents through a fast lookup. If properly indexed, this should add milliseconds to the queries and provide huge benefit.

With a fairly minimal coding effort you now can have attachments everywhere.

The "copy files" thing has its own discussion at https://gnucash.uservoice.com/forums/101223-feature-request/suggestions/8854033-copy-file-attachment-to-permanent-gnucash-locatio – I'd say that's a separate discussion from whether images can go to invoices as well as regular transactions.

While reopened: Would it not be possible and sensible to also allow attachment of documents to accounts?

Found it,, When entering a transaction in Description, ( right click and the menu - Associate file / or Associate location with transaction )o or Alt-N (Transaction) 'a' will go to save menu.
(there is no indication I have a file associated )
Please add this to 'contents' .
And Maybe display '@r' color blue in description to indicate presence of a ref_doc .

I wish I could find this, been looking all over 2.6.6 but can not find how to link to a reference document for a transaction, right now I am using in description "ref bb0034534" which is a pdf file in directory BigBook, also use pdf995 to create these files. Nowdays we just download the pdf file. still have to index the directory contents, ,, (search within) but still looking for a way to link, the pdf in either description or as a separate column.

Only if you can get it out of Quicken as a separate image file. Gnucash stores only the file path.

Is there any way to import attached files/receipts from a Quicken QIF file?

This should indeed be possible with any transaction.
I don't quite understand the question "Where will those images be saved?". The are already saved. The user links it, and the image remains where it was before. So make sure you move your image to the proper space first.

There should also be some cleaning feature "Remove broken links from all transactions" - I guess the functionality is selfexplaining.

I am about to start using GnuCash for my personal finances. After installing and some testing, I realised that GnuCash comes very close to my requirements. The only thing I am missing is the here discussed addition of scanned documents. For me, this is an absolute mandatory requirement. Realising that this discussion is now going on for many years without any progress in terms of implementation in GnuCash, I won't continue using it. I might reconsider if this feature is available at a later stage, but for now, unfortunately this otherwise very good application is not for me...

Any news on this idea? It is still a great idea to implement..

Is there any movement on this issue? If not, perhaps we can start a crowdfunding campaign?

There is a bounty available for implementing this feature.
http://wiki.gnucash.org/wiki/Bounty_Program#Uservoice

Please.
Preferably *not* internet capable. eg. file:/// only.
IMO this would be a better way to implement the popular wish to be able to embed scan images into GNUCash.

I'd like a similar ability but differently implemented - the ability to add a hyperlink to a transaction record that links to a pdf containing a scan or scans of a paper record.
I currently do that eg. Expenses/Insurance/$date/Description includes a file path to the PDF with the scans of the insurance policy documents.
But it would be *so* much better if the link actually worked.

Extra points if I could link in both directions ie. put a link in PDF that opened GNUCash and displayed the relevant transaction entry.

in the xml file?

It would really really be great to have that feature...

The discussion here is very nice. However, we are mixing up several different areas of requirements on this feature, and also the forum here isn't really helpful in structuring the various requirements into a useful work plan to implement this. As this feature project can nicely be divided into several sub-projects, I propose to continue the technical discussion on http://www.fossfactory.org where people can also commit to put bounties on those aspects that are most important to them.

This would be an awesome feature to have. I definitely echo the need for it to apply to all transactions, not just invoices.

My own personal suggestions/requirements for v1.0 of the feature:
+ Both File and DB back end should probably be allowed, but File based option should be first priority. DB support could come later.
+ Making a copy of the file(s) is a must. Don't link to existing copies as this can break way too easily (sorry, jcard). In file based approach, hard links would be a nice compromise, but aren't supported by all file systems.
+ Attachments should be file type agnostic. it shouldn't matter if it is PDF, TXT, JPG, DOC, etc.
+ User can click a button/link which will open the file in its default application. For example, a PDF would open in Adobe Acrobat and JPG in Eye of Gnome or Windows Photo Viewer, etc.
+ User must be able to delete attachments.
+ File size limitation. ... For file-based back end it doesn't matter much but for DB file size will be a big issue. This is another argument for deferring DB support IMO. For DB it is definitely necessary but what should the limit be? Maybe there should be a config setting for this, or for DB use a preset limit and specify in the documentation and for file-based do not enforce a limit? Thoughts?
+ One attachment allowed per transaction. Multiple attachments would be nice, but are not necessary for v1.0 (see below).
+ Very basic metadata support. At least a Filename and possibly Title. "Category" is probably not necessary since it will be attached to a transaction which itself must be balanced with an income/expense TXN which then gives you its category.
+ Unique ID/File Name for attachments. For file-based system, files must be given a unique name so that there is not a naming conflict. So when attaching a file, the file should be assigned a UID which should then be used for the file name, rather than using the original, actual file name. The original file name could be stored as metadata associated with the file, along with other file information in the database. This will also improve portability as it will prevent users from entering characters in the file name which are not allowed in other operating systems.
+ Keep it simple! Don't add extra features if they will defer release of the initial attachment feature.

Suggestions which should be made into separate feature requests and/or implemented after the initial simple file attachments are completed:

1. Attach multiple files to a single transaction. - This would be first on my list of things to add after the above, but I wouldn't want it to prevent the file attachment feature from being implemented in general. I would suggest this should be done for version 2 of the attachment feature. To work around the limitation, users could make a ZIP attachment if they want to attach multiple files to a single TXN.

2. @Vladimir - Scanning integration would be very nice, but IMO should be a separate feature request after initial file attachment support is implemented. Scanning in another application is an extra step, but it is better than not having transaction attachments at all!

Questionable items:

@Peter - Thumbnail support - Not necessary for initial implementation. Also, what is the purpose of generating thumbnails? If there is no actual intention of displaying them inside gnucash then they only take up precious CPU and hard disk space. I don't know about anyone else, but a thumbnail of a receipt or other text document is generally a waste as you can't read anything and must open the full-resolution file anyways. IMO this would be a waste of development effort which could be used for more important fixes and feature enhancements.