Inability to correct GBP value for Euro priced shares

John Ralls jralls at ceridwen.us
Sat Jun 10 19:14:13 EDT 2017


> On Jun 10, 2017, at 3:19 PM, Fred Bone <Fred.Bone at dial.pipex.com> wrote:
> 
> On 10 June 2017 at 14:52, John Ralls said:
> 
>> 
>>> On Jun 10, 2017, at 10:35 AM, Fred Bone <Fred.Bone at dial.pipex.com>
>>> wrote:
> [...]
>>> I can verify that an old price in GBP trumps a new one in EUR. This
>>> *has* to be a bug, surely?
>>> 
>>> I will log a bug on Bugzilla shortly.
>> 
>> It might be a bug, but it's so minor and obscure that we're not even going
>> to consider it. I've made a detailed response on the bug report [1], but
>> the executive summary is that securities priced in multiple currencies
>> don't exist. 
> 
> True, but this misses the point. The OP had accidentally created a 
> Pricedb entry in the base currency that (had it not been eliminated) 
> would forever poison the valuation. I doubt whether he was the first or 
> last to do this. One use-case I can think of is when the user wishes to 
> reflect a valuation at a particular point in time as supplied by the 
> broker. It seems illogical that if this happens to be in the book 
> currency it will override any subsequent ones, while if in the 
> commodity's currency the reverse is true.

Right. The OP made a mistake. There is no way GnuCash can anticipate, correct, or flag every possible mistake a user might make, and frankly even trying would be a misuse of very scarce developer time.

Commodities don't have currencies. Accounts have a commodity which might be a currency. Accounts are priced to their parent accounts, and GnuCash can do that only one price/exchange rate at a time. 
> 
> Your claim (in the response) that an intermediate account in the 
> commodity's currency would cure the problem 
>> In order for GnuCash to correctly handle stock investments in currencies
>> other than the book currency they need to be subaccounts of an account
>> denominated in that currency, 
> does not reflect what I find. I omitted tne intermediate in my sample 
> purely because it changes nothing; my own books do include such an 
> intermediate and I can readily reproduce the OP's problem.
> 

I wrote:
> Doing that without changing anything else will allow GnuCash to display the correct value for investments (EUR), but the rollup to Investments will still be wrong as long as that bogus price for GET.PA is in the pricedb.

That's exactly what I observed: The value on the Accounts page was correct for the intermediate account (Investments EUR) but not for the rollup to GBP (Investments).

Regards,
John Ralls



More information about the gnucash-user mailing list