Generate conversion postings for priced amounts.

[Xitian9]

A potential implementation of the proposals in #1177. This is almost certainly not the final behaviour, but I'm putting this up to solicit feedback on a solid proposal. Let me know your thoughts!

This means there will no longer be unbalanced transactions, but will be
offsetting conversion postings to balance things out. For example.

2000-01-01
  a   1 AAA @@ 2 BBB
  b  -2 BBB

When converting to cost, this is treated the same as before.
When not converting to cost, this is now treated as:

2000-01-01
  a                           1 AAA
  b                          -2 BBB
  equity:conversion:AAA:BBB  -1 AAA
  equity:conversion:BBB:AAA   2 BBB

[Xitian9]

Showing conversion postings with --explicit seems reasonable too, but if we have a separate flag we probably want to keep those orthogonal.

[Xitian9]

We used to have just two cost modes – Cost and NoCost – in which case a flag was sufficient. We now have three – Cost, NoCost, and ConversionCost. The flag --cost will still access Cost mode, but there is no way to select between NoCost and ConversionCost. NoCost is used by print and close and ConversionCost is used by all other commands. I think we need more fine-grained control, for example --cost=cost/--cost, --cost=conversion, or --cost=nocost.

Any thoughts on this proposal?

[simonmichael]

I think it needs draft docs ? That would help me assess it.

[Xitian9]

I've added the enhanced --cost option, some tests, and docs in a new commit. Let me know what you think.

[simonmichael]

Maybe this would be better as a separate flag ? I think it's not variations of how to calculate cost, but rather a choice of whether to generate and show conversion postings, independent of whether reporting cost or not ?

[simonmichael]

From trying to write feedback, I see this is a complex topic, such that I think we need to flesh out the specification/draft doc, here on this issue because #1177 is huge. Apologies if I have forgotten past discussion/context. It looks like my last coherent thoughts on this were here. Am I right in thinking this PR is aimed at the second bullet point ("Let's implement conversion rate inference from a balanced @-free transaction - it seems possible and would allow -B and --infer-value to work without the need for @ notation") ?

[simonmichael]

No, I think that was not right; this PR doesn't address that bullet point.

Instead I think it aims to help people who are using @ notation, or implicit @ (autoconversion), to produce reports where the equity balance is correct and the accounting equation can balance (by generating the required equity postings where they are missing).

Would that be accurate ? Let's nail down

Goals:
User-visible changes:
Impact/compatibility:
Interactions:

[Xitian9]

Instead I think it aims to help people who are using @ notation, or implicit @ (autoconversion), to produce reports where the equity balance is correct and the accounting equation can balance (by generating the required equity postings where they are missing).

Would that be accurate ?

Yes, that's correct. Current behaviour without -B/--cost will generate unbalanced postings; this automatically generates equity postings so that @/@@ transactions are balanced.

Let's nail down

Goals: User-visible changes: Impact/compatibility: Interactions:

Goals:

• Transactions involving transaction prices can be balanced (preferably by default or by explicit choice)
• Users can continue to get previous --cost behaviour if desired
• Users can get previous unbalanced transactions if desired (for simplicity)

Impact/compatibility:

• If default behaviour is changed then there will be extra postings generated. They will be in special equity accounts, so this should cause minimal interference.
• If default behaviour is not changed, then there should be no noticeable effect without explicitly calling for it.

Interactions:

• None currently seen, as we have to deal with costing anyway. Perhaps some weird interaction with --gain that I'm not thinking of.

[Xitian9]

Maybe this would be better as a separate flag ? I think it's not variations of how to calculate cost, but rather a choice of whether to generate and show conversion postings, independent of whether reporting cost or not ?

I think this is not quite correct. If we're reporting cost, then generating conversion postings will make transactions unbalanced, exactly the problem we were trying to avoid.

I think the following are things that could (conceivably) be done:

2021-11-26  Test
    assets:stock    1 stock @ 1 EUR
    assets:cash    -1 EUR

1. Do not use transaction cost. Currently the default. This creates unbalanced transactions.

$ hledger register
2021-11-26 Test                 assets:stock               1 stock       1 stock
                                assets:cash                 -1 EUR        -1 EUR
                                                                         1 stock

$ hledger print
2021-11-26 Test
    assets:stock    1 stock @ 1 EUR
    assets:cash              -1 EUR

2. Do not use transaction cost, and generate conversion postings. The above, but transactions are balanced.

$ hledger register
2021-11-26 Test                 assets:stock               1 stock       1 stock
                                eq:co:stock:EUR           -1 stock             0
                                eq:co:EUR:stock              1 EUR         1 EUR
                                assets:cash                 -1 EUR             0

$ hledger print
2021-11-26 Test
    assets:stock                        1 stock
    equity:conversion:stock:EUR        -1 stock  ; generated-posting:
    equity:conversion:EUR:stock           1 EUR  ; generated-posting:
    assets:cash                          -1 EUR

3. Use transaction cost. Currently available with --cost. This creates balanced transactions.

$ hledger register
2021-11-26 Test                 assets:stock                 1 EUR         1 EUR
                                assets:cash                 -1 EUR             0

$ hledger print
2021-11-26 Test
    assets:stock           1 EUR
    assets:cash           -1 EUR

4. Use transaction cost, but generate conversion postings. This creates unbalanced transactions. An affront to nature. Begs for death.

$ hledger register
2021-11-26 Test                 assets:stock               1 EUR       1 EUR
                                eq:co:stock:EUR         -1 stock       1 EUR
                                                                    -1 stock
                                eq:co:EUR:stock            1 EUR       2 EUR
                                                                    -1 stock
                                assets:cash               -1 EUR       1 EUR
                                                                    -1 stock

$ hledger print
2021-11-26 Test
    assets:stock                          1 EUR
    equity:conversion:stock:EUR        -1 stock  ; generated-posting:
    equity:conversion:EUR:stock           1 EUR  ; generated-posting:
    assets:cash                          -1 EUR

The way I see it, 2 and 3 make the most sense. 2 should be default, 3 is a common need. 1 makes sense for the print command, and since it's both simpler and longstanding default should be maintained for those who want it. 4 does not make sense.

[simonmichael]

I have posted an attempted summary of this proposal, with some open questions, at https://hledger.org/conversion2.html#xitians-1554 .

[simonmichael]

See #hledger chat log for much other discussion. Now in master - thanks a lot @Xitian9 !