associate jpeg image of reciept with a transaction?
Josh Sled
jsled at asynchronous.org
Wed Dec 8 18:36:38 EST 2004
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}`
More information about the gnucash-user
mailing list