multiple transactions of the same commondity on the same day

[geof...@gmail.com]

My 401k plan applies the 'Mega Back Door' Roth conversion for me automatically.

This means that I have something like the following in my input file:

2020-02-04 * "CONTRIBUTION  - AFTER TAX POST"

  Income:Salary                            -5000 USD

  Assets:Investments:401k:PostTax:VFFSX    50 VFFSX {100 USD}

2020-02-04 * "Transfers - AFTER TAX POST - ROTH IN-PLAN CONVERSION"

  Assets:Investments:401k:PostTax:VFFSX  50 VFFSX {}

  Assets:Investments:401k:Roth:VFFSX      50 VFFSX {100 USD}

The above works fine, however, I am importing these from OFX, and the order is not guaranteed (since OFX is stored by account, if the Roth account gets read first, the order would be swapped).  If the order is swapped, I get a 'no position matches' error.  Also, it means I can't put these into different files, as I won't know the order they get sorted.  For now I've worked around the issue by ensuring the OFX file contains full datetime timestamps with enough precision to order the transactions, and then creating a single datetime ordered list before importing into beancount.  It works ok, but adds complexity to my workflow.

I thought that one of the tenants of beancount is to not care about the order of items within the input file(s).  Are there any recommendations on how I should be dealing with the above case?  

I tried an alternative of collapsing into a single transaction, but that also caused problems:

2020-02-04 * "CONTRIBUTION  - AFTER TAX POST"

  Assets:Investments:401k:PostTax:VFFSX  50 VFFSX {}

  Assets:Investments:401k:Roth:VFFSX      50 VFFSX {100 USD}

  Income:Salary                            -5000 USD

  Assets:Investments:401k:PostTax:VFFSX    50 VFFSX {100 USD}

The above doesn't resolve unless I instead include the explicit cost basis, in which case it works ok.  I could probably rework my workflow to find these cases and collapse them into single transactions but I'm not sure if that would make the workflow any simpler than what I'm doing now.

[Martin Blais]

On Wed, May 13, 2020 at 8:37 AM <geof...@gmail.com> wrote:

My 401k plan applies the 'Mega Back Door' Roth conversion for me automatically.

This means that I have something like the following in my input file:

2020-02-04 * "CONTRIBUTION  - AFTER TAX POST"

  Income:Salary                            -5000 USD

  Assets:Investments:401k:PostTax:VFFSX    50 VFFSX {100 USD}

2020-02-04 * "Transfers - AFTER TAX POST - ROTH IN-PLAN CONVERSION"

  Assets:Investments:401k:PostTax:VFFSX  50 VFFSX {}

I think you meant -50 here.

 

  Assets:Investments:401k:Roth:VFFSX      50 VFFSX {100 USD}

The above works fine, however, I am importing these from OFX, and the order is not guaranteed (since OFX is stored by account, if the Roth account gets read first, the order would be swapped).  If the order is swapped, I get a 'no position matches' error.  Also, it means I can't put these into different files, as I won't know the order they get sorted.  For now I've worked around the issue by ensuring the OFX file contains full datetime timestamps with enough precision to order the transactions, and then creating a single datetime ordered list before importing into beancount.  It works ok, but adds complexity to my workflow.

Alternatively you can make your importer bump the date of the contribution one day back (if you don't mind the inaccuracy this causes).

 

I thought that one of the tenants of beancount is to not care about the order of items within the input file(s).  Are there any recommendations on how I should be dealing with the above case?  

You make a great point. I disambiguate by (date, transaction-type, line-no)l but the guarantee is not as strong as the one you suggest, it's not independent of order (which would require a non-trivial redo of the booking algorithm) it's more that you cannot rely on it.

A while back I agreed to add the time to directives but not to honor them in sorting because it would create confusion around when balance / padding directives would occur.

But I just realized now that I constrained the option to add time only to transactions, it's probably harmless, and I could add the time to the sort key.

I tried an alternative of collapsing into a single transaction, but that also caused problems:

2020-02-04 * "CONTRIBUTION  - AFTER TAX POST"

  Assets:Investments:401k:PostTax:VFFSX  50 VFFSX {}

  Assets:Investments:401k:Roth:VFFSX      50 VFFSX {100 USD}

  Income:Salary                            -5000 USD

  Assets:Investments:401k:PostTax:VFFSX    50 VFFSX {100 USD}

The above doesn't resolve unless I instead include the explicit cost basis, in which case it works ok.  I could probably rework my workflow to find these cases and collapse them into single transactions but I'm not sure if that would make the workflow any simpler than what I'm doing now.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/beancount/ffdfa295-e7ae-4efc-bbab-4e412a6a7aff%40googlegroups.com.

[Martin Blais]

Just for fun I quickly added syntax for an optional time after the date but just for Transaction directives here:

https://github.com/beancount/beancount/tree/adding_time

bergamot [git|master]:~/p/beancount$ cat /tmp/before
Benchmark #1: time bean-check $L
  Time (mean ± σ):      6.352 s ±  0.353 s    [User: 6.183 s, System: 0.135 s]
  Range (min … max):    5.708 s …  7.757 s    30 runs

bergamot [git|master]:~/p/beancount$ cat /tmp/after
Benchmark #1: time bean-check $L
  Time (mean ± σ):      6.903 s ±  0.776 s    [User: 6.662 s, System: 0.140 s]
  Range (min … max):    6.213 s …  9.220 s    30 runs

Not even using it yet.

That's an 8.7% cost on the average run time.

[geof...@gmail.com]

On Sunday, May 24, 2020 at 9:44:22 PM UTC-7, Martin Blais wrote:

Just for fun I quickly added syntax for an optional time after the date but just for Transaction directives here:

https://github.com/beancount/beancount/tree/adding_time

Not even using it yet.

That's an 8.7% cost on the average run time.

That seems like a pretty big cost for just parsing timestamps which are only useful in a minority of situations.  While I am really impressed with it, Beancount's strength isn't exactly in its performance, so I'd hate to make it even slower unless there was high ROI.  I am sure others would find intra-day trading to be a nice benefit, but for me, sorting by line-number is sufficient.

[Martin Blais]

OTOH I can probably halve the time parsing takes (which is about half the total processing time on my ledger) if I just as much as rewrite some of the lexer and parser in C. The parser calls back to Python drivers in these two files:

https://github.com/beancount/beancount/blob/master/beancount/parser/lexer.py

https://github.com/beancount/beancount/blob/master/beancount/parser/grammar.py

This was great for iterating 5+ years ago but frankly now that the desired behavior has been teased out and gelled, it's probably fair to do that.

I'm resisting spending the time to do this right now because I'll be rewriting the whole parser with a re/flex scanner (UTF8 support) and parser generator in C++ in V3, with no Python code in that loop. This would involve introducing dependencies on the C++ language which brings a whole other set of issues, and purely C++ data structures (as protos), so I've postponed this for V3.