The Gnucash database?

blfs blfs at comcast.net
Tue Jul 27 20:46:00 EDT 2004


----- Original Message -----
From: "Mark H. Wood" <mhwood at ameritech.net>
To: <gnucash-user at gnucash.org>
Sent: Tuesday, July 27, 2004 6:21 AM
Subject: Re: The Gnucash database?


> -----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-----
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user

OK, I have spent some time with Gnucash.  It appears
to me that all transactions are generated from the GL.

If this be true, this is not natural because in the real world
the GL is the last step and not the first.  One thing that
a financial program needs to do is to try to imitate that
which was done by hand for thousands of years.

Before computers, people did not make GL entrys and
then from there make checks invoices etc etc.

This would have been completely unworkable.

If it is completely unworkable by hand it cannot be a
good solution by computer.

I might be completely off base here because I am still
not sure if I understand this program.



More information about the gnucash-user mailing list