Mutual fund prices precision

Tue Aug 4 11:06:24 EDT 2015

AC,

My understanding of the data structure is that the price DB is separate from the transaction register—and that the presence of the former is not directly related to the latter. In other words, the register does not use the price DB. That is what others implied. 

I am not sure which method the reports use (and in fact I imagine that the different reports handle it differently); the presence of the time selection option on some of these reports suggests strongly that the price DB is used in those instances, but I am not a programmer, so cannot say definitively.

Again, my understanding is that GnuCash’s roots are in traditional accounting, in which the focus is on real commodities. Thus, GnuCash emphasizes the number of shares involved and the amount of capital expended on purchasing those shares, since those represent real commodities. The price per share in a transaction is imputed from the other two.

HTH,
David

> On Aug 4, 2015, at 3:31 AM, AC <gnucash at acarver.net> wrote:
> 
> 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.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.