3 ms·
I'd be interested to understand the rough details of your system. I have played around with ledger and beancount, but like you I find myself wanting a more prog
by mattarm 6y ago
I'd be interested to understand the rough details of your system. I have played around with ledger and beancount, but like you I find myself wanting a more programmatic access to the data. Maybe what we need is a sqliteaccounting.org site to explain the pros/cons!
- massysett 6y agoThere are two main tables: one that can hold any transaction, and another that's specifically for transactions I download from bank and credit card statements. It holds different data such as the unique identifier that banks assign in the OFX data (this helps avoid duplicate transactions.) Difficulty in dealing with data like that is a big reason I started to move away from plain text. There are other tables to hold what I call "categories" (accountants would call these "accounts") and "accounts" (these correspond to the more colloquial usage) and commodities and other items like the balances from bank statements. I considered both SQLite and Postgres. Postgres has nice things like true ALTER TABLE support but SQLite's ease of administration and simple API swamps any advantage that Postgres would offer for this. My user interface is in Haskell, but one could use any language for that - I just like Haskell. It's all CLI based. I import the overwhelming volume of transactions from bank downloads, but when I need to enter something manually I currently just write a little Haskell script to do it (eventually I might add a CLI program to do this.)