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.

207 votes
Sign in
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  ·   · 


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • YeOldHinnerkYeOldHinnerk commented  ·   ·  Flag as inappropriate

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

      • SemkySemky commented  ·   ·  Flag as inappropriate

        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 .

      • SemkySemky commented  ·   ·  Flag as inappropriate

        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.

      • YeOldHinnerkYeOldHinnerk commented  ·   ·  Flag as inappropriate

        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.

      • DirkDirk commented  ·   ·  Flag as inappropriate

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

      • 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

        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.

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


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

      ← Previous 1

      Feedback and Knowledge Base