Unrealized Gains (Again)

[David Carlson]

Perhaps I could state my question a little differently.  I do always enter
the total amount and the number of shares and let GnuCash calculate the
price for actual transactions.  This forces the number of shares to always
match the brokers' statements.  For mutual funds, shares are usually stated
to the nearest 1/1000, as they are for this example.

I think that whatever rounding discrepancies exist, they are forced by this
method to accumulate as unrealized gain.  That is how the first purchase
created an instant unrealized gain of $4.72 in the balance sheet report
which used the 'nearest in time' quoted price of  $14.62.  This is what I
actually expected for the date of purchase.

What I am more concerned about is ultimately whether the trial balance
method of tracking the cost basis for an account with many purchases and
sales is accurate when the average cost method (or any variation of lot
tracking) is used.  I did not express that in my original message, as I
have not gotten that far in my experiment yet.  What I did state was that
the unrealized gain as reported by the balance sheet report differed from
the spreadsheet unrealized gain number by $4.13 on December 31 2016.  The
difference between the report and the spreadsheet changes after most
transactions.  Thus I expect that the final closing transaction will
probably leave a residual cost basis in that security account, possibly
worth several dollars.  I think that has already happened in my data for
some closed 401-K's.

Would it be appropriate to track whatever residual unrealized gain exists
and transfer that amount to equity at some point to drive it to exactly
zero after the last fractional share is gone?  If so, is there some easy
way in GnuCash to find that residual value for any commodity account in a
practical data file that could have hundreds of securities and thousands of
purchases and sales?

David C

On Mon, Mar 6, 2017 at 11:11 PM, John Ralls <jralls at ceridwen.us> wrote:

>
> On Mar 6, 2017, at 8:26 PM, Edward Doolittle <edward.doolittle at gmail.com>
> wrote:
>
> On 6 March 2017 at 22:13, John Ralls <jralls at ceridwen.us> wrote:
>
> You *always* want GnuCash to compute the price. Always. That's because if
>> you feed it a rounded price you get an inexact result
>> in either amount or value, and that's what gets stored. If you give it
>> the exact amount and value then it might display a rounded price, but the
>> stored amount and value are correct and GnuCash will always recalculate the
>> price and maybe round it for display so there's no error.
>>
>
> Maybe, then, users shouldn't be given the option of entering the price?
>
>
> Maybe not. I was thinking about that as I wrote it.
>
> But I always worry that there are use cases that I haven't thought about
> when I have the urge to do something dictatorial like that.
>
> Regards,
> John Ralls
>
>
>