Mutual fund prices precision

[Derek Atkins]

AC <gnucash at acarver.net> writes:

> I know the share count matters, but the share count is wrong and I can't
> get it working properly to match the statements.  Doesn't matter if I
> let GC compute the price or compute the buy/sell total, it still seems
> to be off slightly in the share totals.

The only numbers that GnuCash cares about are:

1) Number of Shares, and
2) Total Value of those shares

The price is always computed.  If you enter in a price then it will
compute one of the other values, round it, and then *recompute* the
price.

> For one account the shares as listed on the statement are 950.971 but GC
> is computing 949.632 even though I started the account from scratch and
> entered every transaction manually.  Most of the other funds differ in
> shares by 0.01 but this one is a larger difference of a whole point.
> This is also the only account where most of the prices have
> autocorrected themselves so that's why I'm suspicious of the things
> going on in the background.

This means you did not enter in the number of shares correctly...
Either that or your rounding and the institution's rounding are
different.

-derek

> On 2015-08-01 16:58, Edward Doolittle wrote:
>> AC,
>> 
>> The share count is what matters when you reconcile the account, not the
>> price. You should enter the amount you paid and the number of shares you
>> received, and let GnuCash calculate the price for you.
>> 
>> Edward
>> 
>> On 1 August 2015 at 17:37, farleykj <farleykj at gmail.com> wrote:
>> 
>>> I tried this out, via the following, pretty much as you described:
>>> (1) enter 47.889 shares in that column.
>>> (2) enter 4.76 in the price column
>>> Make no other entries, <tab> through to the next line of the split.
>>> The result is the total is calculated as 227.95. This results in the price
>>> per share being adjusted to the 4.75997 value. The number of shares is
>>> unchanged. Thus I don't understand what you mean by the final share count
>>> being off.
>>> I suspect what's happening is because the registers are only allowing the
>>> balance column to represent numbers with two decimal places, since we're
>>> dealing with dollars and cents. It calculates the total to be 47.889 * 4.76
>>> = 227.95164, rounds that to 227.95, then recalculates the price to be
>>> 4.75997.
>>>
>>>
>>>
>>> -----
>>> Ken Farley
>>> --
>>> View this message in context:
>>> http://gnucash.1415818.n4.nabble.com/Mutual-fund-prices-precision-tp4679709p4679711.html
>>> Sent from the GnuCash - User mailing list archive at Nabble.com.
>>> _______________________________________________
>>> 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.
>>>
>> 
>> 
>> 
>
> _______________________________________________
> 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.
>
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available