associate jpeg image of reciept with a transaction?

[Josh Sled]

On Wed, 2004-12-08 at 11:20, Ben Pracht wrote:

> given transaction.  I'd also like to be able to associate documents with 
> a whole account.  I can think of two scenarios:

Sure ... certainly there are interesting things to note about accounts
as well ... and especially certain account types ... "what APR am I
getting on this credit card", "when does my promotional rate end",
&c....


> Personally, I'd think that if it could be done, it'd probably be best to 
> put some sort of a link from the XML file to a member in a separate file 
> containing compressed jpgs' or gif's or whatever.

I'd probably opt for either the same file, or for gnucash to manage a
"virtual folder" -- basically, a .tar.gz file which contains the "root"
datafile and individual sub-parts.  At least then there's much less
chance of the user inadvertantly invalidating references that the root
data-file contains to the sub-parts.

But the whole idea of the file backend is going to go away when we move
to the embedded-database backend.  I guess the same question is true
there, but has different tradeoffs.


WRT to formats: JPEGs aren't appropriate, GIFs are okay, PNGs are good,
but I'd seriously consider using the DjVu format [1], which was
expressly created for the compression of scanned documents, and has
open-source libraries available.

[1]: http://www.djvuzone.org/wid/index.html


> paper.  That is, an ID generated by GnuCash, separate from any thing 
> else such as a check number.  That way, I can go back to the actual 
> piece of paper associated with the transaction and figure out what went 

I've thought about the same thing myself ... generally, there's that
whole "document correlation" problem.  I like this, though -- just a
simple user-facing identifier.


> wrong.  There is an ID with every transaction inside the XML file 
> itself, but that's several inches long making it too impractical for me 
> to hand write on every source document.  Also, there seems to be no way 
> of getting that information without looking at the XML file itself.  I'd 
> like to see it in the account register and general journal and also in 
> reports.  I'd like both the scanning of the receipt and the unique ID, 
> but would probably prefer the unique ID first.

The GUID that's in the data file is not appropriate ... it's
/expressely/ there in order to replace inter-object runtime
memory-references, so that GnuCash can re-construct the full object
graph from the linerally-serialized form in the data-file.  There is no
assurance about the stability of those identifiers.

Better as you implied to have an identifier which specifically has a
end-user-facing semantic.


> Since I'll probably never have the time to contribute or do anything 
> other than use GnuCash, I can certainly understand why no one else would 
> want to tackle this, however.

There are definitely higher priorities at the moment, yes.  As well as a
severe drought of developer attention.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`