Add the ability to attached scanned images to invoices.
Corresponding bugzilla item: https://bugzilla.gnome.org/show_bug.cgi?id=336843
Gnucash could kick off new process to display image based on type (gif, jpeg, pdf, etc) maybe. Similar function is present in Quicken.
Be able to use a link or a command in a PDF or other document containing a scan of paper receipt/invoice etc that opens GNUCash and displays the associated transaction.
When couple with my wished for hyperlink from the Transaction Description field it would allow linking scans of paper records with GNUCash
I think it would be usefull the ability to attach (external) documents to transactions, or to account informations.
A field where insert the path to a pdf document. Ex. Invoices etc
This idea has been around for quite some time, but it requires further thinking on how this can actually be implemented. For example, where will those images be saved?
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.
Scott Ferguson commented
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.
Scott Ferguson commented
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?
Antonio Muchaxo commented
It would really really be great to have that feature...
Admincstim (Core Developer, GnuCash) commented
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.
Tim M commented
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!
@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.
Vilhelm Moberg commented
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.
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.
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.
Structure 3 - Transaction or *other link(account, employee, invoice or other
Using a linking table would allow for a less rigid linking system.
Mark S commented
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.
Jamil Ben Alluch commented
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)
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
Textpad also opens http:// links with Ctrl+Shift+G.
I hope this helps get the ideas going. ;-)
Jorg Bliesener commented
Definitely, the concept should include attaching images to ANY transaction, not just invoices.
Frank Schroeter commented
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.
Matthew Barron commented
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?
Vladimir Bashkirtsev commented
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.
Admincstim (Core Developer, GnuCash) commented
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?
Vladimir Bashkirtsev commented
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.