I suggest you ...

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.

189 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    RedRaider74RedRaider74 shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Scott FergusonScott Ferguson shared a merged idea: Add the ability to link to a transaction, or display a specific transaction with a command  ·   · 
    JoãoJoão shared a merged idea: Ability to attach files  ·   · 
    Paolo ConrottoPaolo Conrotto shared a merged idea: hyperlink  ·   · 
    under review  ·  cstimAdmincstim (Core Developer, GnuCash) responded  · 

    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?

    22 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • JamesJames commented  ·   ·  Flag as inappropriate

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

      • Scott FergusonScott Ferguson commented  ·   ·  Flag as inappropriate

        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.

      • Scott FergusonScott Ferguson commented  ·   ·  Flag as inappropriate

        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.

      • cstimAdmincstim (Core Developer, GnuCash) commented  ·   ·  Flag as inappropriate

        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 MTim M commented  ·   ·  Flag as inappropriate

        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.

      • Vilhelm MobergVilhelm Moberg commented  ·   ·  Flag as inappropriate

        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!

      • PeterPeter commented  ·   ·  Flag as inappropriate

        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.

      • Mark SMark S commented  ·   ·  Flag as inappropriate

        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

      • Jamil Ben AlluchJamil Ben Alluch commented  ·   ·  Flag as inappropriate

        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).

      • jcard21jcard21 commented  ·   ·  Flag as inappropriate

        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. ;-)

      • Frank SchroeterFrank Schroeter commented  ·   ·  Flag as inappropriate

        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 BarronMatthew Barron commented  ·   ·  Flag as inappropriate

        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 BashkirtsevVladimir Bashkirtsev commented  ·   ·  Flag as inappropriate

        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.

      • cstimAdmincstim (Core Developer, GnuCash) commented  ·   ·  Flag as inappropriate

        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 BashkirtsevVladimir Bashkirtsev commented  ·   ·  Flag as inappropriate

        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.

      ← Previous 1

      Feedback and Knowledge Base