Rounding in the price db.

David T. sunfish62 at yahoo.com
Thu Aug 13 09:28:01 EDT 2015


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

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.

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. 

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. 

David

* I will take a look at the documentation and see what I can come up with to inform users better.

> Regards,
> John Ralls
> 
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




More information about the gnucash-devel mailing list