Why am I getting the No position matches error?

Peter

unread,

Jan 4, 2021, 8:56:15 AM1/4/21

to Beancount

Hi,

having the following example file, I'm getting the error:

Test.bean:21: No position matches "Posting(account='Assets:Crypto:USDT:Binance', units=-0.43686294 USDT, cost=CostSpec(number_per=Decimal('0.83161458'), number_total=None, currency='EUR', date=None, label=None, merge=False), price=0.83161458 EUR, flag=None, meta={'filename': '/media/Daten/03-Finanzen/00-Beancount/Test.BTCUSDT2.bean', 'lineno': 28})" against balance (134.27435124 USDT {0.83159490 EUR, 2020-12-17})

File

option "booking_method" "FIFO"

option "operating_currency" "EUR"

plugin "beancount.plugins.auto_accounts"

2020-12-15 * "" "Trade BTCUSDT: SELL BTC for USDT"

Assets:Crypto:BTC:Binance 0.1 BTC {16000 EUR} @ 16000 EUR

Equity:Opening -0.1 BTC {16000 EUR} @ 16000 EUR

2020-12-17 * "" "Trade BTCUSDT: SELL BTC for USDT"

time: "08:50 "

orderId: "123456789-01"

Assets:Cash:Binance 111.77364000 EUR

Assets:Crypto:BTC:Binance -0.00600000 BTC {} @ 18628.94000000 EUR

Assets:Crypto:USDT:Binance 134.40876000 USDT {0.83159490 EUR} @ 0.83159490 EUR

Assets:Cash:Binance -111.77364000 EUR

Assets:Crypto:USDT:Binance -0.13440876 USDT {0.83159490 EUR} @ 0.83159490 EUR

Expenses:Commission:Binance 0.13440876 USDT @ 0.83159490 EUR

Income:Day-trading

2020-12-17 * "" "Trade BTCUSDT: SELL BTC for USDT"

time: "08:50 "

orderId: "123456789-02"

Assets:Cash:Binance 363.30158788 EUR

Assets:Crypto:BTC:Binance -0.01950200 BTC {} @ 18628.94000000 EUR

Assets:Crypto:USDT:Binance 436.86293686 USDT {0.83161458 EUR} @ 0.83161458 EUR

Assets:Cash:Binance -363.30158788 EUR

Assets:Crypto:USDT:Binance -0.43686294 USDT {0.83161458 EUR} @ 0.83161458 EUR

Expenses:Commission:Binance 0.43686294 USDT @ 0.83161458 EUR

Income:Day-trading

I can't figure out why I'm gettig the error because the transaction is basically the same as the first one. And the first transaction parses without error.

Furthermore, if I "split" the second transaction and move the commission expenses into a seperate transaction, I'm getting no error:

option "booking_method" "FIFO"

option "operating_currency" "EUR"

plugin "beancount.plugins.auto_accounts"

2020-12-15 * "" "Trade BTCUSDT: SELL BTC for USDT"

Assets:Crypto:BTC:Binance 0.1 BTC {16000 EUR} @ 16000 EUR

Equity:Opening -0.1 BTC {16000 EUR} @ 16000 EUR

2020-12-17 * "" "Trade BTCUSDT: SELL BTC for USDT"

time: "08:50 "

orderId: "123456789-01"

Assets:Cash:Binance 111.77364000 EUR

Assets:Crypto:BTC:Binance -0.00600000 BTC {} @ 18628.94000000 EUR

Assets:Crypto:USDT:Binance 134.40876000 USDT {0.83159490 EUR} @ 0.83159490 EUR

Assets:Cash:Binance -111.77364000 EUR

Assets:Crypto:USDT:Binance -0.13440876 USDT {0.83159490 EUR} @ 0.83159490 EUR

Expenses:Commission:Binance 0.13440876 USDT @ 0.83159490 EUR

Income:Day-trading

2020-12-17 * "" "Trade BTCUSDT: SELL BTC for USDT"

time: "08:50 "

orderId: "123456789-02"

Assets:Cash:Binance 363.30158788 EUR

Assets:Crypto:BTC:Binance -0.01950200 BTC {} @ 18628.94000000 EUR

Assets:Crypto:USDT:Binance 436.86293686 USDT {0.83161458 EUR} @ 0.83161458 EUR

Assets:Cash:Binance -363.30158788 EUR

