Image enabling gnucash?

[Christopher Browne]

On Thu, 22 Feb 2001 19:33:32 EST, the world broke into rejoicing as
Bakki Kudva <bakki@navaco.com>  said:
> I am new on this list and gnucash. I do have it on my Red Hat 6.2 box 
> and am very impressed with what I see.
> 
> I am a consultant/integrator in the business document management 
> solutions. One of the major application of 'imaging' is to image enable 
> legacy accounting apps, usually running on some host via some sort of 
> terminal emulator. Using screen scraping  host based accounting apps can 
> be image enabled so that scanned images associated with particular 
> transactions  can be indexed(with additional indexes if necessary), 
> stored, retrieved and displayed. Most of the time these supporting 
> documents are scanned tiff images but could also be any type of file. 
> Most businesses spend a  lot of time handling supporting paper documents 
> and imaging can really improve productivity.

_Very_ interesting option.

Imaging doesn't typically have too much to do with "screen scraping" from
what I've seen.  [For those not familiar with the term, it's usually
referring to the situation where you treat a mainframe "host" as a captive
application.  Your program grabs the fields written to the screen, and
writes data back as needed to control the system.  The typical vendor
for this is AttachMate.  In UnixLand, the comparable thing is to write
Expect scripts.  More recently, in "WindowsLand," the analagous sort
of thing is to capture Win32 events, with the big vendor being Mercury
Interactive...  But I digress...]

I'd certainly be pretty happy to see a whole lot of my paper documents
scan in so that I could basically throw them in boxes and _never_ look
at them again.

A few properties have to be assumed, though:

-> There needs to be a significant amount of "metadata" _TIGHTLY_
   attached to each such document so that it can be readily cross-indexed.
   Preferably that data should be inside the document so that it all
   remains atomic if I copy files from one place to another.

   It is unacceptable if moving a document from one place to another
   makes it "lost" from the system...

-> There needs to be an organized way of collecting the documents
   together so that saving to CD or moving to a new HD is straightforward
   and safe.

-> It needs to be downright _easy_ to attach metadata to documents, including
   dates, descriptions, and arbitrary additional sets of tags that _I_ may
   need to define.

-> There needs to be a database that collects the metadata and allows
   efficient lookups of documents.  "I want all the NationsBank and Bank
   of America statements."

-> There needs to be a way of associating images together.  My credit
   union statement often consists of four pages, for instance.

-> It would be a slick idea to allow a variety of kinds of images.  
   Postscript, TIFF, JPEG, all would be valuable.

-> Note that if Postscript is on the list, that means that I could
   set up a print queue that grabs documents from the web and
   pushes them in. Thus, I could preserve Citibank "electronic bank
   statements" by printing from Netscrape to print queue -Parchive...

It could well be that all this stuff gets tossed into a set of directories
where each file is named based on [say] its MD5 checksum to maximize
uniqueness of names.

> I browsed through the project goals at linas.org but didn't see anything 
> related to image (document) enabling of gnucash. I wanted to get some 
> opinions on this feature. I am a programmer with reasonable skills and 
> would be interested in adding these features if there is interest.

> The only modifications to gnucash would be that register windows have 
> additional buttons called 'scan', 'attach', 'documents'. These buttons 
> would be tied to method calls into the imaging client with index info. 
> Scan and attach commands would invoke a scan program via 'SANE' or allow 
> attachments much like email. Additional index fields could be defined 
> and filled in (vendor id#, account# or whatever) in addition to the 
> automatic fields such as date, transaction id etc. Seperate window would 
> display the images and/or other apps launched based on mime types. Back 
> end could be mysql and the imaging engine can have its own API so that 
> other apps can share the functionality.
> 
> So what do you folks think?!

If you try to make it have anything to do with "screen scraping," a big
punch in the nose is likely mandated.  :-)

But aside from that, there would be _tremendous_ value to connecting in
a sort of "poor man's imaging system."  

Indeed, that is something that is _well_ worthy of its own project in its
own right.  I would suggest that you _not_ make it GnuCash-specific, but
rather try to define some clean interfaces for connecting them together.
As you suggest, a few hooks are all that are needed to make it link
together.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://vip.hyperusa.com/~cbbrowne/finances.html
The Three Laws of Thermodynamics: 
   1) You can't win.
   2) You can't break even.
   3) You can't even get out of the game.