I will donate additionally $70 to the GnuCash-project when the feature in question is being introduced in GnuCash. I really am looking forward to seeing this feature in GnuCash!

I would love to add my two cents to this, This is a NEEDED feature, But rather than trying to create more code for the folks on the front lines of maintaining the codebase by including of the code it would be better to implement this as a plugin. If the plugin is clean enough it will likely get included in some future version anyway.

On implementation:

One object may need to be linked to multiple transactions and multiple objects may need to be linked to a single transation. As such a single stucture while simpler will not provide the needed linkage. Secondly the plugin would need to be able to handle both the dbi interface and the local xml data structure as well as the transition between formats not to mention the export and report funtionality needed for full integration. This is more reason to keep the system seperate from the main trunk until full integration can be achieved.

Timeline and methodology.
Starting with a simple receipt link to transaction system would be good but in the long run what is needed is a comprehensive document manager with a field for tagging the type of object being linked i.e. receit, bill, statement.

While of course the actual developers would have the final say so but it seems to me on fist thinking about this a good way to implement would be to create a tab sidebar in the main window(or popup?) which would list associated transactions and contain the needed funtionality of such a system. The plugin would also need to add a main menu item titled "links" or "receipts" and such for configuration options and other features we would need.

The first step would be to implement this in both the local and DBI backend systems then move on to integrate the plugin with the rest of the system such as reports and export. One would also want such a system to link documents or other files to entire accounts such as bank statements, bills, stock reaserch and other documents. Once we have a working system it would be trivial to add a linked document management system to your finacial data to create full reports in a wholly electronic package using gnucash as the financial heart. This would make reporting on taxes or preparing finacials for banking and loan purposes much easier to prepare with careful usage. If it is too difficult to do all of this as a plugin the a testing fork could be created and developed alongside gnucash until it is accepted by the developement team.

Finally document handling and image display is not always easy. I would suggest not reiventing the wheel and using okular or nautilus being Plugged in to do the file viewing or thumbnailing. I dont know if this is too ambitious but if you are going to do something you might as well plan for the future.

Data structures.

1) store all file meteadata in a three data structures linked to the transaction guid with the following columns

Structure 1 - Link

guid the guid of the linked document.
link the URL
local the file location from the
blob the uploaded file if desired
type a category or tag
mimetype meta information for thumbnail creation and file handling
meta other meta information which may be needed (preferred aplication, originator etc.)
thumbnail a jpeg of the document.
notes

Structure 3 - Transaction or *other link(account, employee, invoice or other

link_guid
transaction_guid
*other_guid

Using a linking table would allow for a less rigid linking system.

I suggest each transaction can link to one or many files. These files would just make it easy to open transaction related information and not required for reports. I also suggest having a preference for the location of your files. File links in the transaction could be relative or absolute URIs.

I do not suggest storing files in the gnucash database. Keep these things separate.
-Mark

I'm all for the BLOB implementation on the DB, although, having both files in dir and db option should be offered as options.
Personally I really like to use the DB back end to do my bidding as opposed to having files laying around, I think inserting the images directly into the database would make things much easier.

I also agree that this would be practical for any kind of transactions: I am one to keep all the receipts I have, it takes quite some space, having it on the computer would make my life less miserable in the long run (no boxes full of useless paper to keep, just hard drives).

Suggestion: The last thing we need is to have gnuCash store the image or pdf file within gnuCash.... not necessary!

The image or pdf file would be already existing in the computer file system, e.g. (I use Windows Vista)

C:\Users\Jcard21\Documents\2011\20110508_1125_Walgreens_Receipt.jpg

The new gnuCash field would only contain the file's location, i.e. the text string, as above.

When the gnuCash field is double-clicked, gnuCash would use the appropriate Windows function to open the file using the Windows-defined default program; with images, it may be Picasa Photo Viewer; with pdfs, it probably is Adobe Reader.

The text-editor I use: TextPad uses this same procedure to open external files, except you put the cursor somewhere in the filename/text string, and press Ctrl+Shift+G.

TextPad requires file::// in front of the image/pdf filename string, and the slashes to be forward slashes, e.g

file://C:/Users/Jcard21/Documents/2011/20110508_1125_Walgreens_Receipt.jpg

Textpad also opens http:// links with Ctrl+Shift+G.

I hope this helps get the ideas going. ;-)

Definitely, the concept should include attaching images to ANY transaction, not just invoices.

Could this be broadened to attach images to any kind of transaction? Example would be a picture of a check attached to the respective transaction.

Is there a way to create two file system storage options? One for XML, where the scanned images are stored in a folder relative to the XML's root directory? The other, where the files are stored in a user-defined directory and that location be listed in the DB?

You think? To me both of these approaches are the same: just consider DB table which will hold BLOBs as file system (actually a subdirectory where images are held). So if XML file is open call to fetch an image will load file <invoice_guid> from BookName-Images directory, if DB is open image will load from "SELECT image FROM images WHERE guid = <invoice_guid>".

Clearly file system is not the best way to keep images as XML file itself may be easily parted with corresponding images and so relevant check is needed: if image cannot be loaded then image GUID in invoice record should be cleared. In case of DB parting of data and images is unlikely but such check still should happen.

In both cases images should be loaded on demand - not the same way as with data where whole DB or XML is loaded on start.

Actually I am more concerned with "how to get images into GnuCash". Under Linux it is extremely simple with sane. I have tried sane under Windows quite some time ago and it was not doing well. But I think it is relatively easy to make GnuCash to be platform independent sane client. Under Windows TWAIN prevails still but in reality I do not see how to get it to GnuCash nicely. So for Windows users it may be an option to get something like Twain2Sane and then configure GnuCash sane client to pickup images from local sane source.

Of course we can have a "pick file" dialog to get pre-scanned image file attached to the invoice but it is quite inconvenient: put paper invoice in the scanner, run program XYZ to scan an image, store image in the temporary location, open GnuCash, open "pick file" dialog, find file, select, click OK, don't forget to delete file from temporary location. Much easier just to have a button which will execute sane scan from pre-selected sane source directly from GnuCash and then stick resulting image into file system or DB. However option to attach image through dialog should exist as well as sometimes invoices do come by email as scanned images.

You described two different approaches for the actual image storage: Either as separate files, referenced through the appropriate file name, or as binary BLOBs directly in an SQL database. Those two approaches will require vastly different implementations. Which of the two approaches would you like to see first?

Fairly easy: generate document GUID and save image alongside with xml file. Obviously images should be copied along for backup. When reading files if no file is found (data integrity problem) then just cleanup associated GUID from xml file. In case of DB blob may be stored directly in DB.

As a pointer to previous discussion: https://bugzilla.gnome.org/show_bug.cgi?id=336843