The Gnucash database?

[Mark H. Wood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 25 Jul 2004, Linas Vepstas wrote:
> On Sun, Jul 25, 2004 at 04:08:21PM -0500, Mark H. Wood was heard to remark:
> > On Sat, 24 Jul 2004, Linas Vepstas wrote:
> > > "I have this report, I want to import it into gnucash. Why is
> > > gnucash so stupid that it can't do this?"
> >
> > I'm sorry I discarded the original posting.  This is, in my recollection,
> > the first I have heard that the input was to be a report.  I will admit to
> > an assumption:  I read "flat file" and thought he had files like these:
>
> ...
>
> "same difference".  Its a report with commas in it, and bad indentation.
>
> > which is a set of flat CSV files containing everything needed to express
> > three transactions.  Is it not?
>
> well, besides the fact that its unclear what is in which column,

That's why the files have headers.  The CSV input filters I've seen will
(optionally) read the first line as a header, try to match the column
titles to the program's own, and put up a mapping table for the user's
adjustment and approval.

> -- the currency is missing.

True.  Another column.

> -- the transactions were unbalanced. Sure "expenses:gas", but what
>    account was this drawn on? bank? credit card? cash?

Look again.  Draw from assets:checking; pay to expense:auto:fuel.  I made
the document number "card" to indicate the use of a debit-card rather than
a check.

> > I don't see why it is *impossible* to load CSV data into Gnucash.
>
> Its not impossible, its just that one needs to write a GUI to
> describe the data format to gnucash; how to map the various columns
> of this flat file to thier gnucash equivalents.

It seems that we agree, more or less.  Of course the user must supply a
mapping from one application's terms to the other.  It doesn't have to be
done GUI-style, though; it could be supplied in (drum roll) another file.

Some people seemed to be saying that it can't be done *at all*.  That's
absurd.  Files like the example I gave (with fixed column boundaries
instead of the commas) are the way mechanical bookkeeping was done in its
early days.  Financial records couldn't be kept in an RDBMS if they can't
be represented as tables.

> What is (more-or-less) impossible is to do this automatically.
> I suppose one could apply all sorts of heuristics to guess which
> column applies to which gnucash concept, but without an immense amount
> of work, putting together the heuristics so that they did "the right
> thing" 99% of the time would be a huge effort.  If it was easy, we
> wouldn't need XML :)

I agree that it would be less work, and less error-prone, to ask the user
to participate in the mapping.  I wouldn't trust mechanical guesswork
until I'd checked the results very carefully.

> > ... the accounting problem ...
>
> The absence of any sort of programming standards for accounting.
> For example, 3D graphics has the OpenGL programming API, which
> is spec'ed standardized, and overseen by commitee.  Accounting
> has nothing like this.

A common standard for exchange of financial data would be useful.  I don't
see how RDBMSs have anything to do with that, though.

With respect to accounting and bookkeeping, an RDBMS improves upon paper
records by making it easy to view the same heap of records in many
different ways.  One of the problems with paper is that, once you've
written, that's that.  Rearranging and filtering are possible on paper
only by copying.  Stuff the data into a database, though, and you can ask
for subsets, sorted and grouped to order, without the problems inherent in
the maintenance of duplicated data.

This doesn't help a lot with exchange, though.  The common language for
accounting metadata is still missing.  At most one can achieve, not a
universal exchange, but a bunch of bilateral agreements about exchange.

The various EDI standards have nibbled at this problem, although
accounting is not the only thing they're aimed at.

- -- 
Mark H. Wood, radical centrist     OpenPGP ID 876A8B75     mhwood at ameritech.net
No amount of clipart will save dull writing or an uninteresting topic.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFBBjrbeziYCIdqi3URAoUkAJwLq942pB1ZKRXhONEEM0TRon++RwCdFLlq
29gKZZ765amjHbHU6QYkZoU=
=07ls
-----END PGP SIGNATURE-----