Importing Revisited

[Neil Williams]

On Monday 02 August 2004 3:35, you wrote:
> OK, the code is apparently well documented and certainly some work went
> into this.
>
> There is one point I am absolutely certain about.  Any
> program named Gnucash should be able to communicate
> with a spreadsheet program.

You might be certain about that, but there is no good reason for it to be an 
absolute rule. Quicken cannot inter-operate with a spreadsheet (and in any 
case, which one?), neither can TasBooks. Quicken can export in QIF and you 
could write a spreadsheet that could process QIF but you'd be a fool to use 
that data back in Quicken. Therefore the same goes for GnuCash. It can export 
and import QIF. GnuCash and Quicken are about TRUST. I MUST be able to trust 
the calculations in GnuCash AND know that the Inland Revenue will also trust 
the calculations, they can even download the same program and reproduce the 
results. You simply cannot do that with a spreadsheet - the Inland Revenue 
are simply not going to trust your spreadsheet data because it is too easy to 
alter the formulae.

> So the question becomes why is it so hard to import
> and export a check register?  Are there similar problems

Stop thinking of a cheque and think of an account at a bank. That is what is 
represented by a GnuChas account. It can do a lot more than just cheques.

> with importing and exporting Customer lists, vendor
> lists, bills and invoices, etc, etc?

Importing invoices is more awkward and is currently consuming a large amount 
of my time. It is NOT simple or straightforward.
See www.codehelp.co.uk/code/

> I don't claim to be an expert, but I have a pretty good
> understanding of programming and accounting. 

Do you?

> I also 
> have a good understanding of what is important in a
> business environment as relates to an accounting program.

So do I. I'm a self-employed businessman and have had numerous reasons to 
thank GnuCash and Quicken for the reliability of the programs. I would never 
even consider using a spreadsheet for such vital information and data.

If you were to calculate your tax return figures solely in a spreadsheet, your 
data would be labelled as unreliable and you would be deemed incompetent by 
the UK Inland Revenue. A Tax Review is an extremely long and unpleasant 
burden that I would not wish on my most loathsome enemy.

So from my experience of personal and retail business accounting, going back 
over some 15years in the UK, covering one-man, small group and multinational 
accounting principles, I can humbly suggest that your understanding of the 
important elements of business accounting is legally flawed if you honestly 
believe that a spreadsheet is of any value in the preparation of an 
authoritative statement of accounts, at least in the UK.

If you were to continue with this practice and submit such accounts to a UK 
government inspection, you would have my pity but no sympathy because you 
would be a clear and unmitigated fool.

Is that clear enough?

> The most important document is the check.  And
> the check is a very simple document.

Rubbish. The transaction is complex, always has been complex and always will 
be complex.

> Also you can have a balanced GL that is completely
> meaningless.  Not only is this possible but it is
> extremely easy to have a meaningless balanced GL.

User error does not mean a program fault.

> If there is a problem, the first step is to make sure the
> data in the computer matches the data in real life.

Duh! That's why you enter the data and reconcile it with a statement. 
Reconciling MUST be done manually - it's a vital step in the audit trail of 
the accounts. As such, it is best done WITHIN GnuCash, as it has always been.

> This is why it is so important to be able to extract
> data from the accounting program and import it into
> a program like gnumeric.

Absolute tosh. It's a reason to KEEP the data within GnuCash!  You can only 
reliably reconcile the data INSIDE GnuCash/Quicken.

This is all about reproducible calculations, evidence of fraud and avoiding 
the costly accusation of tax evasion. Believe me, you do NOT want to give the 
taxman any reason to think you are not being careful and open in your 
calculations!

> The user must be able to look 
> at the check data just as the cancelled checks are returned from the bank.

In GnuCash, not gnumeric.

> And further the user must be
> able to conduct queries on this data.

Reports are available in GnuCash. If you want others, write them.

> It is important that the data in the computer matches
> the real life documents in such a manner that the user
> can easily understand.

Which is what the reconcile column has always done.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20040802/f882d89e/attachment.bin