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