bug(?) in hledger 1.33 around commodity conversions [vs. 1.30]

[Will Robinson]

Hi all,

In switching laptops, I'm bumping up from hledger 1.30 on the previous to hledger 1.33 on the new.

Sadly, my ledger file that runs cleanly through 1.30 now produces an error in 1.33. I've gotten the offending bit into a minimal test case below... If I put this into "tmp.journal" and then run "hledger -f tmp.journal bs" then it works as expected in 1.30, but gives an error[1] in 1.33:

2023-09-26 Test
        assets:myaccount  -10 A @@ $10.00
        assets:myaccount  10 B @@ $10.00
        equity:conversion:$-A:A  10 A
        equity:conversion:$-A:$  -$10.00
        equity:conversion:$-B:B  -10 B
        equity:conversion:$-B:$  $10.00

I played with some details, and the error condition is very finicky! For example, if I change all the $ amounts from 10.00 to 20.00 (while leaving the A and B commodities at 10), then everything works fine.

[1] - Error message below:

1 | 2023-09-26 Test
  |     assets:myaccount           -10 A @@ $10.00
  |     assets:myaccount            10 B @@ $10.00
  |     equity:conversion:$-A:A               10 A
  |     equity:conversion:$-A:$            $-10.00
  |     equity:conversion:$-B:B              -10 B
  |     equity:conversion:$-B:$             $10.00

This multi-commodity transaction is unbalanced.
The real postings' sum should be 0 but is: 10 A, -10 B
Consider adjusting this entry's amounts, adding missing postings,
or recording conversion price(s) with @, @@ or equity postings.

--

Will Robinson (willro...@gmail.com)

[Simon Michael]

On 2024-04-26 12:15, Will Robinson wrote:
> Hi all,
>
> In switching laptops, I'm bumping up from hledger 1.30 on the previous
> to hledger 1.33 on the new.
>
> Sadly, my ledger file that runs cleanly through 1.30 now produces an
> error in 1.33. I've gotten the offending bit into a minimal test case
> below... If I put this into "tmp.journal" and then run "hledger -f
> tmp.journal bs" then it works as expected in 1.30, but gives an error[1]
> in 1.33:
>
> 2023-09-26 Test
>         assets:myaccount  -10 A @@ $10.00
>         assets:myaccount  10 B @@ $10.00
>         equity:conversion:$-A:A  10 A
>         equity:conversion:$-A:$  -$10.00
>         equity:conversion:$-B:B  -10 B
>         equity:conversion:$-B:$  $10.00

Thanks for the repro.

This is an odd transaction to me. It kind of makes sense, but I'm not
sure I've ever done that - a conversion involving three commodities in
one transaction.

I suspect the builtin autodetection of equity conversion postings is not
designed for it. Here are the
https://hledger.org/dev/hledger.html#requirements-for-detecting-equity-conversion-postings
. These apply when using --infer-costs, and also when hledger is
balancing a transaction like the above (? IIRC).

hledger 1.29-1.30 seem to accept this entry, as you say. I wonder if
they are interpreting it correctly ?

[Will Robinson]

They seem to be working correctly in 1.30. FWIW, I have a lot of transactions like these for converting one crypto asset to another. All conversion accounts route through dollars since my capital gains are recorded and taxed in dollars. It was a bit clunky to get the pattern down at first, but it feels like second nature to me now and I use it all the time....

--
You received this message because you are subscribed to the Google Groups "hledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/9517ec8d-054f-4ca8-befa-82e246d6c9fd%40joyful.com.

[Simon Michael]

It's interesting. Here is the simpler variant without the equity postings:

2023-09-26 Test
assets:myaccount -10 A @@ $10

assets:myaccount 10 B @@ $10

I don't think I've ever used one of these either. But it works in all
versions, and hledger can infer the equity postings too:

$ hledger-1.33 print --infer-equity

2023-09-26 Test
assets:myaccount -10 A @@ $10

equity:conversion:$-A:A 10 A

equity:conversion:$-A:$ $-10

assets:myaccount 10 B @@ $10

equity:conversion:$-B:B -10 B
equity:conversion:$-B:$ $10

