Rounding in the price db.

[John Ralls]

> 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/061581.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.

Regards,
John Ralls