Any way to correct the running total of shares?

[David Carlson]

On 2/5/2014 4:59 PM, David T. wrote:
> Another way to think of this: the Price DB shows the value of a commodity as of a given date. GnuCash stores this value because, once retrieved, it remains accurate, since it reflects the share value on that date.
>
> I still don't understand how you could be registering shares from a price entry (or how you have hidden entries adding shares to your books). The prices don't include share values.
>
> David
>
>
> ________________________________
>  From: Derek Atkins <warlord at MIT.EDU>
> To: Graham P Davis <hacker at scarlet-jade.com> 
> Cc: gnucash-user at gnucash.org 
> Sent: Wednesday, February 5, 2014 7:41 AM
> Subject: Re: Any way to correct the running total of shares?
>  
>
> Hi,
>
> Graham P Davis <hacker at scarlet-jade.com> writes:
>
>> I've looked in the Guide but haven't yet found a mention that if one
>> deletes an entry from the accounts display, one should also remove it
>> from the Price Editor.
>>
>> Is this behaving as it should and, if so, is there a warning in the
>> Guide that I've missed? If this is not the correct behaviour, should I
>> raise a bug report?
>>
>>
>> As to zero-pricing, that was a misunderstanding of the system on my
>> part and I think I've got a way round that. If I want more help on
>> that, I'll raise it separately.  
> The PriceDB and Register are only loosly linked.  The register will read
> from the PriceDB to suggest an exchange rate (or price), and it will
> enter a price in the PriceDB if one does not already exist for the day.
> However as you notice it will never remove data from the PriceDB.  Part
> of the reason is that even if you delete the transaction it cannot know
> for sure that there isn't ANOTHER transaction somewhere also using the
> same PriceDB entry.  Moreover, there is not a direct link from the
> transaction that caused the PriceDB entry to be created.
>
> So basically what you are seeing is a feature, not a bug.
>
> -derek
>
Do not take my opinions about releases 2.6.0 or 2.6.1 as gospel, because
I have not tried them more than very briefly.

If you look carefully at the pricedb screen you will see that prices can
come from several different sources.  The most common source is from
downloads but there is supposed to be another source from stock
purchases and sales when transactions are entered.  This source was
broken in release 2.4, but it was restored to work again in release 2.6,
if I recall correctly. 

Thus, as Graham stated, when he entered a transaction, a price was added
to the pricedb.  When he deleted the transaction, the price was not
deleted.  In the 2.5 releases that price would have been entered in an
odd-looking (but accurate) fractional form, but I think that was also
changed in the 2.6.0 or 2.6.1 release. 
Since his share balance now seems correct, I think that his problem has
been resolved.

I doubt that the extra pricedb entry serves as evidence to missing
shares which apparently could happen as a result of one of the bugs in
release 2.6.0.  It could, however influence what values are chosen for
shares in certain reports.  Also, if a transaction is entered with an
incorrect price, that may also appear in the pricedb.  If a user is
worried about that, he would have to search for and delete the spurious
price(s) manually.  If someone thinks this is not correct behavior, I
would love to hear his argument.  Perhaps an argument could be made for
making it easier to see price quotes when viewing screens where they are
used.

The reason purchase or sale prices are allowed to differ from downloaded
quotes is because they rarely exactly match quotes for stock, bond or
option transactions.

David C