Importers should be able to output postings with @@

[blais]

Original report by Kamal Marhubi (Bitbucket: kamalmarhubi, GitHub: kamalmarhubi).

---

When importing foreign currency transactions from my credit card, I am extracting the foreign currency price from the memo, eg 137.00 USD @@ 156.22 CAD. I'm trying to automate this with an importer.

As near as I can tell, this is currently impossible. The parser discards this info, and it is not explicit anywhere in the internals. If I compute the price in the importer, it spits out postings with a really ugly precision in the price.

Ideally, I could import them as I have the data available in the source.

[blais]

Original comment by Kamal Marhubi (Bitbucket: kamalmarhubi, GitHub: kamalmarhubi).

---

@blais If you're willing to accept it, I could take a crack at API changes to allow this. Let me know!

[blais]

Original comment by Zhuoyun Wei (Bitbucket: wzyboy, GitHub: wzyboy).

---

There is a related discussion about this: https://bitbucket.org/blais/beancount/issues/194/use-of-syntax-was-use-of-float-numbers-in

Beancount currently does not record the numerator and denominator of the exchange rate, just the rate itself. So internally @@ and @ are the same thing.

[blais]

Original comment by Kamal Marhubi (Bitbucket: kamalmarhubi, GitHub: kamalmarhubi).

---

I should have said I had seen that issue. To be clear here, I'm not proposing changing he internal behaviour, just the structure that importers return, and the ingest module prints out. The changes would be scoped to just the ingest module; actual computation would be done as it is now.

[blais]

Original comment by Martin Blais (Bitbucket: blais, GitHub: blais).

---

I'm quite opposed to changing the representation of Posting in beancount.core to an ambiguous representation (e.g. two fields: per-unit and total); however, here's a fun idea (see other thread): Just for the purpose of rendering, the rendering code could probe the posting's metadata, and if some total price has been attached there and its value is very close -- to some epsilon as a f(precision), which could be computed automatically -- to that of the computed one, it could use it to render a @@. Its treatment should be optional.

I think that change should be harmless to the rest of the code, and if well documented could be used to render @@ for importers.

[blais]

Original comment by droogmic (Bitbucket: Michael Droogleever, GitHub: droogmic).

---

Further discussion can be found in beancount/beancount#194 and then a rejected implementation in pull request beancount/beancount#42

[blais]

This will require v3's ability to run booking on individual transaction, and will be made possible by that.