Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
close command shows wrong transaction price for multi-priced balances #1035
I'm unable to explain the output I'm getting from
I have journal entries where BTCs are purchased using total price (ie
finance $ grep -r -A2 "12/31 To BTC Savings" 2018-EUR.journal:2018/12/31 To BTC Savings ; category:general 2018-EUR.journal- Personal:Assets:Girokonto:Revolut:EUR -0,400000000 EUR = EUR78,71 2018-EUR.journal- Personal:Assets:Savings:Revolut:BTC 0,00011812 BTC @@ EUR0,40000000 -- 2018-EUR.journal:2018/12/31 To BTC Savings ; category:general 2018-EUR.journal- Personal:Assets:Girokonto:Revolut:EUR -7,200000000 EUR = EUR66,31 2018-EUR.journal- Personal:Assets:Savings:Revolut:BTC 0,00213894 BTC @@ EUR7,20000000
The hledger-derived unit prices of said BTC commodity look fine too:
finance $ hledger prices --costs BTC | grep 2018-12-31 P 2018-12-31 BTC EUR3386,38673 P 2018-12-31 BTC EUR3366,153328
I do not have any 'P' directives anywhere in my journals, and am simply relying on transaction prices for the commodity prices to be determined by hledger automatically.
It's when I run
finance $ hledger close -e 2019 --closing BTC 2019/06/03 closing balances Personal:Assets:Savings:Revolut:BTC -0,2140556 BTC @@ EUR0,10000000 = 0 BTC equity:closing balances finance $ hledger-ui --version hledger-ui 1.14.2
2019/06/03 closing balances Personal:Assets:Savings:Revolut:BTC -0,2140556 BTC @@ EUR720,543970317 = 0 BTC equity:closing balances
the manual section for hledger close does not say anything about how transaction prices are determined in
I pipe the output of the hledger close command to
$ hledger close -e 2019 BTC | sed -e "s#BTC @@ EUR.* = \(.*\) BTC#BTC = \1 BTC#g" 2018/12/31 closing balances Personal:Assets:Savings:Revolut:BTC -0,02269997 BTC = 0 BTC equity:closing balances 2019/01/01 opening balances Personal:Assets:Savings:Revolut:BTC 0,02269997 BTC = 0,02269997 BTC equity:opening balances
Great bug report and workaround - thanks. As you point out, the close command's handling of transaction prices is sloppy. If the sum contained multiple different transaction prices, it shows only the first and discards the rest.
What's the best behaviour I wonder ?
2 is what we do by default everywhere else, so I guess that's the answer.
This gives output like:
Stepping back, the first question is do we want to preserve the "lots" formed by transaction prices (and the more sophisticated lots we hope to support in future) across close/open transactions, and eg from one year's file to the next ? I think the answer must be yes.
(Note for #1022: this demonstrates how posting date and a lot's "acquisition date" can be different. Eg I acquire a lot on 2018-06-01, and start a new file in 2019, that lot appears in the 2019 journal via a 2019-01-01 opening balances posting.)
I agree that preserving the lots across close/open transactions is what makes the most sense.
It seems to me that whatever format one comes up with in #1022 for lot acquisition/deposit is what will eventually be used in
Here's an example of more correctly closing a multi-priced balance.
Until now, we have left the equity posting's balance blank, so that only one equity posting was needed. I tried adding the -x/--explicit flag to make this optional. But I think it's best to just always show it explicitly. If someone prefers the implicit form it's an easy manual edit.
Here's a more complex case that I found in the tests, updated for the new behaviour:
Let me know what you think.