Order dependence of transfers

[Eric Altendorf]

I know in general the order of records in a beancount input file doesn't matter, but if I have an asset acquisition and a transfer of that asset later on the same day, things get confused if the transfer record appears first.

E.g., this works:

2020-01-01 pad      Assets:BrokerA:USD  Equity:Opening-Balances
2020-01-02 balance  Assets:BrokerA:USD  100.00 USD

2020-02-01 * "Buy some ASSET"
  Assets:BrokerA:ASSET                  10.00 ASSET {10.00 USD}
  Assets:BrokerA:USD                  -100.00 USD

2020-02-01 * "Transfer ASSET"
  Assets:BrokerA:ASSET                  -5.00 ASSET {USD}
  Assets:BrokerB:ASSET                   5.00 ASSET {USD}

(using the "{USD}" cost marker workaround to transfer cost basis)

However, if I reverse the order of the two records, I get the error:

  Too many missing numbers for currency group 'USD'

and if I remove the {USD} cost markers on the transfer, I get the booking error:

  No position matches "Posting(account='Assets:BrokerA:ASSET', units=10.00 ASSET, cost=CostSpec(number_per=Decimal('10.00'), number_total=None, currency='USD', date=None, label=None, merge=False), price=None, flag=None, meta={...})" against balance (-5.00 ASSET)

I've seen some discussion of these errors in the context of tracking cost basis among transfers, but I don't fully understand where things are at.

Brainstorming workarounds:

- hack the physical ordering to respect original tx timestamps

- artificially book transfers a day late (but that will break if there are further actions on that asset on the same day as the actual transfer)

- ....?

thanks,

eric

[Daniele Nicolodi]

On 21/07/23 07:24, Eric Altendorf wrote:
> I know in general the order of records in a beancount input file doesn't
> matter

It does not matter in the sense that directives are processed in date
order and not in the order in which they appear in the ledger.
Directives with the same date are processed in the order in which they
appear in the ledger. For the details, you can refer to the function
deriving the sorting key:
https://github.com/beancount/beancount/blob/193645460fd7aafcb3d9e0359edabc21e389db81/beancount/core/data.py#L647-L658

I think that what you observe is completely explained by this.

> Brainstorming workarounds:
> - hack the physical ordering to respect original tx timestamps

That's the way to go, IMO.

> - artificially book transfers a day late (but that will break if there
> are further actions on that asset on the same day as the actual transfer)

This is required if what throws the booking algorithm out is the
ordering of directives of different type with the same date. If you are
dealing only with transactions, this is not necessary (and as you point
out, may result in a cascade of date shifts).

Cheers,
Dan