On Tue, May 30, 2017 at 9:39 PM, Peter McArthur <peter.mcart...@gmail.com> wrote:
> First I should describe my philosophy. > > We’re all computer nerds here, I think, so we all know the value of > simple, flexible abstractions with strong mathematical underpinnings. > Relational databases, the lambda calculus, finite automata, context free > grammars and so on. I believe double-entry book keeping deserves a place in > that last. > > > I shan’t go into this in any depth, but I don’t think many people – even > professional accountants – appreciate the mathematical brilliance that > underlies the double-entry system. But it was this brilliant idea that > turned all our ad hoc book keeping systems into a coherent, flexible whole, > with lots of side benefits I won’t go into here. > > > So, just as we have SQL for talking about relational databases, or regular > expressions for talking about finite automata, I see Ledger as a language > for talking about double-entry book keeping, and in my view that is a very > good thing. > > This topic arose in the context of bank reconciliation, so, let’s talk > about bank reconciliation. The traditional, pen-and-paper way of doing it > is: > > 1. Go through your accounts and your bank statement, matching them > item by item, and checking off matched items. > 2. At the end of this process, there will probably be a few unmatched > items in your accounts, because they haven’t cleared yet. Make a note of > these in a Reconciliation Report, and check that they are all reconciled > next month. > > The advantage of this method is that it is quick and efficient. That > mattered a lot in the era of pen-and-paper accounting, but now it doesn’t, > so I think we should consider its disadvantages too: > > 1. It’s hard to detect and correct errors. > 2. There is no record of which item in your accounts matched which > item in your bank statement, so if you ever need to check again your work > is partially wasted. > 3. The Reconciliation Report is a new kind of artefact that exists > outside your core accounting system. > > All of the above can be solved if we split the bank account into two sub > accounts: one for uncleared transactions and one for cleared transactions. > It’s the double-entry way of doing it. They didn’t do this in the era of > pen-and-paper accounting because it wasn’t worth the extra effort, but now > it just seems the obvious and natural thing to do. > > > “So why don’t professional accountants do it?” I hear you ask. That’s a > good question. I went and asked that very question on an accountant’s forum > (which I was already a member of), and I got five answers. They were: > > 1, 2 & 3. But that’s more complicated the way we do it now. *[I > disagree!]* > 3. That would make life harder if the computers stopped working and we had > to go back to pen-and-paper. *[Fair point.]* > 5. Our accounting software already does things that way, and it works > great! > > > I believe that accountants could start using the new system now, if they > wanted, but most are reluctant to move on from a system they’ve invested so > much in learning. Pretty much how my wife felt when I persuaded her to > switch to a Mac. ;-) > > So, now, on to Ledger’s way of doing things. I said earlier I disliked the > * tag. That’s not really true. I have no problem with metadata tags without > special semantics. But I REALLY dislike auxiliary dates. They are *not* a > core concept of double-entry; they have unclear semantics; and they violate > some important design heuristics without good reason, namely: > > - *Zero, one, infinity:* An entity should be forbidden, one should be > allowed, or any number should be allowed. *[Definitely not two!]* > - *Minimalism:* A designer knows he has achieved perfection when there > is nothing left to take away. *[I do not think auxiliary dates are > ever necessary.]* > > The manual shows us how unclear the semantics are. Most people seem to use > auxiliary dates as a date when a cheque is *cleared*. But the manual also > shows them being used when a cheque is *paid*: > > > 2008/01/01=2008/01/15 Client invoice > > Assets:Accounts Receivable $100.00 > > Income: Client name > > > or when it is *not* paid: > > > 2008/10/16 * (2090) Bountiful Blessings Farm > > Expenses:Food:Groceries $ 37.50 ; [=2008/10/01] > > Expenses:Food:Groceries $ 37.50 ; [=2008/11/01] > > Expenses:Food:Groceries $ 37.50 ; [=2008/12/01] > > Expenses:Food:Groceries $ 37.50 ; [=2009/01/01] > > Expenses:Food:Groceries $ 37.50 ; [=2009/02/01] > > Expenses:Food:Groceries $ 37.50 ; [=2009/03/01] > > Assets:Checking > > > If you included all three of these in your accounts, you’d end up in a > terrible mess. And in any case, a trained accountant would look at the two > examples above and say, “No, you’re doing it wrong! You should …” and then > describe a method that doesn’t use auxiliary dates at all. (I’ll leave the > details as an exercise for the reader.) > > To be clear, I’ve nothing against adding extra dates to accounts *per se*. > But I dislike the privileged status given to auxiliary dates. I would much > rather see Ledger improve its support for typed tag values (e.g. cleared:: > [05/30]) so that auxiliary dates could be downgraded to a special syntax. > E.g. [=05/30] might become a synonym for AuxiliaryDate:: [05/30]. > > -- > Greetings Didn't trim the foregoing as I didn't know what to cut to still keep all the important parts alive and nothing else. Something like this 'typed tag value' would be very valuable for invoicing in a small business. There possibly also could be a use for this in inventory control (which makes me wonder how I could use Ledger for just that!). Maybe Ledger 4.0 (or 3.5 (or whatever)) could do this for us small business owners who want that plain text archive yet need tools to work on the informaiton in that text file!!. (Ledger does a good job of what its doing so far!! Dee -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
