Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
On Tue, May 30, 2017 at 9:39 PM, Peter McArthur 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! Yo
Re: Conversion nightmares: gnucash to ledger-cli
Dear Rushad, Rushad Faridi writes: > Firs I tried ledger 2.x approach since 3.x can not do the conversion. I > had not much of a problem installing 2.x but after I issued the command " > ledger -f myfile.gnucash print > myfile.txt" it spitted out 27 lines of > error with something " invalid date string". I had a cursory look at my > account entries but did not find anything wrong. Any suggestions on how to > fix that? What were the errors that you saw? Probably someone here can help you with this, but we'd need more information about what went wrong. > Anyway, I went ahead > and ran the python script "gnucash2ledger.py" downloaded from > "https://github.com/MatzeB/pygnucash"; in the following manner: > > python2.7 gnucash2ledger.py myfile.gnucash print > test.txt (It does not look like you should have "print" in this command line invocation, though probably the Python program is just ignoring it.) > The error came through is as follows: > > Traceback (most recent call last): > File "gnucash2ledger.py", line 35, in > data = gnucash.read_file(sys.argv[1]) > AttributeError: 'module' object has no attribute 'read_file' This is a strange error to see, if you are indeed using the code from that repository. Python is complaining that it can't find the read_file function in the gnucash module. But the gnucash module from that repository does contain such a function. So either you're importing a *different* module named "gnucash", or something very weird is happening in the gnucash2ledger module that messes up the attributes of its own gnucash module. I suspect the former. Try this: 1) Run a Python interpreter from a directory *outside* the repository you referenced (so that the pygnucash code is not on Python's search path). 2) Type 'import gnucash' at the prompt. You should see an ImportError. 3) If you do *not* see an ImportError, your Python is importing some other module named 'gnucash' (perhaps this comes with GnuCash itself?). Try typing: gnucash.__file__ gnucash.__path__ at the Python prompt. This will tell you where the conflicting gnucash module is located. 4) If you *do* see an ImportError, quit Python, and try these steps again, but this time run Python from *inside* the pygnucash repository. This time, you should *not* see an ImportError. In that case, make sure that gnucash.__file__ and gnucash.__path__ are what you'd expect, and then try hasattr(gnucash, 'read_file') This should return True. Let us know what you see! Best, Richard -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
> "PM" == Peter McArthur writes: PM> The manual shows us how unclear the semantics are. Most people seem to use PM> auxiliary dates as a date when a cheque is *cleared*. But the manual also PM> shows them being used when a cheque is *paid*: It should be noted here that one of the "features" of Ledger is that it leaves as much of the semantics of your accounting as possible up to you. This is a reason why beancount was created: To choose the best notion of what things mean in a financial setting, and then to impose those semantics to help you avoid errors. C++Ledger, however, is just a glorified calculator. It doesn't tell you what your inputs or your outputs should mean. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
On Wed, May 31, 2017 at 12:59 PM, John Wiegley wrote: > > "PM" == Peter McArthur writes: > > PM> The manual shows us how unclear the semantics are. Most people seem to > use > PM> auxiliary dates as a date when a cheque is *cleared*. But the manual > also > PM> shows them being used when a cheque is *paid*: > > It should be noted here that one of the "features" of Ledger is that it > leaves > as much of the semantics of your accounting as possible up to you. This > is a > reason why beancount was created: To choose the best notion of what things > mean in a financial setting, and then to impose those semantics to help you > avoid errors. > > C++Ledger, however, is just a glorified calculator. It doesn't tell you > what > your inputs or your outputs should mean. > So - -- from your perspective you don't see a value in having something defined that would help with the date paid, date cleared, date issued (more for invoicing) as a specific 'data type' available for use? As a small business owner that really doesn't want to buy the rights to the use (sort of) of some Win program that isn't really that responsive (to my needs at least) I would like to see something that would enable me to run some kind of a report. This report would then be able to tell me which invoices to be paid or those due me that are outstanding (possibly with a way to make aging easy). I understand that you see C++Ledger as a 'simple' tool - - - I think it is a tool that appears simple but has the framework to do even more. (To use the analogy of a calculator it looks like perhaps just a 4 function machine and then when you dig a little deeper you see the scientific functions and then deeper yet you find the statistical functions and the vector/polar calculations and and and. This is how I see ledger - - - its a tool with little showing on the surface but there is a vast world below!) 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
On Wednesday, 31 May 2017 18:58:10 UTC+1, John Wiegley wrote: > > > "PM" == Peter McArthur > writes: > > PM> The manual shows us how unclear the semantics are. Most people seem to > use > PM> auxiliary dates as a date when a cheque is *cleared*. But the manual > also > PM> shows them being used when a cheque is *paid*: > > It should be noted here that one of the "features" of Ledger is that it > leaves > as much of the semantics of your accounting as possible up to you. Yes, the semantics are up to you, but you can only have one kind of auxiliary date. That’s quite a restriction. If you’ve used auxiliary dates to spread your payment to Bountiful Blessing Farm over time, as the manual suggest, you can’t also use them to mark when a cheque cleared. Compare that to tags. While there are two special tags called * and !, there's nothing they can do that other tags can't, as far as I'm aware. For instance, this: 2017-05-20 McDonald’s food and drink £ -1.99 *** current account £ 1.99 $ ledger -f journal balance *--cleared* 17-May-20 McDonald’scurrent account £ 1.99 £ 1.99 $ ledger -f journal balance *--uncleared* 17-May-20 McDonald’sfood and drink £ -1.99 £ -1.99 Is pretty much the same as this: 2017-05-20 McDonald’s food and drink £ -1.99 current account £ 1.99 *; :cleared:* $ ledger -f journal balance *%/cleared/* 17-May-20 McDonald’scurrent account £ 1.99 £ 1.99 $ ledger -f journal balance *'not(%/cleared/)'* 17-May-20 McDonald’sfood and drink £ -1.99 £ -1.99 I would like to similar freedom with dates. This is a reason why beancount was created: To choose the best notion of > what things mean in a financial setting, and then to impose those semantics > to help you avoid errors. I'm not experienced with beancount but, so I may have misunderstood you, but I don't really see what you're getting at. Power and flexibility are good. The ability to add constraints is also good. They work best when used together. -- --- 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.
Re: Reporting (reg and bal) with historical prices
Looks like -H is what I need in this case. Thanks a lot John! On 30 May 2017 at 21:38, John Wiegley wrote: > > "VS" == Vladimir Sorokin writes: > > VS> I'm trying to generate reports for an account which has transactions in > VS> different currencies, and I stuck. > > Have you tried the -B (cost basis) and -H (historical price) options? > > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 > -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
> "o" == o1bigtenor writes: o> So - -- from your perspective you don't see a value in having something o> defined that would help with the date paid, date cleared, date issued (more o> for invoicing) as a specific 'data type' available for use? Not as part of the internals of Ledger, no. As something in the form of external scripting, such as by using the Python support, sure. o> I understand that you see C++Ledger as a 'simple' tool - - - I think it is o> a tool that appears simple but has the framework to do even more. (To use o> the analogy of a calculator it looks like perhaps just a 4 function machine o> and then when you dig a little deeper you see the scientific functions and o> then deeper yet you find the statistical functions and the vector/polar o> calculations and and and. This is how I see ledger - - - its a tool with o> little showing on the surface but there is a vast world below!) You might want to give beancount a look, since it has much more of an accounting focus. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
> "PM" == Peter McArthur writes: PM> I'm not experienced with beancount but, so I may have misunderstood you, PM> but I don't really see what you're getting at. Power and flexibility are PM> good. The ability to add constraints is also good. They work best when PM> used together. I want you to add the constraint, not me. If there's a constraint you want to encode but can't, I'd want to find a way to generalize what you're trying to accomplish. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
On Wed, May 31, 2017, at 04:39 AM, Peter McArthur wrote: > 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. I was very as very interested in this idea, however based on your example from the other thread I don't understand how you've changed the situation. Your example, aiui: 05/25 McDonald’s expenses:food and drink:fast food £ -0.99 assets:current account:uncleared £ 0.99 assets:current account:uncleared £ -0.99 ; [05/27] assets:current account:cleared£ 0.99 ; [05/27] With regard to the problems raised above: 1. This seems to make it no easier to detect and correct errors than a tick mark on your bank statement. To add the final lines you still have to go through the statement line by line. 2. There still seems to be no record tieing your entry to the line item on your bank statement. Had you added a comment containing the exact details from your statement then you could match. This could also be accomplished by just numbering the entries on your bank statement and then adding a cleared line number comment. 3. Agreed as solved if a suitable parser is written. It seems your syntax could be expanded to solve number 2 by encoding it as something like: 05/25 McDonald’s expenses:food and drink:fast food £ -0.99 assets:current account:XYZ £ 0.99 05/27 McD Flughafen Wien assets:current account:XYZ £ -0.99 assets:current account:£ 0.99 This presumes you can load the transactions from your statement. You would have to tie the two entries together via the XYZ subaccount where XYZ is a unique transaction identifier. A suitable parser could then generate a reconciliation report. However, this seems to have no significant value for error detection and correction (item #1) over the existing process you've described or the process of making tick marks on statements. I suspect I've missed something in your explanation and look forward to your response. Regards, bex -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
> > 1. This seems to make it no easier to detect and correct errors than a > tick mark on your bank statement. To add the final lines you still have to > go through the statement line by line. > > 2. There still seems to be no record tieing your entry to the line item on > your bank statement. Had you added a comment containing the exact details > from your statement then you could match. This could also be accomplished > by just numbering the entries on your bank statement and then adding a > cleared line number comment. > > 3. Agreed as solved if a suitable parser is written. > I haven’t tested this, but I believe Ledger offers a simpler way to do it with the Payee tag. Payee is a special metadata tag which allows you to modify the payee field for individual posts within a transaction. So if this is my bank statement: *DateTransaction Type Description Money out Money in Balance* ... ... ...... ... ... 27th May 2017 Contactless Payment MCDONALDS WIEN DE£0.99 £173.48 Here’s what I would put in my ledger file: 05/25 McDonald’s expenses:food and drink:fast food £ -0.99 assets:current account:uncleared £ 0.99 ; assets:current account:uncleared £ -0.99 ; [05/27] Payee: MCDONALDS WIEN DE assets:current account:cleared£ 0.99 ; [05/27] Payee: MCDONALDS WIEN DE All four posts are now linked by being part of the same transaction, without any need for transaction codes. By the way, I’m uncomfortable with the way you used an :XYZ subaccount. Is it not possible to do the same thing with tags? -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
On Thu, Jun 1, 2017, at 06:17 AM, Peter McArthur wrote: >> 1. This seems to make it no easier to detect and correct errors than >>a tick mark on your bank statement. To add the final lines you >>still have to go through the statement line by line.>> >> >> 2. There still seems to be no record tieing your entry to the line >>item on your bank statement. Had you added a comment containing >>the exact details from your statement then you could match. This >>could also be accomplished by just numbering the entries on your >>bank statement and then adding a cleared line number comment.>> >> 3. Agreed as solved if a suitable parser is written. > > I haven’t tested this, but I believe Ledger offers a simpler way to do > it with the Payee tag. Payee is a special metadata tag which allows > you to modify the payee field for individual posts within a > transaction. So if this is my bank statement:> > *DateTransaction Type Description Money out > Money in Balance*> ... ... ... >... > ... ...> 27th May 2017 Contactless Payment MCDONALDS WIEN DE > £0.99£173.48> > Here’s what I would put in my ledger file: > > 05/25 McDonald’s > expenses:food and drink:fast food £ -0.99 > assets:current account:uncleared £ 0.99 > ; > assets:current account:uncleared £ -0.99 ; [05/27] Payee: > MCDONALDS WIEN DE> assets:current account:cleared£ 0.99 ; [05/27] > Payee: > MCDONALDS WIEN DE> > All four posts are now linked by being part of the same transaction, > without any need for transaction codes.> > By the way, I’m uncomfortable with the way you used an :XYZ > subaccount. Is it not possible to do the same thing with tags? Certainly, but early this morning this isn't what first popped into my mind :). My concern remains with #1. I feel like we've added a lot of work (assuming no automation) without solving the problem. regards, bex -- --- 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.
Re: Why I don’t want to use auxiliary dates for bank reconciliation … or anything else
> > I feel like we've added a lot of work (assuming no automation) > Agreed. Without automation, it’s probably not worth the effort. In fact, this whole discussion started with me asking for help with the automation, and others asking why I would want to do such a thing. > without solving the problem. > If it doesn’t solve any problem you have, and if it makes life harder for you in some way, then of course you shouldn’t do it. If it doesn’t solve any problem you have, but it doesn’t create any work, then I would suggest that my way is better, because it hews closer to the double-entry model. The closer you stay to that model, the more use you can get from Ledger’s general purpose tools for handling double-entry accounts. -- --- 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.