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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
