Re: Importing and exporting revisited

[Perry Smith]

Quickbooks is not a real accounting system.  Neither is Quicken.  As 
far as serious programmers and accountants working on them, Quickbooks 
and Quicken have seen neither.  They are marketing programs.  Very 
successful.  But few serious book keepers recommend Quickbooks to their 
clients.   And from the user interface and the problems that crop up, 
you can tell that the internal designs are badly flawed.

The book keepers I've talked to all have horror stories of data 
corruption and lots of other problems.  CPA's put up with Quickbooks 
because they seldom deal with the day to day horrors.  They want the 
business of the customers already using Quickbooks.  Why not?  But as 
far as recommending Quickbooks for start ups, I've never had one of 
them suggest "Hey, just use Quickbooks".  I use it because the 
marketing got to me before they did.  And I can not easily switch 
because, guess what, I can't export transactions from Quickbooks in any 
form that any other program (including Quickbooks) can import (yet).  I 
can export transactions from Quicken using QIF but, if you do a bit of 
research, QIF is too primitive to adequately describe transactions.  
Quicken 5 plans to abandon QIF completely.

Perhaps you are suggesting that GnuCash should change directions and 
become more market driven.  But, just like Unix which was never market 
driven, eventually the tide will turn.  And if it doesn't thats fine 
too.  At least GnuCash will be useful.  I remember system managers 
telling me that Unix will never become popular because there was no 
concept of an operator and no way to request an operator to load and 
unload tapes.  How can you do useful work on a computer without loading 
tapes?

On Aug 2, 2004, at 9:59 PM, blfs wrote:
----- Original Message -----
From: "Benoit Gr�goire" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 02, 2004 8:45 AM
Subject: Re: Importing and exporting revisited

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 01 August 2004 10:35 pm, blfs wrote:
So the question becomes why is it so hard to import
and export a check register? Are there similar problems
with importing and exporting Customer lists, vendor
lists, bills and invoices, etc, etc?
No offense, but this has been explained to you over and over from many
different angles.  Let me try to summarise so we can finally stop this
thread
or get something constructive out of it.
Exporting data in tabular format is inherently trivial, and is usually
done
for reporting purposes.  Few have been implemented in GnuCash (TXF 
export
is
an exception) because most people feel the current reports are 
adequate
for
most purposes.  Those who don't and want to export something really 
custom
have usually done it by running an XSLT transform on the XML file.  It
isn't
durable, but it certainly is simple.
On the other hand, importing tabular data is inherently hard and 
involves
solving several problems.

1-You need a generic, robust and flexible CSV parser.  We couldn't 
find a
ready made one in C, but someone has contributed one.  You also need a
small
interface to tell it the separator, quoting caracter and if the first 
row
must be treated as column names.

2-You need a column matcher to map column name (or number) to their
gnucash
semantic type (amount, value, commodity, currency, reconciled state,
customer
name, account id, split memo, tax rate, etc, etc, etc.).  Since there 
are
several dozens of those (way too much for the casual user to find it 
easy
to
select from a list), you probably need to do it in two steps.  First 
you
pick
an import profile that represents the type of data you wisht to import
(Bank
statement, customer list, check register, stock value report, etc).  
After
that your are presented with a list of relevent data type to match 
against
the columns.

3-Unfortunately, you'd have to run this process every single time you
import a
file.  So you also need a file profile manager.  This will store the 
data
types/column name or number match above in a file as well as some 
metadata
so
the format can be usefull to others (general file format category,
finincial
institution or software, packager, application notes, etc.).  You 
will off
course need a GUI to look at all such file in some directory and 
present
the
metadata to the user so he can pick it instead of running the previous
step.
4-Now you have the data nto gnucash, but that is still not enough.  
Now
you
need several GUIs to fill in missing data.  Some of them exist in 
Gnucash
(the generic transaction matcher, the account matcher, the commodity
matcher), more would have to be written (customer matching, invoice
matching,
etc.).
5-You also need helper support for such things as date formats, number
formats.
None of this is rocket science, but most of it is very long as it 
involves
many, many pieces of user interface. Lots of people want to see it 
happen,
but so far we had few contributors for the import/export process.  
It's a
pet
project of mine, but I have no time to spend on it right now.
Now if you can't see why this is a LOT of code to write, you either:
- -Don't understand the implementation challenges of real commodity 
and
currency
support and double entry accounting like gnucash does.
or
- -Underestimate the time required for the GUI part of all this.
or
- -Like many people assume that since you know and understand the 
meaning
of
your file, a computer can as easely infer the meaning of the 
differents
columns, date formats, currency labels, etc.

The gnucash developers are not interested in solving a problem for a
single
individual (barring financial contribution...), however the ARE 
interested
in
solving problems for a group of users (or solving problem for 
themselves),
when time permits.

Thank you for your reply.  First of all, I have imported data into 
more than
one financial program without great difficulty.  In each case these 
were
financial programs built on top of SQL databases.

I have also imported data
into Peachtree which is a canned program, and I am
sure the developers at Peachtree had to do all the work
you mention to allow imports.
So the issue is not the importing and exporting of data in general 
into a
financial database program but the issue is importing and exporting 
into
GNUcash or canned
financial programs in general.

I dont think GNUcash can make it is a canned program like Quicken, 
Peachtree
and Quickbooks.  They rely on selling product and they can pay people 
to
make certain all these features are there.  Of course no one has time 
for
working on a free program that they dont depend on.
The design of this program needs to be rethunk to get
some serious people working on it or it aint going nowhere.  And there 
are
plenty of serious people out there that know programming and 
accounting and
accounting programs.

It seems to me that the best approach would be to
aim for some database type program, and then build
the financial program on top of it.  This would work
towards solving Linux's lack of a desktop database
program.  A financial program would be the natural
vehicle for developing a desktop database program.
I also want to add that I have been using Woody's
version of gnucash, which does install quite nicely.
Is this version missing functionality?

_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel