[GNC-dev] book currency is what ... question mark

Wm wm_o_o_o at yahoo.co.uk
Sun Feb 17 13:58:50 EST 2019

On 15/02/2019 01:44, David Cousens wrote:
> Wm,
> My apologies for being long winded in the following, but I think it is
> necessary to achieve clarity in what is proposed or intended.

Not at all, I appreciate your effort and have read what you have written 
more than once.

> The "book currency" is the currency assigned as the default currency, i.e
> the currency of the root account, when you create a new book or file  using
> the File->New File. I can create a new file with a default currency of USD
> even though my "home currency" i.e. the currency where I live, is AUD and I
> may choose  maintain a separate book or file with AUD as its root or default
> currency. I can't think of a good reason why unless I happen to commute
> between the US and Oz on a regular basis but I could choose to do it. When
> you create a new account, it will by default have that "book currency"
> unless you change it to another currency.

Starting a tx stream with an unadorned (no currency) number is normal 
for most people, changing it part way through is never going to be 
simple.  Obvious answer?  Start with a nominal currency tx.
1 [nothing] = 1 [Currency of Choice]
it really can be that simple, put that right at the beginning and every 
unassigned number has a currency.

> In what way do you think what John said is invalid?

I don't really disagree with John much, he is just often the person 
brave enough to reply.

