Rounding in the price db.

[John Ralls]

> On Sep 2, 2015, at 1:18 PM, David Carlson <david.carlson.417 at gmail.com> wrote:
> 
> 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,

Git’s the easy part. *Building* is the hard part, especially on Windows. I’m not quite ready to merge but I will soon so that you can test it before the release.

Your use case is an interesting one. It actually points up a weakness in the Transfer Dialog, which assumes that the “other” account has been set in the transaction. We might want to defer running the dialog until the transaction edit is completed instead of when exiting the Credit or Debit cell.

Prices have a source and a type field. The source can be “Finance::Quote”, “user:invoice-post”, “user:stock-split”, “user:xfer-dialog”, “user:split-register”, or “user:price-editor”. The current code treats all of the “user:foo” sources the same and prefers F::Q to any of them. Early in this thread we discussed making two flavors of user:xfer-dialog so that cases where the users entered the price directly could be differentiated from those where she entered the amount of the “other” currency and the former preferred over the latter. I haven’t implemented that yet, and your point about user:price-editor being preferred over all others is a good one.

Regards,
John Ralls