; Assets:Crypto:USDT:Binance -0.43686294 USDT {0.83161458 EUR} @ 0.83161458 EUR

; Expenses:Commission:Binance 0.43686294 USDT @ 0.83161458 EUR

Income:Day-trading

2020-12-17 * "" "Trade BTCUSDT: SELL BTC for USDT"

Assets:Crypto:USDT:Binance -0.43686294 USDT {0.83161458 EUR} @ 0.83161458 EUR

Expenses:Commission:Binance 0.43686294 USDT @ 0.83161458 EUR

What am I doing wrong in the second transaction that beancount can't figure out the correspoding lot?

Regards

Martin Blais

unread,

Jan 4, 2021, 9:15:37 AM1/4/21

to Beancount

The context command will not work on the last txn because of the way errors are handled right now (will be fixed in v3 with parser changes), but you can get context on the prior transaction to see the remaining inventory's balances which are going to be the input to the last transaction to match against.

bean-doctor context btc2.beancount 17
Hash:64d489e8797bf562fdc15f7a890fe5e5
Location: /home/blais/r/q/beancount-data/user/tobiash/btc2.beancount:10

------------ Balances before transaction

Assets:Crypto:BTC:Binance 0.1 BTC {16000 EUR, 2020-12-15}

Assets:Cash:Binance

Assets:Crypto:USDT:Binance

Expenses:Commission:Binance

Income:Day-trading

------------ Transaction

2020-12-17 * "Trade BTCUSDT: SELL BTC for USDT"

orderId: "123456789-01"
time: "08:50 "
Assets:Cash:Binance 111.77364000 EUR ; 111.77364000 EUR
Assets:Crypto:BTC:Binance -0.00600000 BTC {16000.00000000 EUR, 2020-12-15} @ 18628.94000000 EUR ; -96.00000000 EUR
Assets:Crypto:USDT:Binance 134.40876000 USDT {0.83159490 EUR, 2020-12-17} @ 0.83159490 EUR ; 111.7736393313240000 EUR
Assets:Cash:Binance -111.77364000 EUR ; -111.77364000 EUR
Assets:Crypto:USDT:Binance -0.13440876 USDT {0.83159490 EUR, 2020-12-17} @ 0.83159490 EUR ; -0.1117736393313240 EUR
Expenses:Commission:Binance 0.13440876 USDT @ 0.83159490 EUR ; 0.1117736393313240 EUR
Income:Day-trading -15.77363933 EUR ; -15.77363933 EUR

Residual: (0.0000000013240000 EUR)
Tolerances: BTC=5E-9, EUR=5E-9, USDT=5E-9
Basis: (15.6618656919926760 EUR)

------------ Balances after transaction

* Assets:Crypto:BTC:Binance 0.09400000 BTC {16000 EUR, 2020-12-15}

Assets:Cash:Binance

* Assets:Crypto:USDT:Binance 134.27435124 USDT {0.83159490 EUR, 2020-12-17}

* Expenses:Commission:Binance 0.13440876 USDT

* Income:Day-trading -15.77363933 EUR

--
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/aa5b7b54-9bd1-4308-b872-7d3e52b1ef71n%40googlegroups.com.

Peter

unread,

Jan 4, 2021, 10:40:31 AM1/4/21

to Beancount

To be frank, I think I don't fully understand your reply to the problem.

The context of the first transaction is just fine, yes.

The only USDT lot in the Assets:Crypto:USDT:Binance account is reduced by the 0.134… USDT and expenses are correctly set.

But it's not just about bean-context/the context of the first txn. I imported several transactions of this "type".

