Supported syntaxes for acquiring lots

114 views
Skip to first unread message

Jeff Brantley

unread,
Jan 18, 2019, 10:29:28 AM1/18/19
to Beancount
Context: I'm going back and getting true transaction data from a Fidelity 401(k), which started years before I started keeping books, and has since ended (job change and subsequent rollover to IRA). Fidelity gives me date of contribution, total dollar amount of contribution, and fractional number of shares purchased. It doesn't provide the unit price.

So, two questions:

1. Is it possible to have beancount infer the unit price, or do I need to provide it explicitly? One could imagine writing 123.456 HOOL {} @@ 789.10 USD, and leaving the balancing posting blank for equity-balanced posting (see #2) or in 789.10 USD, for a PreTax401k:Cash-balanced posting. To be clear, I'm talking about when the commodity was acquired, not when it's sold.

2. The documentation sometimes shows a 2- or 3-tuple for the lot definition, including date. Can an explicit date be given when the lot is acquired, separate from the date of the transaction. That is, can I have an Equity:Opening-Balance type entry with a transaction date of 2016-01-01 (when I started keeping books) and a lot date of, e.g., 2013-05-13 (date of first 401k contribution)? I'm imagining that would look like: 123.456 HOOL {xx.yy USD, 2013-05-13}

Martin Michlmayr

unread,
Jan 18, 2019, 10:52:58 AM1/18/19
to bean...@googlegroups.com
* Jeff Brantley <jsb...@gmail.com> [2019-01-18 07:29]:
> 1. Is it possible to have beancount infer the unit price, or do I
> need to provide it explicitly? One could imagine writing 123.456
> HOOL {} @@ 789.10 USD

You can write:

Assets:Investments 123.456 HOOL {{789.10 USD}}

beancount will covert from 789.10 USD to a per share price internally:

2019-01-18 * Bought 123.456 HOOL {6.39 USD}
2019-01-18 * Bought -789.100 USD

> 2. The documentation sometimes shows a 2- or 3-tuple for the lot
> definition, including date. Can an explicit date be given when the lot is
> acquired, separate from the date of the transaction. That is, can I have an
> Equity:Opening-Balance type entry with a transaction date of 2016-01-01
> (when I started keeping books) and a lot date of, e.g., 2013-05-13

Yes.

2016-01-01 * "Bought"
Assets:Investments 123.456 HOOL {{789.10 USD, 2013-05-10}}
Equity:Opening-Balance

--
Martin Michlmayr
https://www.cyrius.com/

Jeff Brantley

unread,
Jan 18, 2019, 7:50:22 PM1/18/19
to Beancount
Thanks, this is exactly what I needed to know.


On Friday, January 18, 2019 at 9:52:58 AM UTC-6, Martin Michlmayr wrote:
* Jeff Brantley <jsb...@gmail.com> [2019-01-18 07:29]:
> 1. Is it possible to have beancount infer the unit price, or do I
> need to provide it explicitly? One could imagine writing 123.456
> HOOL {} @@ 789.10 USD

You can write:

    Assets:Investments           123.456 HOOL {{789.10 USD}}

I think this is missing from the Language Syntax document, but I do see now that it's listed in the Syntax Cheat Sheet.
 
beancount will covert from 789.10 USD to a per share price internally:

2019-01-18 *   Bought  123.456 HOOL {6.39 USD}
2019-01-18 *   Bought -789.100 USD

> 2. The documentation sometimes shows a 2- or 3-tuple for the lot
> definition, including date. Can an explicit date be given when the lot is
> acquired, separate from the date of the transaction. That is, can I have an
> Equity:Opening-Balance type entry with a transaction date of 2016-01-01
> (when I started keeping books) and a lot date of, e.g., 2013-05-13

Yes.

2016-01-01 * "Bought"
    Assets:Investments           123.456 HOOL {{789.10 USD, 2013-05-10}}
    Equity:Opening-Balance

Okay, I found an example of explicitly dating the purchase in Trading with Beancount, and eventually explicit wording about overriding the date in How Inventories Work. It's listed in the Cheat Sheet as well. But again, I can't find any reference to it in Language Syntax, which seems peculiar.

Anyhow, thanks for your help!

Jeff Brantley

unread,
Jan 18, 2019, 9:38:41 PM1/18/19
to Beancount

This seems to be working pretty well, except I think it is leading to over-precision problems. As shown below, I booked an opening transaction establishing years' worth of lots of a TDF, then booked a bunch of payslips, each of which puts money into a 401k Cash account, with a related transaction that purchase more of the TDF using the Cash. So, money flows into Cash, then flows out. So I placed a balance assertion after the job concluded, stating that there should be 0 USD in cash. But I get an error due to a silly precision of 3E-25.

2016-01-01 * "Starting position"
  Assets:Fidelity:CompanyA:PreTax401k:LIPIX      10.175 LIPIX {{109.69 USD, 2013-07-01}}
  Assets:Fidelity:CompanyA:PreTax401k:LIPIX       0.051 LIPIX {{  0.58 USD, 2013-09-30}}
  ;; ... about 60 lots
  Assets:Fidelity:CompanyA:PreTax401k:LIPIX       9.783 LIPIX {{115.05 USD, 2016-01-04}}
  Equity:Opening-Balances

;; for around 20 paychecks:

2016-01-14 * "CompanyA Payroll" ""
  Income:CompanyA:Salary                                   -1111.11 USD
  ;; ...
  Assets:Fidelity:CompanyA:PreTax401k:Cash                   115.05 USD
  ;; ...
  Income:CompanyA:Match401k                                 -115.05 USD
  Assets:Fidelity:CompanyA:PreTax401k:Cash                   115.05 USD

2016-01-15 * "Contribution"
  Assets:Fidelity:CompanyA:PreTax401k:LIPIX      20.994 LIPIX {{230.10 USD}}
  Assets:Fidelity:CompanyA:PreTax401k:Cash

;; ...earned dividends for a while after job ended...

2017-12-29 * "Dividend"
  Assets:Fidelity:CompanyA:PreTax401k:LIPIX      11.606 LIPIX {{173.97 USD}}
  Income:Fidelity:Dividends

2018-01-10 balance Assets:Fidelity:CompanyA:PreTax401k:Cash        0 USD

2018-01-11 * "Liquidated for Transfer"
  Assets:Fidelity:CompanyA:PreTax401k:LIPIX   -1056.687 LIPIX {} @@ 16262.42 USD
  Assets:Fidelity:CompanyA:PreTax401k:Cash     16262.42 USD
  Income:Fidelity:PnL                          -3236.81 USD

This balance assertion results in the following error from bean-check:

path/to/main.beancount:3503:    Balance failed for 'Assets:Fidelity:CompanyA:PreTax401k:Cash': expected 0 USD != accumulated 0.0000000000000000000000003 USD (3E-25 too much)

   2018-01-10 balance Assets:Fidelity:CompanyA:PreTax401k:Cash        0 USD

Is this crazy precision a direct result of my exclusively using the double-brackets to infer a share price every time I purchased a lot of the fund? If so, what is the recommended practice at this point to convince beancount to use a more reasonable precision?

Thanks again

Martin Michlmayr

unread,
Jan 18, 2019, 9:42:37 PM1/18/19
to bean...@googlegroups.com
* Jeff Brantley <jsb...@gmail.com> [2019-01-18 18:38]:
> If so, what is the recommended practice at this point to convince
> beancount to use a more reasonable precision?

Does adding this to the top of the file help?

option "inferred_tolerance_default" "USD:0.01"

Jeff Brantley

unread,
Jan 18, 2019, 9:49:11 PM1/18/19
to Beancount
Yes, it does. I don't yet have the understanding of the implications of setting this, nor the run-time with beancount to predict any consequences of a particular choice (0.01, 0.001?), but yes that does fix the issue for now.

Thanks

Martin Blais

unread,
Jan 19, 2019, 12:50:16 AM1/19/19
to Beancount
There's a newer syntax for this
{ # total amount}
Instead of
{{ total amount }}
Reason is it can be combined with per unit amount

  

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20190118155252.4ypymxfuzbdowgz2%40jirafa.cyrius.com.
For more options, visit https://groups.google.com/d/optout.

Jeff Brantley

unread,
Jan 19, 2019, 2:23:27 PM1/19/19
to Beancount
How new? I'm running Beancount 2.2.0, per `bean-check --version`.

If I try to use { # 123 USD} instead of {{123 USD}}, bean-check barfs with "Too many missing numbers for currency group 'USD'" for each instance.

(And the beancount plugin for Sublime Text doesn't recognize this as valid syntax, highlighting the # character in an unhappy pink shade. So I'm guessing this is pretty new.)

Martin Michlmayr

unread,
Jan 19, 2019, 3:07:38 PM1/19/19
to bean...@googlegroups.com
* Jeff Brantley <jsb...@gmail.com> [2019-01-19 11:23]:
> How new? I'm running Beancount 2.2.0, per `bean-check --version`.
>
> If I try to use { # 123 USD} instead of {{123 USD}}, bean-check barfs with
> "Too many missing numbers for currency group 'USD'" for each instance.

It has to be

{ 0 # 123 USD}

which I believe means: 0 per share plus a total of 123 USD.

One of the examples previously given is
Assets:Investments 100 MSFT {42.00 # 9.95 USD}
i.e. 100 shares at $42 each plus $9.95 fees.

Martin, it sounds like { 0 # xx USD} is preferred over {{...}}, right?
(I'm wondering if ledger2beancount should use this syntax. Then
again, {{ ... }} works)

Martin Blais

unread,
Jan 20, 2019, 11:17:28 AM1/20/19
to Beancount
That sounds like a bug
It should be accepted without a zero

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

Martin Michlmayr

unread,
Jan 24, 2019, 10:23:39 AM1/24/19
to bean...@googlegroups.com
* Martin Blais <bl...@furius.ca> [2019-01-20 08:15]:
> That sounds like a bug
> It should be accepted without a zero

I've filed an issue with a test case now:
https://bitbucket.org/blais/beancount/issues/366/

It only fails in some circumstances.

Martin Blais

unread,
Jan 29, 2019, 11:22:09 PM1/29/19
to Beancount
Thank you Martin


--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages