[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Fri, 29 Jun 2007 16:46:13 +0100 James Fidell <james@xxxxxxxxxxxx> wrote: > Neil Williams wrote: > > > My recommendation is GnuCash (which handles OFX) - starting with a new > > file from the start of this financial year. Maybe go back one year if > > you really want the historical data but be honest, how often do you > > need to look back beyond that? There is no point importing data "just > > because it is there" when the import methods are (frankly) buggy. Bad > > financial data is a LOT worse than no financial data. > > There is the minor problem of the requirement to keep all financial > records for six years. Not necessarily in digital form - in fact if (like me) you end up facing a tax review, digital documents are not likely to be acceptable. I had to photocopy 3 years of bank and credit card statements, surrender the *originals* and get them back when the review was complete. This isn't a minor problem. ;-) > Granted, for many people it just won't ever > be an issue, but for people like me who have a number of different > income sources both corporate and personal, it's way too risky not > to bother. I would recommend that you reconsider - to the best of my knowledge, digital records are next to useless for 'official' (government/tax) purposes. The exception is a digital copy of your submitted tax return because the format of that file is fixed and acknowledged. There is no such acceptance of QIF, Quicken, GnuCash, SAGE or anything else. Government may appear stupid but there are limits. > *If* I assume that the QIF file is correct to start with, Wrong assumption in >80% of cases where there is more than a trivial amount of data, especially involving more than one type of employment/income/business. > is it > feasible to create something gnucash can import without throwing > a load of errors, perhaps by writing some sort of script to do so? Probably not - and no amount of scripting will help you. Even if QIF import doesn't throw errors, there is still no guarantee that the data is financially correct. You'll spend hours correcting the flaws in Quicken and QIF. This isn't the fault of gnucash, it is a problem with QIF. Your data is in a bad format and no amount of scripting will get around the basic limitations of that format. This question is asked again and again on other lists but the result is the same: don't trust data in QIF files. Not even Quicken handles QIF reliably and they have been working on it for probably 15 years. QIF dates back to Windows 3.0 (which is about when I first started using Quicken, IIRC) and it wasn't particularly reliable even then. It's been hacked so many times it simply isn't viable. Face it, James. QIF files are just a case of "Do you feel lucky?". -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpUCQOroS5aW.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