|Censorship, Freedom of Speech, Privacy|
Please join the Electronic Frontier Foundation ( EFF.org ) and the fight for your rights on the Internet.
I have not received any National Security Letter.
|HOME||Software||Lotus Cars||DWARF||Kindle||eeepc||PALM||RPM Building|
We've long done our personal checkbook(s) on Quicken on Mac, but I thought that, soon, we were not going to be able to user our ancient Quicken2007 on latest MacOS. We've been lucky that the old version has been working over several machine upgrades. And indeed our latest Mac seemed to refuse to run Quicken2007. Well, it had to happen someday.
Having heard rumors that more modern Quicken had no real data-export capability we decided to investigate open source applications. Since I use Linux (exclusively) I looked into several accounting/checking applications. While I use Linux I wanted to use a package that would run on any of Linux/Mac/Windows.
Note that we have not allowed Quicken to go direct to bank or credit card accounts for years. Letting Quicken do that made us very uneasy. As a result we lose no features that matter when switching to open source.
The first step had to be exporting our data to a text file so other packages could import the data. Quicken allowed export to a QIF format. We immediately found that NO package could import the large data file. It turns out that Quicken2007 emitted a little bit of the QIF output incorrectly. And then it became clear that the QIF had a few places with UTF-8 characters. I wrote some C code to fix those places in the QIF. Ugly code and quite specific to our data file.
Then I discovered that most of the open-source applications would still not accept the QIF input. They tried, but got errors. And some of them were seemingly working but still not done after hours. The only application that would both accept the data and accept it quickly was GnuCash!
One of the surprises in the QIF data was how many instances of really bogus transaction descriptions we found (perhaps 100 or so, not thousands). In some cases it was apparently just input error. In other cases what Quicken2007 showed on the computer was, well, not what the QIF said. In one or two cases the numerical value was different in QIF than on the computer. Odd.
GnuCash's default setup turned Quicken Categories into GnuCash accounts. This, it turned out, resulted in exactly the behavior we wanted. Note that if you import a QIF data file twice in a row GnuCash thinks you are merging and...it bogs down to a crawl. So if you fix QIF for some reason remove any previous GnuCash files before re-importing! Seems obvious, but the first time it imported like a snail I was mystified!
Security: We do the day-to-day work on a machine we don't plug into any network. The backups are on disks not plugged into anything except to the one machine (and only while doing a backup). You should consider doing that too. I won't go into details, but do plan a backup strategy. And verify it works.
The learning curve for GnuCash was a challenge. It took several days to get over some misconceptions and even longer to figure out how to deal with transactions we made errors in. The GnuCash documentation on the web is pretty good. And certainly essential. Use it (but do that web access on a different machine, obviously).
It was well worth the learning effort. Our data now belongs to us. We had some random crashes with the old Quicken. None so far with GnuCash.
One issue arose with GnuCash and its Graphical User Interface. While the built-in search functionality is very powerful it seemed difficult to get the right level of search-result detail visible at the same time as the account data. So I wrote an application in the Python language to do simple searches and to report the output in simple text files. Making it easy to have several search results around while not interfering with the current view of the accounts.
Here is a sample. Slightly modified to avoid showing anything personally meaningful. First, an example command line:
python -case 1 -s Bond
Next, the output from the test file:
Searchterm: "Bond" Dateterm: "" Casesensitive: "y" Transaction : 19xx-06-05 00:00:00 Bond=350 + quake refund=34.14 Split: 384.14 Bank A Split: ins co refund of premium -34.14 Unspecified Split: bond -350.00 non-taxable
The -s clause is an 'and' clause. One can have as many -s options as one wants on the command line. The search considers the base transaction and the splits as a single entity (more or less).
Download the simple search application here (gzipped python source code) .