> For a transaction crediting an account in RUB and debiting one in EUR for
> 100 EUR at an exchange rate
>   of iEUR=75.30 RUB(e.g. asset saving) the register for Savings EUR appears
> as
>                                  Debit         Credit
> Savings EUR              100.00
> Savings RUB                               100.00
> and the register for Savings RUB as
> Savings EUR            7530.00
> Savings RUB                             7530.00
> when the transaction is carried out from the Savings EUR register (with
> presumably the description field linking the two to show they are one and
> the same transaction.

Ummm, have you heard of Trading Accounts?  The splits show actual values 
for each register.

> If it is initiated from the Savings RUB account the transactions appear
> exactly as above in each register (provided of course the same exchange rate
> is used. The advantage of the above for me is that the value of the
> transaction in each currency is clear and the exchange rate used is clear
> and calculable from the balances (as well as being able to check the price
> editor.) and it is clear that the transaction is balanced in both
> currencies.

Trading Accounts, again.  Plus, I find it useful to right click and 
choose Edit Exchange Rate if I want to check (the tx rate not the price 
file rate should be prime) [1]

> If I start in Savings RUB , select the Savings EUR account and enter 100 it
> is assumed to be in RUB not EUR as GnuCash operates at present. This is
> clear, both registers are balanced and it is clear that they are correct.
> I am presuming what you would like is to be able to start in the Savings RUB
> register, select the Savings EUR account, enter 100.00 as the amount and
> have that interpreted as !00.00EUR, even though the register currency is RUB
> and then when you tab to the next line select Savings RUB have the currency
> dialog popup, enter or fetch the exchange rate, and then display the amount
> against the Savings RUB account in RUB. 

Nope.  I normally know the exact amounts at either end of significant 
tx, the exchange rate is implied from the numbers.  That *is* the right 
way of doing the accounting.

You start with 100 of some currency and end up with 2300 of some other 
currency, the *valuation* is separate.

gnc doesn't seem to get into this muddle with other commodities, btw, 
just currencies.

aside: There may be occasions when an approximate value may work fine 
because the amount doesn't matter but commercial exchange rates as 
fetched from AV or taken from a bank or credit card statement for 
example will rarely match an actual tx for most people so one should 
never start from there.

> And similarly if you start in
> Savings EUR and repeat the procedure. I.e. no matter what register is in
> use, the register would display the amount of a split in the currency of the
> account that the split is being made to not the currency of the register .
> e.g.  would appear in the entries for both registers
>                                 Debit                  Credit
> Savings EUR             100.00                                     (EUR)
> Savings RUB                                      7530.00          (RUB)
> I personally would be quite happy if this were the way GnuCash registers
> behaved, particularly if the currency symbol were to appear at the end of
> each line to indicate the currency applicable to the split, but I find the
> current system of displaying amounts in the currency of the register being
> displayed, equally as clear. When I made my first multicurrency transaction,
> it took me all of 5 seconds to follow what was happening.

I am not too troubled by that as I put the currency at the end of each 
account name that isn't GBP out of habit and even add GBP if it often 
interacts with other currencies.

> I have some reservations about Alex's proposal to convert the amounts to the
> "book currency" to check the balance. I may be misunderstanding the
> intention here but it is not reallynecessary to check the balance as long as
> the amounts in the splits are in agreement with any exchange rates and their
> respecive currencies. It is the equality of
> amount in currency 1 = amount in currency 2

I think (and I accept my understanding may be wrong) what Alex is 
proposing is, errrm, wrong.

> If the book currency is USD (or AUD or any other third currency) then the
> currency conversion becomes EUR<->USD<->RUB. 

No it does not!  That is a valuation (i.e. balance sheet time exercise).

The tx of currency to currency is an exact number of so many units of 
one thing to so many units of another.  No value!  Yes there may be 
expenses and so on but you start with 10 of one thing and end up with 21 

> The double conversions involved
> to the EUR and RUB may introduce scope for rounding errors to produce
> slightly different results on conversion back.

If someone only made very occasional tx outside of their home currency 
(I include any other commodity) that probably wouldn't be an issue.  It 
does, however, raise problems for tx in non-currecy stuff too and it 
seems to me Alex is trying to do something other than understanding the 
scary Trading Accounts.

> It also assumes that EUR->USD-> RUB will give the same result as EUR->RUB.
> Where the exchange rates are good to 6 significant figures, this appears to
> be OK using today's figures
> (https://www.xe.com/currencyconverter):
> 1 EUR=75.3052 roubles
> 1 EUR =1.12958 USD
> 1 USD = 66.6667 RUB => 1 EUR = 75.3054 RUB.
> If you transfer amounts of >10000 roubles or equivalent this could start to
> introduce significant errors into what is recorded.

It works the other way, actually, the larger the amounts exchanged the 
closer you get to commercial rates.  Try sending 1 AUD / USD / GBP / EUR 
to any of the others and see how much it really costs.

The point is, and I repeat myself, the actual values are what counts, 
the exchange rate for a tx should be calculated from the values and at 
the end of the tx you do NOT have so-much-worth of foreign stuff any 
more than when you buy some shares you have so-much-worth of that 
company.  You have 123 of another commodity, just like you have 321 of 
shares of a company, the value of which changes constantly.

> My view is that the recording of foreign currency transactions really needs
> to follow and reflect the events associated with the transaction as they
> occurred. I.e. no conversion to an intermediate currency unless that is what
> actually occurred. 


> I do not see how converting a transaction between
> accounts in EUR and RUB via a third currency affects any entries in the
> "book currency" until such funds are actually converted to that "book
> currency" in any case and it is the price of that conversion when that
> conversion actually occurs which ensures the integrity of the book in the
> "book currency".

You have a value at the time and a value at the report date, reporting 
the later date is balance sheet stuff, reporting the difference is 
income statement stuff.

> Reports could/should report a foreign currency balance at either a specified
> exchange rate or the current exchange rate but should make clear what that
> is, but that is a separate issue.

I am certainly sure the tb is wrong.

> I am not sure what
> contributed to the discussion of this point though Wm.

If your world view is USD prime (which has largely been the case since 
WW2 for USA people) you don't care much about the rest of the world 
regardless of numbers and money, you expect other people to fit into 
your tax system, your tax system's valuation of assets, following from 
that you impose your view of the value of fx tx on other people and so 
on.  None of this tends to be a problem so long as people are aware of 
it.  That changed with Trump, his election defined some USA people as 
being proud of being ignorant of the rest of the world.

[1] the tb is where this gets confused, it is not meant to value stuff 
at a date but at the time of the tx, or if it isn't doing that it is 
doing other weird stuff we're still working out.  the current tb 
starting point (balance sheet, value of things at a single point in 
time) is wrong.


More information about the gnucash-devel mailing list