On Wed, May 13, 2020 at 8:37 AM <[email protected]> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beancount/ffdfa295-e7ae-4efc-bbab-4e412a6a7aff%40googlegroups.com
> <https://groups.google.com/d/msgid/beancount/ffdfa295-e7ae-4efc-bbab-4e412a6a7aff%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/CAK21%2BhOLgu4cfRBOAJZvaUuXpM0a67VRvxAAkW86wMbGErsMBQ%40mail.gmail.com.
