reporting currencies & integrity

Christian Stimming stimming@uclink.berkeley.edu
Tue, 23 Jan 2001 22:35:28 -0800


-----BEGIN PGP SIGNED MESSAGE-----

> Lets say that our 'reporting currency' is USD.  Lets say we live in
> france, and we bought IBM stock with FF.  The user types in the
> shares bought, and the FF paid. (that's our first 'exchange rate').
>
> When user clicks on 'commit', a little GUI dialoge pops up, and says
>
>   'To correctly report this transaction in the main window account
>    summary, we need to know the value of this transactin in USD.  The
>    last exchange rate we know of for USD is xx.yy FF per USD, which
>    would value the transaction at $zzz USD.  Use this exchange rate, or
>    edit?'

I disagree. Instead I agree with Bill's three FASB59 methods. Which means 
in this example: The user types in the shares bought, and the FRF paid, 
and clicks on commit. That's it for the user -- no extra dialog is 
necessary.

But at some point in time before, the user clicked on "Settings" - 
"Currencies" and chose the "report currency" (say, Swiss Franks CHF) as 
well as one out of three "methods to convert amounts to report currency". 
This method determine what gnucash will do after the above transaction is 
entered:

1) "convert the amount at the current exchange rate". Then gnc-prices will 
be started to fetch the current price of IBM. This price might be in EUR, 
so gnc-prices will also get the rate EUR to CHF (that one might 
already be cached). The resulting price will be displayed. Note that the 
result will not at all be stored anywhere; it is only for displaying 
("reporting") purposes. Also note that the displayed value of the IBM 
assets might change pretty soon, depending on the price update interval, 
but almost surely on every new business day.

2) "convert component amounts at their historical exchange rate" Let's 
assume that somewhere in the WWW there is a stock ticker which gives you 
not only the prices for right now but also for any point back in history. 
Then the actions under 1) will be performed by querieing that stock ticker 
with the day of the above transaction. If there is no such stock ticker 
those prices will have to be stored somewhere in gnucash and it remains to 
be discussed where. Note that the displayed value of the IBM assets will 
never change unless there is a new transaction with IBM shares.

3) "weighted-average exchange rate for the entire reporting period" (At 
least that's how I would understand it: ) Let's assume that you didn't own 
any IBM shares before. Then the price ("exchange rate") from IBM to FRF is 
taken exactly from this transaction and you (the reporting code) has to 
get from FRF to CHF. Let's further assume that the whole book began with 
CHF, that is, there is only one equity account and it is in CHF. To own 
any FRF at all you probably at some point in time have bought FRF for CHF, 
e.g. you bought FRF 400 for CHF 100 and at a later point you bought FRF 
1000 for CHF 200. Gnucash then builds the weighted average over all 
CHF-FRF transactions and comes up with an exchange rate (e.g. 
(400+1000)/(100+200)=4.66). By this means the report can calculate the 
value of the IBM shares in the current report currency. Note that the 
displayed value of the IBM assets will change everytime you buy more FRF 
for CHF.

Recall that the "reporting currency" can be changed anytime (= I agree 
with Bill on this). I disagree with Linas in that accounts should have a 
"reporting currency". Reports show many accounts but they need one "report 
currency" to give one single number at the bottom line. If you mean two 
different things here then don't give them the same name.

I repeat my question from today afternoon: Where can I find more 
information about the "price database" that you're talking about? I haven't
found it anywhere in the source. Or what kind of database do you mean, 
Linas?

Christian
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBOm53t2XAi+BfhivFAQFuEgP8Dl5wo5blikUG02s8fVQMgOUMfrQu7GLy
ZK6yE2eBugk6KSCC5h0Azr7+RHnYQJddr1tHE0oquTxWOi0fjjPsxS4oAUkej7KP
NxQlIF+rmo5dqWyOkCpXx2/OxEr8rt4Ed9fL6EKPbv9J4rKXQzMoT18+6DkeAJGO
tVN1WMlhPR4=
=0zo+
-----END PGP SIGNATURE-----