Rounding in the price db.

[David Carlson]

On 9/1/2015 10:01 PM, John Ralls wrote:
>> SNIP...
> David,
>
> Quotes from F::Q are supposed to overwrite user entries for the day, but although F::Q is quite capable of retrieving historical quotes, GnuCash doesn’t use that facility. So if you create a transaction with a date_posted in the past and there isn’t already an F::Q quote for that day then the price generated from that transaction won’t get overwritten later on. On the other hand, if you do have an F::Q quote already on that day then the user price won’t get written to the price db.
>
> Umm, are you able to build from git? This code is currently on a feature branch so it isn’t going to get into the nightlies for you to test with otherwise. I think I understand the first test-case well enough to run tests myself, but I need more detail on the second (the duplicate-and-modify) one to test it.
>
> Regards,
> John Ralls

John,
I am not ready to try git, but if it does get to nightly or weekly
windows builds, I could try that.

That second case comes from a habit I developed years ago that once I
have a transaction with a structure that I like but it is in the 'wrong'
account for my current needs, I will clone it there then change the date
and accounts one by one until it is 'correct.'  Sometimes I will stop
and create a new account if I did not create all the accounts ahead of
time.  Since I don't have a fixed routine to do this, I may change any
transaction field in any order, then I often need to save before
finishing to switch to a different account register to complete the
transaction.  This is most likely to happen when I sell a security that
I have not sold from that brokerage account in the past, but that is not
the only time it happens. 

Prior to the 2.6 .x releases, that did not cause any issues in the price
data, but now there are cases where GnuCash wants to set a price (or
quantity?) for a 'wrong' security before I am ready, and it may also add
entries to the price database.  If GnuCash discards transaction derived
prices when there are 'better' prices already present, that is fine with
me.  Otherwise I would request that GnuCash ask if I want to record the
price in the database before that happens.  I think that there is a
difference between 'User" prices entered directly into the database
compared to prices derived indirectly from transactions.  If the derived
price(s) disappear if (all of the) the source transactions for that date
disappear or change, that would be ok too.

Actually, when directly editing the price database, the user can select
whether the price is characterized as High, Low, Last, NAV, etc.  Only
Last or NAV type 'User' prices would need to be 'stickier' than F:Q
prices or indirectly derived prices, in my opinion.

David C