D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Gnucash problems :(

 

On Fri, 29 Jun 2007 09:10:17 +0100
James Fidell <james@xxxxxxxxxxxx> wrote:

> We seem to have a few gnucash users on the list, so here goes...
> 
> I have a large-ish qif file that I'm trying to import to initialize
> gnucash (it's about 100MB, from m$money).  When I read in the file
> and accept all the accouts etc. to be created, gnucash then flags
> up a large number of possible duplicate transactions.

(as ex-gnucash upstream developer and someone forking gnucash into
something less like a mini operating system)

Every time I talk about problems importing data into GnuCash people say
"Oh, it *does* do imports, it imports QIF!" and I reply "Actually, QIF
import (in any application other than the one that wrote the original
QIF file) is a hack, a bad hack and a frequently broken hack." :-(

(And, btw, QIF does not support business objects like customers,
invoices and accounts-payable.)

> What I don't understand is why it does this, when there are clearly
> no duplicate transactions in the qif file -- every one I looked at
> exists only once in the qif file.

Umm, then those are not double-entry transactions. Hence gnucash has to
try and make them into double entry which is where the hack falls over.

GnuCash is double entry. That means that if you enter a transaction for
petrol in your "Bank" account for £30 you get:
Debit/Assets:Current_Assets:Bank-£30
Credit-Expense:Motor:Fuel+£30

If you split that transaction (say you bought a paper and some sweets
in the petrol station), you might have:
Debit/Assets:Current_Assets:Bank-£38
Credit-Expense:Motor:Fuel+£30
Credit-Expense:Food+£8

However you do it, every debit has a credit and every credit has a
debit - that is double entry. Money doesn't grow on trees, you can't
just magic money out of thin air. You also shouldn't expect a financial
program to make your money disappear into thin air! (Most of us can do
that without any help!) Money - in a half-decent financial program - is
a bit like energy, it cannot be created or destroyed, it is just
re-assigned. Quicken categories and other programs that do not use
double-entry break this model. When those programs export QIF,
recreating the double entry tends to break things.

When you spend money, you increase your expenditure so an Expense
account gets increased (credited) when you buy something and
decreased (debited) when you get a refund.

When you receive income (salary etc.), you credit Assets/foo/Bank and
debit Income/foo.

My guess is that MSMoney is doing the usual trick of interpreting the
QIF format to suit it's own ends and GnuCash is failing because QIF is
actually a 99.9% useless format that has no decent error checking.
:-(

It will take longer to fix the data imported from QIF than to recreate
the transactions in a new file in GnuCash. Mainly because some of the
errors will be VERY hard to find.

Expecting any QIF file over 40kb in size to be anything more useful
than a backup for the program that wrote it is just a tad ambitious. Do
ya feel lucky?
;-)

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpCxgNV4H3Nq.pgp
Description: PGP signature

-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html