Any way to correct the running total of shares?

[Graham P Davis]

On Wed, 05 Feb 2014 22:01:43 -0600
David Carlson <david.carlson.417 at gmail.com> wrote:

> 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

Thanks, David, for trying to explain but let's please forget about the
price of the shares, that is absolutely irrelevant. Tne error in the
'balance' column was for the number of shares. 

In 2.6.0, say I entered a purchase for 1000 shares, the balance column
showed 1000. If I then bought another 200 shares, the column read 1200.
If I deleted that entry and added a purchase of 300 shares, the balance
column would read 1500 shares instead of 1300.

In 2.6.1, the same procedure gives the correct result of 1300 shares,
showing the bug in 2.6.0 has been fixed. 

-- 
Graham Davis, Bracknell, Berks.
openSUSE 13.1 (64-bit); KDE 4.12.2; AMD Phenom II X2 550 Processor;
Kernel: 3.11.6; Video: nVidia GeForce 210 (using nVidia driver); 
Sound: ATI SBx00 Azalia (Intel HDA); Wireless: BCM4306