(equivalent to your original example).

[Simon Michael]

PS I can't even say at this moment if the original example is balanced
according to hledger's transaction balancing rules. I guess it is,
allowing the @@ costs to be redundant ?

If so, if anyone would like to investigate how to detect it as balanced,
Hledger.Data.Balancing.transactionCheckBalanced is the place.

[the.so...@gmail.com]

1. This only seems to happen when `@@` are used.  This (more traditional) transaction is fine, for instance:

```

2023-09-26 Test
    assets:myaccount                   10 B

    equity:conversion:$-B:B           -10 B
    equity:conversion:$-B:$             $10

    assets:myaccount                  -10 A

    equity:conversion:$-A:A            10 A
    equity:conversion:$-A:$            $-10

```

The trouble seems to be that the logic (correctly, one could argue) infers that this means that A was traded for B:

```
2023-09-26 Test
    assets:myaccount            10 B @@ 10 A

    equity:conversion:$-B:B            -10 B
    equity:conversion:$-B:$              $10

    assets:myaccount           -10 A @@ 10 B

    equity:conversion:$-A:A             10 A
    equity:conversion:$-A:$             $-10

```

But instead in Will's test transaction the `@@` notes the price in $.

```

2023-09-26 Test

    assets:myaccount            10 B @@ $10
    equity:conversion:$-B:B            -10 B
    equity:conversion:$-B:$              $10
    assets:myaccount           -10 A @@ $10
    equity:conversion:$-A:A             10 A
    equity:conversion:$-A:$             $-10

```

The solution could be to simply remove the @@ and the text that follows:

sed 's/@@.*//' /tmp/test.j

Combining @@ notation with equity:conversion accounts in the journal itself isn't useful.  When you need to use an option like `--gain`, just use `--infer-costs` along with it, and hledger will work its magic.

~ Pranesh

[Will Robinson]

Hey Pranesh,

Thanks for looking into this. In general, I do find the @@ with conversion accounts very useful. The entry causing a problem here is a degenerate case (trading one stablecoin for another, both with values pegged to $1). But in general my entries look more like this:

2023-09-26 Test
        assets:myaccount  -10 A @@ $9.00
        assets:myaccount  10 B @@ $10.00

        equity:conversion:$-A:A  10 A

        equity:conversion:$-A:$  -$9.00

        equity:conversion:$-B:B  -10 B

        equity:conversion:$-B:$  $10.00
        revenues:capitalgain  -$1.00

...where the @@ $9.00 in the first row captures the original cost basis for the A asset we're now disposing of; it's being traded for a B asset worth $10 at current market rates, and we thus are realizing a $1 capital gain today. I am parsing this information from a separate crypto tax-tracking package that is doing all the hard work of determining HIFO sale lots across wallets, etc. etc. This pattern captures the intent accurately, ensures that my overall realized capital gains/losses within hledger reconcile correctly with the tax software's own computations, etc. I would also argue that since the entry above parses cleanly in both hledger 1.30 and hledger 1.33, this is the expected functionality, and some principle of uniformity argues that it shouldn't break if the top line happens to be @@ $10.00, and the capitalgain line happens to be $0.00.

Pushing a step further, in the original test case, the accounting equation is actually balanced! (There is a -10A, a +10A, a -10B, a +10B, a -10$, and a +10$). So it seems that the 1.33 behavior is unintuitive at least (and I would argue buggy).

Last but not least, the fact that I can change all the $10.00 entries in my breaking example to $20.00 entries (while leaving the A and B entries untouched) and it works ... .again, very unintuitive behavior. By Pranesh's logic, that should be just as likely to "infer that A was tradeed for B" and so should fail in the same way ... but it does not.

The problem seems to be the specific matching of the "10" causing some conflation of different commodities in 1.33, where it did not in 1.30 and prior versions. [Haven't checked versions between 1.30 and 1.33].

Will

--
You received this message because you are subscribed to the Google Groups "hledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/9a116dd2-df87-4305-a780-5914c09e3208n%40googlegroups.com.

--

Will Robinson (willro...@gmail.com)