Mutual fund prices precision

[Mike Alexander]

--On August 3, 2015 at 4:42:08 PM -0700 AC <gnucash at acarver.net> wrote:

> No, it's a correct assumption.  If I type a number in I expect that
> number to stay the same.  If I type 1.234 which came from a piece of
> paper, then both GC and my piece of paper should say 1.234 no more no
> less.

That's not really true.  You have three numbers, call them A, B, and C, 
such that A must equal B*C.  If you type values for A, B, and C such 
that this isn't true then either GnuCash must reject the transaction or 
it must adjust one of the numbers.  It does the latter, after perhaps 
asking you which one to adjust.  A is total cost of the shares, B is 
the price, and C is the number of shares.

> That is true except that the total price in GC is artificially reduced
> to two decimals which is inducing rounding errors on its own.  The
> funds do not trade with precision higher than three decimal places in
> the number of shares or price per share (verified with a broker).
> The final rounding is in the final price.  So to get the shares and
> final price to agree I have to let GC and the statement disagree on
> the price per share.
>
> I just checked by making a fake account set.  No shares yet and I set
> the smallest fraction in the parent account to 1/10000 (instead of
> commodity default of 1/100 for USD) and the fund account uses the same
> 1/10000 fraction.  I added a transaction for 2.345 shares at 4.8 per
> share and let GC compute the price.  Since the parent is set for
> 1/100000 I expected to see that reflected in the total price which
> should compute to 11.256 (and well within the range of a 1/100000
> fraction).  Instead it computed 11.26 and then, as Derek pointed out,
> it back computes the price per share and made it 4.80171 instead of
> the original 4.80.
>

I think you mean total cost where you say total price.  The total cost 
of the transaction (A above) is rounded to the number of places 
appropriate for the currency of the transaction (usually 2 decimal 
places) not the number of decimal places for the shares.  Since this is 
a currency value, it should be rounded as appropriate for that currency.

The share count is rounded to the number of decimal places appropriate 
for the commodity the shares represent.  The price isn't rounded at all 
since it isn't ever stored anywhere.  When it is displayed, it is 
calculated as needed by dividing the total cost by the share count.

Does this make things any more clear?

           Mike