Rounding in the price db.

[david.carlson.417@gmail.com]

    I usually reply at the end of a message but this tablet is not set up that way yet.Thank you John for that concise description.  This thread Is too lengthy to browse and I am still trying to figure out why one Android device puts the last message at the top of the list and another device puts the last message at the bottom or sorts randomly? ?? I am definitely not rrady to give up my tower next to my desk.  Tablets are impossible to edit on, too.
I like the idea of deferring the transfer dialog to the end of the edit session but that would not completely solve the problem of changing a transaction from a sale of ABC stock to FOO stock because it is still necessary to save before going to the target security account register to adjust the number of shares or something to get whole thing right.Maybe I could learn to start by adding an empty split line to make the ttarget security account available as a place to do the edit., but there is still either an intermediate save or split lines containing different lots and securities (maybe even different brokerage accounts) to contend with.  Now that I am thinking about it, maybe I should try doing that in a ledger view.  I have not tried that.  Business transactions probably add more cans of worms to this work flow concept.
If there was a way to paste an entire transaction into an account, then a different method of editing might work.  I think that would be way beyond the scope of this work.
I am looking forward to seeing the result of all your hard work.
David C

Sent from my LG G Pad 7.0 LTE, an AT&T 4G LTE tablet



------ Original message------From: John RallsDate: Wed, Sep 2, 2015 7:56 PMTo: David Carlson;Cc: gnucash-devel at gnucash.org;Subject:Re: Rounding in the price db.
> On Sep 2, 2015, at 1:18 PM, David Carlson  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