On Mon, Apr 29, 2013 at 2:25 PM, Graham Leggett <minf...@sharp.fm> wrote:
> On 29 Apr 2013, at 7:28 PM, John Ralls <jra...@ceridwen.us> wrote: > > > Because Gnucash isn't that kind of a program. It's an accounting > program, the exact domain for which SQL was invented. "Basically Available, > Soft state, Eventual consistency" are all anathema to accountants. > > Really? I am still waiting for one client's accountant to "eventually" pay > me, and I will "eventually" capture those invoices piled on my desk. > That may be true, but those aren't features I'd want in my books (software or hardware). I want my books to be consistent whenever I look at them. I don't want an invoice to be seen in my "Expense" account, but not in my "A/P" (or cash, depending on accrual/cash accounting) account. I want my credits to always equal by debits; always, not "eventually". While it's true that my books don't capture the invoices in unopened envelopes on my desk, or the cash sitting in the donation jar by the front door (I'm treasurer for a small non-profit), that's not a problem with GnuCash. > > > Would you want your bank to treat your account that way? > > My bank does treat my account this way. If you pay me now, I'll > "eventually" get the money, maybe in two hours, maybe in two days, maybe 7 > days if you gave me a cheque. As soon as I deposit a cheque, my bank records are consistent: Before I deposited the cheque, I had $9000 in the account, but there were outstanding, uncleared debit-card transaction totalling $500, so $8500 was available for my use. After the deposit, I had $10,000 in the account, but there were outstanding, uncleared debit-card transactions totalling $500, and there is a hold on $800 until the cheque is cleared by the recipient bank, so $8700 is available for my use. At all times everything adds up properly (total-uncleared-held=available). There is no "eventually" it'll be right. There's just an "eventually" your books will match theirs, and that's a standard property of how accounting works between different entities. That said, I'm not 100% certain that the original poster (b...@comcast.com) is referring to the "Basically Available, Soft state, Eventual consistency" paradigm when he/she asks why GnuCash isn't based on Base. There are a lot of things "Base" could be referring to other than the anti-ACID database paradigm. Base SAS software, for instance, which is described as a "Flexible and extensible fourth-generation programming language designed for data access, transformation and reporting", and is decidedly not free software. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
