Don’t Sink Your First Attempts at Plaintext Accounting
Robert Nielsen
I wrote the article below to help newcomers to plaintext accounting. Simon, if you think this would be useful for any of your websites, you have my permission to post it there.
Enjoy!
Don’t Sink Your First Attempts at Plaintext Accounting
Plain text accounting programs such as Ledger and HLedger are powerful, helpful tools, but your own user errors can take the wind out of your sails when you would rather be breezing through your accounting. Here, then, are several mistakes—ones that I have personally tested—that you will want to avoid in order to enjoy the benefits of plaintext accounting without unnecessary pain.
Preliminary assumptions:
· You have Ledger or Hledger already installed and running on your PC, and you are ready, or have already begun, to start entering your data.
· You understand that there are normally three lines of text for each transaction, and you know basically what’s supposed to go in each line
Formatting Can Be Critical
The following two formatting errors will cause your work to come to a screeching halt. Here’s how to avoid them.
First, as you enter transactions, make sure that the second and third (and any additional) lines in a transaction are indented by at least one space. In other words, do this:
2017/01/15 Acme
Expenses:Household $20.00 ;roadrunner trap
Liabilities:CreditCard
Not this:
2017/01/15 Acme
Expenses:Household $20.00 ;roadrunner trap
Liabilities:CreditCard
The above two transactions look very similar to the human eye, but the second one doesn’t work.
Another formatting issue that’s easy to miss, is that you need at least two spaces between the category ”Expenses:Household,” below) and the amount of the transaction (“$20.00”):
2017/01/15 Acme
Expenses:Household $20.00
Liabilities:CreditCard
Contrast this with the wrong way:
2017/01/15 Acme
Expenses:Household $20.00
Liabilities:CreditCard
As it’s very hard to see the number of spaces in the critical parts, I have written them out in the two transactions below.
Correct:
2017/01/15 Acme
Expenses:Household[space][space]$20.00
Liabilities:CreditCard
Wrong:
2017/01/15 Acme
Expenses:Household[space]$20.00
Liabilities:CreditCard
Again, it’s easy for us humans to miss the difference between one space and two, but your plaintext accounting program will notice.
Use Currency Symbols Consistently
Here’s another error that’s easy to make and easy to overlook – omitting a currency symbol. For example:
2017/01/15 Acme
Expenses:Household 20.00
Liabilities:CreditCard
If you have been working with US dollars, it’s very easy to think that the above 20.00 refers to $20.00, but Ledger and HLedger will process this amount as something other than US dollars.
Using a Comma When You Need a Period
Another mistake to avoid is inadvertently typing a comma where a decimal in required. Let’s say, for example, that you are recording the purchase of a yacht for slightly more than $1.2 million. Here is the error:
2017/01/16 Mega Yacht Company
Expenses:Leisure $1,245,449,72
Assets:Bank:Checking
The correct way to write this is:
2017/01/16 Mega Yacht Company
Expenses:Leisure $1,245,449.72
Assets:Bank:Checking
If you are using Emacs, erroneously using a comma instead of a decimal point as shown above can manifest itself as a confusing error message about no transactions that need to be cleared.
Summary
· Indent the second and following lines of each transaction. The first line of the transaction needs to be flush left.
· Use two spaces after the transaction category and before the currency symbol (assuming that you are working with currency).
· Use the currency symbol before every amount that’s currency.
· Don’t use a comma when you need to write a decimal point.
So, avoid the above mistakes and enjoy some clear sailing with plaintext accounting.
Author: Robert Nielsen
Simon Michael
Robert Nielsen
Simon Michael
--
You received this message because you are subscribed to the Google Groups "hledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Plain Text Accounting -- Errors.docx>
Martin Blais
So, avoid the above mistakes and enjoy some clear sailing with plaintext accounting.
Simon Michael
On Apr 21, 2017, at 8:16 AM, Martin Blais <bl...@furius.ca> wrote:These all look to me like they should be bug reports, not required reading.
- The two space rule hurts everyone at some point. Why not design the syntax to not be subject to the problem in the first place? Constrain the syntax not to allow spaces and you don't have this problem anymore.
- A missing currency symbol could be inferred automatically in many cases. If you don't use it and you can't infer it, an error should be raised.
- Bad commas in numbers should be easily detectable in the parser in most cases (they have to align to every three; if not aligned to groups of three, an error should be raised).
Simon Michael
Martin Blais
On Apr 21, 2017, at 8:16 AM, Martin Blais <bl...@furius.ca> wrote:These all look to me like they should be bug reports, not required reading.Hi Martin.. a very reasonable thought. We should do better. The devil is in the details, which I'd like to make some headway on:- The two space rule hurts everyone at some point. Why not design the syntax to not be subject to the problem in the first place? Constrain the syntax not to allow spaces and you don't have this problem anymore.I've thought of it many times. Ok, we disallow spaces in account names. What would be the plan for migrating (a) existing user data (b) existing docs and examples ? What would be the cost of this particular incompatibility with Ledger ?
- A missing currency symbol could be inferred automatically in many cases. If you don't use it and you can't infer it, an error should be raised.How would that work ?
Is that assuming one currency per account ?
What about cases where it can't be inferred ?
- Bad commas in numbers should be easily detectable in the parser in most cases (they have to align to every three; if not aligned to groups of three, an error should be raised).I think you're not saying drop support for using comma as decimal point ? And you are saying that digits should only be grouped in threes ?
According to https://en.wikipedia.org/wiki/Decimal_mark#Digit_grouping , digits are not (only) grouped in threes in India. I'm not finding other applications for that feature at the moment, but that seems a pretty big one. Maybe Kamar and others could comment.
jungle boogie
> I wrote the article below to help newcomers to plaintext accounting.
> Simon, if you think this would be useful for any of your websites, you
> have my permission to post it there.
>
>
> Enjoy!
>
>
>
> Formatting Can Be Critical
>
>
>
> The following two formatting errors will cause your work to come to a
> screeching halt. Here’s how to avoid them.
>
>
you have a recommendation on what I should use?
When I do hleder -f file.journal print > printed, the spacing is much
greater than two spaces, but I don't quite know what it is. I'd like the
file to be uniform throughout and when I open in a text editor (other
than vim), for the file to look sane.
Simon Michael
> On Feb 16, 2018, at 9:05 PM, jungle boogie <jungle...@gmail.com> wrote:
> I use vim and I'd like to setup a vim modeline in the hledger file. Do
> you have a recommendation on what I should use?
>
> When I do hleder -f file.journal print > printed, the spacing is much
> greater than two spaces, but I don't quite know what it is. I'd like the
> file to be uniform throughout and when I open in a text editor (other
> than vim), for the file to look sane.