Mutual fund prices precision

[AC]

On 2015-08-03 20:51, Mike Alexander wrote:
> --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.

Ok, well it's a difference of expectation versus true behavior then.  I
expect the number to stay the same and GnuCash has other ideas so that's
what I'm trying to sort out because additional behavior isn't what I
expect (such as changing the commodity fraction).  See below for that.

>> 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?


As far as I've been able to tell from searching through the XML file,
the price per share is stored in the price table where I do find the
price being stored to six decimal places.  At the same time, the shares
and the total cost are also stored in the XML file.

Here's one of the records:
<gnc:transaction version="2.0.0">
  <trn:id type="guid">9b27a0d01203c2bf0d74be18c7020c97</trn:id>
  <trn:currency>
    <cmdty:space>ISO4217</cmdty:space>
    <cmdty:id>USD</cmdty:id>
  </trn:currency>
  <trn:date-posted>
    <ts:date>2015-07-01 00:00:00 -0700</ts:date>
  </trn:date-posted>
  <trn:date-entered>
    <ts:date>2015-08-02 00:12:06 -0700</ts:date>
  </trn:date-entered>
  <trn:description>Reinvestment</trn:description>
...
  <trn:splits>
    <trn:split>
      <split:id type="guid">ebf3b53e8e062f2aa3861b6ffc4eb019</split:id>
      <split:action>Buy</split:action>
      <split:reconciled-state>n</split:reconciled-state>
      <split:value>1046/100</split:value>
      <split:quantity>219300/100000</split:quantity>
      <split:account
type="guid">084a500e2772a1d1618a49bd1db5645e</split:account>
    </trn:split>
  </trn:splits>
</gnc:transaction>


Elsehwere the matching price record for the above transaction looks like
this:

    <price:commodity>
      <cmdty:space>NASDAQ</cmdty:space>
      <cmdty:id>SSSSS</cmdty:id>
    </price:commodity>
    <price:currency>
      <cmdty:space>ISO4217</cmdty:space>
      <cmdty:id>USD</cmdty:id>
    </price:currency>
    <price:time>
      <ts:date>2015-06-01 00:00:00 -0700</ts:date>
    </price:time>
    <price:source>user:split-register</price:source>
    <price:value>4769722/1000000</price:value>
  </price>


So all three entries are present.  The question is, if I have the parent
account defined to be a bank with currency USD but a fraction of
1/100000 (instead of the default setting) and the actual fund account
also defined to have a fraction 1/100000 why is the value recorded as
only x/100 instead of x/100000 like I defined?  The parent currency
account has this configuration:

<gnc:account version="2.0.0">
  <act:name>Holding Parent Account</act:name>
  <act:id type="guid">c344be16f8abf7b2977be1da33a462a7</act:id>
  <act:type>BANK</act:type>
  <act:commodity>
    <cmdty:space>ISO4217</cmdty:space>
    <cmdty:id>USD</cmdty:id>
  </act:commodity>
  <act:commodity-scu>100000</act:commodity-scu>
  <act:non-standard-scu/>
...
  <act:parent type="guid">81c93161a043b4cde6ae96c9cdc495e8</act:parent>
</gnc:account>

And the one line shows the fraction set to 100000.  But it seems to
ignore that yet the table of accounts actually shows that many decimal
places for that account.  I would have expected the transactions to
honor that account's fractions and not the default for the currency.
The price per share appears to behave that way.