GNOME Bugzilla – Bug 449395
Support for fixed prices
Last modified: 2018-06-29 21:39:40 UTC
The preference "enable euro support" should be removed altogether. It's unclear whether it changes anything anyway, but more importantly it rather confuses the user because of course we must support the Euro. At first, the preference must be removed from the preference dialog. In a (potentially) later step, any internal case-distinctions on the state of this preference should be removed and replaced by always-on semantics of that preference.
http://lists.gnucash.org/pipermail/gnucash-devel/2007-June/020766.html has been proposed and partly implemented in r16196. The only thing is name and description of the gconf key. I think the name should stay the same, providing backwards compatibility. The description could be made more precise, but this will have to wait for the String Freeze to end.
Retargeting for 2.3.x. Setting severity to Minor.
This is targeted to 2.3.x. What is still needed?
What is needed for this?
http://lists.gnucash.org/pipermail/gnucash-devel/2009-October/026607.html and thread. What I got from that discussion is this: The gnc-euro.c code contains a second price db for a particular sort of prices, namely those where authorities have set a fixed exchange rate for two currencies which won't ever be changed again. This is useful for e.g. the old euroland currencies to EUR, and in principle it will also be useful for any future country currency changes ("old turkish lira" vs. "new turkish lira" etc). Hence, the features of that code are probably useful. However, we don't need the preference anymore. The parts of the gnc-euro.c code which are useful should be enabled always, but any extra EUR column in any window which is switched on by this preference can go away and the preference can go away as well. Herbert Thoma said he might contribute a patch for improving the usefulness of this, but the preference can go away in any case.
Unless Herbert Thoma is still working on this, I am about to look into the remaining things to do for this bug. I'm not really clear on some thing(s) though: Suppose I have an old book that is using BEF as base currency (one example of the obsolete EURO currencies). If I am to open this book after this bug has been closed, in what currency should the transactions and splits in that book be shown ? Should they be shown in EUR or in BEF ? And what if I make changes in this book, I presume they should still be stored internally in BEF ?
(In reply to comment #6) > Unless Herbert Thoma is still working on this, I am about to look into the > remaining things to do for this bug. Good! > Suppose I have an old book that is using BEF as base currency (one example of > the obsolete EURO currencies). If I am to open this book after this bug has > been closed, in what currency should the transactions and splits in that book > be shown ? Should they be shown in EUR or in BEF ? They should be in BEF. Showing them in EUR should be possible through the normal price data base mechanisms, with the potential extension that the price data base should contain the BEF - EUR rate as a hard-coded extension of the normal price table. > And what if I make changes > in this book, I presume they should still be stored internally in BEF ? Existing transactions should still be in BEF, as they always have been and should always be. This preference concerned only the display of the txn.
(In reply to comment #7) > > Suppose I have an old book that is using BEF as base currency (one example of > > the obsolete EURO currencies). If I am to open this book after this bug has > > been closed, in what currency should the transactions and splits in that book > > be shown ? Should they be shown in EUR or in BEF ? > > They should be in BEF. Showing them in EUR should be possible through the > normal price data base mechanisms, with the potential extension that the price > data base should contain the BEF - EUR rate as a hard-coded extension of the > normal price table. > This is probably more of a user question, but it will help me better understand what to modify: Let's assume indeed that the BEF - EUR rate is available hard-coded (that I can probably already do), then how would a user display his accounts in EUR ? Can the accounts tab use EUR then ? What about the register windows ? Or do you mean that reports can be generated reports in EUR ? Thinking of this, I suppose it would make sense that only the reports can be displayed in different currencies, right ? > > And what if I make changes > > in this book, I presume they should still be stored internally in BEF ? > > Existing transactions should still be in BEF, as they always have been and > should always be. This preference concerned only the display of the txn. Ok
(In reply to comment #8) > > > Should they be shown in EUR or in BEF ? > > > > They should be in BEF. > > > This is probably more of a user question, but it will help me better understand > what to modify: > Let's assume indeed that the BEF - EUR rate is available hard-coded (that I can > probably already do), then how would a user display his accounts in EUR ? Can > the accounts tab use EUR then ? No, the account is in BEF. Only the reports should be able to view the EUR values. The register should stick to the original currency, which is BEF. > Thinking of this, I suppose it would make sense that only the reports can be > displayed in different currencies, right ? Exactly.
I have changed the title of this report to better reflect what's left there to do: GnuCash should be able to read conversion prices from a fixed price database, which we optionally provide ourselves. This idea started for the old Euroland currencies, but I can imagine there will be more of these.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=449395. Please continue processing the bug there and please update any external references or bookmarks.