Why does this balance?

123 views
Skip to first unread message

Thomas den Hollander

unread,
Jan 29, 2022, 1:35:58 PM1/29/22
to Beancount
I have a question. It is either something I don't understand about the cost system or a bug. Why does the following code snippet balance?

2022-01-29 commodity COINA
2022-01-29 commodity COINB

2022-01-29 open Income:Other
2022-01-29 open Assets:CoinA COINA
2022-01-29 open Assets:CoinB COINB

2022-01-29 * "Income"
  Income:Other                         -100.00 EUR
  Assets:CoinA                            1.00 COINA {# 100.00 EUR}
 
2022-01-29 * "Convert"
  ; Why does this transaction balance?
  Assets:CoinA                           -1.00 COINA {# 100.00 EUR}
  Assets:CoinB                            2.00 COINB {# 200.00 EUR}

Shouldn't the transaction give -100.00 + 200.00 = 100.00 != 0?

Alan H

unread,
Jan 29, 2022, 4:10:15 PM1/29/22
to Beancount
I'm not familiar with the # 100.00 EUR syntax that you are using; but running bean-report {file} print shows how this is being interpreted and this might help:

$ bean-report foo.bean print

2022-01-29 open Income:Other
2022-01-29 open Assets:CoinA                                    COINA
2022-01-29 open Assets:CoinB                                    COINB

2022-01-29 commodity COINA

2022-01-29 commodity COINB

2022-01-29 * "Income"
  Income:Other  -100.00 EUR
  Assets:CoinA     1.00 COINA {100 EUR, 2022-01-29}

2022-01-29 * "Convert"
  Assets:CoinA  -1.00 COINA {100 EUR, 2022-01-29}
  Assets:CoinB   2.00 COINB {50 EUR, 2022-01-29}

I tried to run bean-doctor parser to see how this was being parsed but it throws errors in the yacc/lex interface. (Likely code rot)

I suspect you might be looking for the '@' syntax for cost specifications?

Hope this helps
Alan

Martin Blais

unread,
Jan 29, 2022, 7:21:59 PM1/29/22
to Beancount
Looks a bug to me.
I think your interpretation is correct.


--
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/7d06d7e7-c000-42cf-ae5d-1b67beba69d0n%40googlegroups.com.

Martin Blais

unread,
Jan 29, 2022, 7:27:56 PM1/29/22
to Beancount
Oh wow... it's subtle:

2022-01-29 * "Income"
  Income:Other  -100.00 EUR
  Assets:CoinA     1.00 COINA {100 EUR, 2022-01-29}

2022-01-29 * "Convert"
  Assets:CoinA  -1.00 COINA {100 EUR, 2022-01-29}
^^^ here this gets matched against 1.00 COINA in the Assets:CoinA account, and so resolved against that posting.

  Assets:CoinB   2.00 COINB {50 EUR, 2022-01-29}
^^^ here this has a degree of freedom in the per-unit cost, and that gets filled in to -100, in order to balance with the other posting in the transaction.

Behavior is as expected, but admittedly confusing.
Remember:
- reducing (closing) transactions will be matched against existing inventory
- augmenting (opening) transactions will be interpolated when necessary.



Hawrylyshen, Alan

unread,
Jan 29, 2022, 8:29:23 PM1/29/22
to bean...@googlegroups.com
Martin; Is there a pointer to the cost spec that includes / explains the '#' notation. I will admit I didn't find it.
Alan

You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/majra9X_W_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhMaBo-Ye4riOLjxfcsgekPxsWyYDe-3srKK2YU8Y8pYCQ%40mail.gmail.com.


--
a l a n a t p o l y p h a s e d o t c a

Thomas den Hollander

unread,
Jan 30, 2022, 3:55:35 AM1/30/22
to Beancount
Thank you both.

> has a degree of freedom in the per-unit cost

I'm afraid I don't see how it still has a degree of freedom. Isn't the unit cost determined via total_cost / units? Can interpolation overwrite existing entries? Or doesn't units * unit_cost = total_cost have to hold?
Op zondag 30 januari 2022 om 02:29:23 UTC+1 schreef Alan H:

Thomas den Hollander

unread,
Jan 30, 2022, 4:01:13 AM1/30/22
to Beancount
Oh, by the way. It isn't an answer to your question exactly, but the syntax gets generated by beangulp, which in turn uses beancount.parser.printer.


Op zondag 30 januari 2022 om 02:29:23 UTC+1 schreef Alan H:
Martin; Is there a pointer to the cost spec that includes / explains the '#' notation. I will admit I didn't find it.
Alan

Martin Blais

unread,
Jan 30, 2022, 10:31:15 AM1/30/22
to Beancount
On Sun, Jan 30, 2022 at 3:55 AM Thomas den Hollander <denhollan...@gmail.com> wrote:
Thank you both.

> has a degree of freedom in the per-unit cost

I'm afraid I don't see how it still has a degree of freedom. Isn't the unit cost determined via total_cost / units? Can interpolation overwrite existing entries? Or doesn't units * unit_cost = total_cost have to hold?

I think {# 200.00 EUR} is interpreted as {? # 200.00 EUR} and not as {0.00 # 200.00 EUR}

 

Hawrylyshen, Alan

unread,
Jan 30, 2022, 4:50:51 PM1/30/22
to bean...@googlegroups.com
I realise now that my confusion stems from still living in v2 land. :-)

(Note to self : check 'main' before assuming things)

A

Thomas den Hollander

unread,
Feb 2, 2022, 10:50:10 AM2/2/22
to Beancount
I now realized that using `{{}}` does throw the error I expected when `{# }` does not.

Is this a bug? If so, I could try to fix this if you want. Do you know where this may go wrong?
Op zondag 30 januari 2022 om 22:50:51 UTC+1 schreef Alan H:
Reply all
Reply to author
Forward
0 new messages