This page is largely obsolete in favor of quaken developments.
hmm... move this to an advogato diary?
I wrote my first personal finance program back in high school when I realized a spreadsheet wasn't going to cut it. (@@hmm... where is that thing, anyway? it was written in pascal or Basic09 or some such for the color computer; I think I have it on 5.25" floppy.)
Then I discovered Quicken. Wow! I've been a loyal quicken customer since about 1998 (version @@??? on a Mac). I upgraded thru version 6 for windows. But Quicken'99 is bloatware. Blech. (@@more on why I don't like Quicken '99: no DDE/OLE automation, etc.).
I'm a pretty loyal Discover card customer: initially, because it was the only card that SAMs accepted; but more recently: because I can download my statement data straight from the web! I wrote a little perl script(disc-to-qif.pl (obsoleted by disc2qif.xsl in quacken) to screen-scrape the data into QIF format. They seem to offer direct integration with Quicken '99, but as I say, that's bloatware. And they accept checks over the web! (@@link to smartcheck blurb) The cashback bonus is no big deal, but sometimes it makes up for various service charges.
@@webturbotax: ingeneous!
@@fast company, Small Business Computing and Communication
It's time for an Open Source personal finance program.
I've been doing some python, XSLT, etc. hacking with my quicken data. (@@tsv2xml, reportSemantics.xsl, mergeExpenses.xsl, etc.@@)
Export using tab-separated ascii reports, rather than QIF (@@explain).
php version of quicken... aha! saCASH On Oct 2, 2000 at 13:53pm, I downloaded saCASH_0.4.0.tar.gz md5:fa1171c72ace9fbcbbe204e46e7a1646. On 21 Dec, I installed the debian packages for PostgreSQL and PHP3 and go it going. I wrote a little python hack to take the quicken transaction report and normalize it into the accounts/categories/trans/t_entry tables ala saCASH.sql. Hmm... a few details with split transactions remain.
More ideas...
QIF parser: implements @@SAX interface (@@compare with libHTML code from 1990/91). @@Larch spec for SAX?
discover card statement access: XML RPC wrapper. hmm... authentication? ssh? need ssl module for python (aha! OpenSSL apps).
Authentication should be a proof that "this request comes from the party who executed the (only outstanding) cardmember agreement for card #NNNN-NNNN-NNNN-NNNN". I'm not sure what the combination of passwords etc. and the mechanisms used to set them up acutally do attest to.
It's nice that discover puts the data on the web, but the system shouldn't require that I trust them. I want the system to provide integrity from the transaction event forward. I wish point-of-sale gizmos would talk IRDA or bluetooth to my pilot. Until then, I have to keep the paper receipts and verify the online records against them. :-{ I'd like to be able to look at a bunch of online records and a pile of receipts and digitally attest to the veracity of the online records and then throw away the paper. Of course, the digital signature better not get lost. So I need plenty of redundant copies. But the data might be sensitive, so I have to keep the copies confidential. Major PITA factor! Hmm... the signature, detached from the data, is almost certainly not sensitive. So I could trust discover to keep the data available to me and confidential, and use public storage facilities to store the signatures.
integration with online services.
@@cbb, gnucash, ...
U.C.C. - ARTICLE 3 - § 3-104. (check by fax checkfaxx yahoo check software National Automated Payment Association)
Draft Creator FAQ - Questions You May Have
Arcosoft - In search of an Internet payment processing service
RISKS-LIST: RISKS-FORUM Digest
taken from research notebook