This "breaks" the whole file (I'm getting a "bazillion" errors of this type) and thus a proper calculation of PnL and remaining lots, etc — or am I mistaken?

I don't understand why beancount isn't able to find the lot in the second txn. I mean, it did find the right one in the first txn?

Isn't there anything I could do? Except separating the txn into an "actual txn" and fee txn?

Having to rewrite all of the txn to separate the actual transaction and the fees would be cumbersome and I really dislike the idea to have separated trade and fee expense transactions.

Regards

Martin Blais

unread,

Jan 4, 2021, 11:37:10 AM1/4/21

to Beancount

On Mon, Jan 4, 2021 at 10:40 AM Peter <tobias....@gmail.com> wrote:

To be frank, I think I don't fully understand your reply to the problem.

Just showing how to debug the issue.

The context of the first transaction is just fine, yes.
The only USDT lot in the Assets:Crypto:USDT:Binance account is reduced by the 0.134… USDT and expenses are correctly set.

These are the changes you're applying to that account:

Assets:Crypto:USDT:Binance 134.40876000 USDT {0.83159490 EUR} @ 0.83159490 EUR

Assets:Crypto:USDT:Binance -0.13440876 USDT {0.83159490 EUR} @ 0.83159490 EUR

Assets:Crypto:USDT:Binance 436.86293686 USDT {0.83161458 EUR} @ 0.83161458 EUR

Assets:Crypto:USDT:Binance -0.43686294 USDT {0.83161458 EUR} @ 0.83161458 EUR

The problem is a subtle issue with self-reductions (reductions of a position added within the transaction itself).

Reductions are applied on the inventories before the transaction, and not in order.

It's a very long explanation why in the general case it's not trivial to just apply them within the transaction, but I think that's the problem, the 4th posting is attempting to reduce the inventory resulting from the first two, it doesn't see the 3rd one.

I'd like to come up with a better (and still general) booking algorithm in v3, which handles this.

But it's not just about bean-context/the context of the first txn. I imported several transactions of this "type".
This "breaks" the whole file (I'm getting a "bazillion" errors of this type) and thus a proper calculation of PnL and remaining lots, etc — or am I mistaken?

Yes if you do the same everywhere you'll encounter the same issue

I don't understand why beancount isn't able to find the lot in the second txn. I mean, it did find the right one in the first txn?

Isn't there anything I could do? Except separating the txn into an "actual txn" and fee txn?
Having to rewrite all of the txn to separate the actual transaction and the fees would be cumbersome and I really dislike the idea to have separated trade and fee expense transactions.

Not sure I have a great solution for you right now

Wait for v3

Or split them

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/67084077-9fca-4135-9edc-a13985fd36can%40googlegroups.com.

Martin Blais

unread,

Jan 4, 2021, 11:39:36 AM1/4/21

to Martin Blais, Beancount

https://github.com/beancount/beancount/issues/602

Peter

unread,

Jan 4, 2021, 12:35:56 PM1/4/21

to Beancount

Thanks for the extended answer (and your outstanding support in general). It really helps understanding the issue.

Read a couple times about v3 yet. I'm kinda excited about it. As it seems you just started this sommer, I guess there'll be some time, until it gets released? Do you have a timeplan/roadmap?

Martin Blais

unread,

Jan 4, 2021, 1:27:18 PM1/4/21

to Beancount

On Mon, Jan 4, 2021 at 12:36 PM Peter <tobias....@gmail.com> wrote:

Thanks for the extended answer (and your outstanding support in general). It really helps understanding the issue.

I was just remembering now: the difficulties in designing this occurs when there's matching and/or interpolation required, e.g. when some numbers are left to be filled in by Beancount, or when lots are to be deduced automatically. Imagine your transaction with some numbers left to be interpolated... not all cases are obvious to resolve. In the fully specified case, as you have it (all numbers and currencies are present), it should be doable, though it would result in as many rounds of matchings as postings (right now matching is done once per transaction). I think something can be done in the future, but will require a bunch of testing and thinking about this, and performance will be less of a concern (it'll all be done in C++).

Read a couple times about v3 yet. I'm kinda excited about it. As it seems you just started this sommer, I guess there'll be some time, until it gets released? Do you have a timeplan/roadmap?

Don't know. I do this on my off time, progress happens in spurts. Usually the holidays are when things move because it allows me to get my head out of work. But I'm excited to make this rewrite happen now because I'm finding it painfully slow to work with, and I have a bunch of accumulated ideas for fixing all the loose ends (e.g. not dealing with precision correctly). I'm also reducing the scope of the core repo itself, so hopefully it should allow me to get more active again without getting lost on sidelines, e.g. importer stuff, price sources, web view, etc. (these last few years it was too big and time consuming to make changes, so I was reluctant to evolve big changes). And contributions are growing, so that will help. FWIW, the pure C++ parser is almost finished, and I'm keeping track of changes from v2 here:

http://furius.ca/beancount/doc/v3-changes

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/f387cb35-43c5-48c8-943a-bf905cc58f0bn%40googlegroups.com.

Reply all

Reply to author

Forward