I would consider implementing this differently. The price exposed on the statement is *not* the price - or, perhaps not always, depending on the broker. It is an *approximation* of the price, sometimes not even significant to the the point that it prints. Vanguard, for instance, on some of my accounts (I think my 529), reports prices at 4 decimal points, but rounds it to 3 with a trailing 0, while I can get the 'more correct' price online. I've also seen different rounding prices in CSV vs OFX exports from the same statements, and I've seen different conventions where trailing 0's are dropped only when correct vs rounding - leading to strict Decimal tolerance issues. But even if all those were solved for, it's not actually the "price.'' When they calculate gains etc, they use whatever they use in the backend - probably to more significant digits than what is exposed.
Most brokers *store *either 4 (common) or 6 (becoming common?) decimal points -- in the US at least -- and *expose *anywhere between 2 and the full number of decimals varyingly on the web, in their pdf statements, on ofx, and on csv. So while it’s true in principle that we users may or may not be able to import the full precision as stored, in practice I’ve found using the price *as exposed* by the brokerage works very well because a) they are consistent and tend to match on both ends, and b) the rounding errors that come from the store/expose delta is too low to matter. Of course, YMMV. That’s for prices. Quantities are a different story. I only do automatic lot specification so I'm not sure on the best approach to suggest, but I would presume your concerns are also easier to address by specifying date or label of a lot rather than a price, and let the more accurate price calculations run through. It doesn’t work when one has multiple transactions on the same day, and one doesn’t want to use labels (automation complexity, portability). BTW, given the 4/6 storage, price calculations using @@ typically end up with many more decimal points, and are arguably less accurate in that they don’t match how your brokerage stores it. This might matter more from a purity standpoint though, and not in practice. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/beancount/39db21f7-f523-49d1-89c7-c21ea8785fb8n%40googlegroups.com.
