Rounding in the price db.

[Geert Janssens]

On Thursday 13 August 2015 09:28:01 David T. wrote:
> > On Aug 13, 2015, at 6:52 AM, John Ralls <jralls at ceridwen.us> wrote:
> >> On Aug 13, 2015, at 10:51 AM, Geert Janssens
> >> <geert.gnucash at kobaltwit.be> wrote:>> 
> >> On Thursday 13 August 2015 10:06:09 John Ralls wrote:
> >>> First, there’s one other use for the price db: It provides the
> >>> default price to the transfer dialog
> >>> (gnc_xfer_dialog_update_price()). The current behavior aggravates
> >>> some people because every entry tweaks the amount slightly so the
> >>> user has to keep editing the value in the transfer dialog. As you
> >>> can imagine this is irritating. For an extreme case see the
> >>> thread in the user list
> >>> (http://lists.gnucash.org/pipermail/gnucash-user/2015-August/06158
> >>> 1.h
> >>> tml) from a user in the Cayman Islands, which has its own currency
> >>> but which has pegged it to the USD.
> >> 
> >> Yes, I have followed that thread also. The rounding test may reduce
> >> the irritation, but will probably not fix all of it.
> > 
> > Right, which motivates the price-vs-calculated discussion below.
> > 
> >>> In examining the transfer dialog price-update code I noticed that
> >>> there’s an exception for the currencies that have been absorbed
> >>> into
> >>> the Euro. The case of our user from the Cayman Islands and the
> >>> possibility of Grexit makes me wonder if we should have a
> >>> different
> >>> way of dealing with that. Those currencies’ prices are never
> >>> updated,
> >>> but that might change for the Drachma, and while the Cayman
> >>> Islands
> >>> fellow was arguing for similar treatment for his currency it’s
> >>> entirely possible that the Cayman Islands might change the rate
> >>> from
> >>> time to time just as the Chinese government changes the rate on
> >>> the
> >>> Yuan/RMB.
> >> 
> >> At one point I looked at this code and even started to implement a
> >> way to have these "static" prices in a configuration file. That
> >> was very early in my involvement with gnucash and I now consider
> >> that early work way too naive to include in the code base. It did
> >> make me think about the issue though and I now think the cleanest
> >> solution would be an additional price source in F::Q that queries
> >> a db of static prices. Ideally this price list is maintained
> >> independently of the F::Q source such that even static prices can
> >> be updated if needed without requiring users to upgrade their F::Q
> >> installation each time as well.
> >> 
> >> That would keep the quote code in gnucash fairly straight-forward
> >> (no
> >> need for the exception code anymore). And F::Q is already aimed at
> >> having multiple price sources.
> >> 
> >> As an intermediate solution we can also choose to keep the
> >> exception
> >> code but move the prices themselves to a configuration file. This
> >> file can then be manually updated if needed without having to
> >> rebuild gnucash each time.
> >> 
> >> I haven't thought out any details of this. These are just general
> >> ideas.> 
> > Sigh. src/app-utils/gnc-euro.[ch]. Not only hard coded but not in
> > engine where it obviously belongs. Yes, obviously it should be
> > redone as a datafile; I can’t imagine why those currencies aren’t
> > part of iso-4217-currencies.xml with a tag indicating their
> > absorption with a date — and for future umm, disturbances, a
> > de-absorption date. Whether that’s loaded or compiled probably
> > makes no difference since we have no good way of distributing
> > updates between releases. Regardless, it would give us a nice
> > platform on which to expand for pegged currencies.> 
> >>> It’s obviously my hope that the 1 scu rule will prevent any
> >>> jitter,
> >>> but we should be prepared to adjust it if necessary. Mike proposed
> >>> early on that we treat differently prices that are entered vs.
> >>> those
> >>> that are calculated so that they’re not subjected to jitter, but
> >>> that
> >>> makes me a bit nervous. We’d obviously have to tag them
> >>> differently
> >>> in the pricedb and it would create a new precedence: F::Q,
> >>> user-direct, user-calc or some such. Is that worth considering?
> >> 
> >> That's a difficult one. I understand the benefit of this. A user
> >> entered price can be considered exact and preferred over a user
> >> calculated one. So it would sit in between an F::Q fetched price
> >> and one that had to be calculated from the different amounts in
> >> our selection system.
> >> 
> >> On the other hand my fear is adding yet another type may add to the
> >> user confusion instead of reducing it. Although if it's well
> >> documented the difference between the tags should be fairly easy
> >> to learn and understand.
> > 
> > Users are already pretty thoroughly confused. A little more won’t do
> > any harm. ;-)
> > 
> > Maybe if we renamed the Price DB some variation of the Price History
> > DB or Market Price DB it would be clearer? ISTM the fundamental
> > problem is getting inexperienced users to understand that market
> > prices and realized prices are different and that only the latter
> > apply directly to accounting. There should be a discussion of that
> > in the Tutorial… but getting people to read docs is always a
> > challenge.
> John,
> 
> I think renaming and documenting* would be the best way to go.
> Considering this a little more, it seems to me that there are two
> different issues here: basis and valuation. The first is (or should
> be) always based on the actual transaction, while the second is (or
> should be) based on some external data source.
> 
> Untangling the two data sets entirely could clarify this for users.
> This could be accomplished by making the PriceDB *only* hold F::Q or
> user-entered values, and not prices calculated from transactions. To
> handle the “How come GnuCash doesn’t know the price for these shares
> I bought and entered into my accounts?” problem, insert a F::Q lookup
> into the transaction save routine (instead of a PriceDB insert), and
> put a F::Q derived value into the PriceDB. At least that way, the two
> are clearly separate. The question of value would look to the
> PriceDB, while the question of basis would look to the transactions.
> 
I'm not sure we can do that:
- until now F::Q is an optional module. Especially on Windows not 
everybody has it installed or wants to go through the hassle of 
installing it. If we want to insert an F::Q lookup in each multi-
commodity transaction, it has to become a mandatory module, installed 
for everyone.

- even worse IMO, it would turn gnucash into an app that *requires* 
internet access because F::Q can't work without it. That is an important 
change which would make it a much less attractive option in places 
around the world where internet access is expensive.

> With the circumstance of multiple same day buys of a commodity, I
> don’t see how to avoid the problem that each position will differ
> from the PriceDB basis, except to note the differences between basis
> and value (especially as implemented in GnuCash) clearly in the
> documentation. In reality, it’s no different than the inter-day
> fluctuations that users are comfortable with, except for the timing,
> but it obviously can be confusing.
> 
That's true. And I agree improved documentation can probably help a lot 
here.

> I suspect that Geert’s comment regarding how the reports derive basis
> is crucial as well. It seems to me that there have been a number of
> issues raised in the user list about needing to change the price
> setting in reports to get valid information on this data point; if
> every report used the same method for determining basis (the
> calculated transaction value, IMHO), this problem ought to go away.
> Removing that part alone would go a long way to cleaning things up in
> users’ minds, I believe.
> 
I have no idea how different reports deal with this. As I rarely use 
multi-commodity transactions, I never played much with this part of 
gnucash.

But I agree that more uniformity in this respect among the reports 
(where possible) would be a good thing.

Geert