Multi currency discussion cont'd

[Jan Nielsen]

Hi Derek,

>Hi.  I'm finally back from vacation so I can take a look at this.
>
>First question: what version of Gnucash are you using?  Everything I
>am about to talk about is in current CVS (and some are in later 1.7
>series releases)....
>
I think I mentioned in my original mail that I am using CVS from 
12282002 (looking back I actually did say so, but it was quite well 
hidden far down in the message, sorry about that).

>>Disclaimer: I have accounts (as in bank, expense, income) in three
>>different currencies, none of which are US dollars (which might be
>>important for a couple of observations that I'll make). My typical use
>>of these account relates to infrequent transfers between bank accounts
>>of different currencies and expenses and income payed out from/into
>>account of the same currency).
>>    
>>
>
>No, it shouldn't matter that you're not using USD...
>  
>
>>1) When specifying a transfer between two differently "currencied"
>>accounts using the "To amount" mechanism I expected that it would be
>>possible to go back and adjust one of the the sides independently of
>>the other. An example would be that I make a transfer of 10 Euro from
>>a euro account to a DKK account. In transfer dialog I specify 10 EUR
>>going out and in the "To Amount" field I specify 75 DKK (which most
>>often will be based on a guess, albeit a qualified one) coming
>>in. When my account statement show up later for the danish account, it
>>    
>>
>
>Question: is DKK a Euroland currency?  Based on your usage here I
>would presume not.  Sorry, I don't know which currencies are euroland
>and which are not....
>  
>
Nope, not yet at least ;-) Danes are somewhat reticent people (actually, 
I think they just did not want to get lumped in with europeans in 
general, but I have heard that now the Euro seems to be stabilizing 
nicely they want to get in ;-).

>>shows that actually my account has been credited with 70 DKK (they did
>>not offer the normal interbank  rate, they stole some money, the
>>transaction cost money, I had bad information, whatever). Now, I need
>>to adjust the DKK account to reflect this, and simply change the 75 to
>>70. However, gnucash at this point also changes the amount that I have
>>taken out of the EUR account to say 9 EUR instead of 10. But in my
>>opinion this is wrong. If I understand correctly the transaction has
>>been remembered by a calculated exchange rate instead of by the actual
>>amounts.  So one way of looking at this could be that transfers made
>>with "To amount" should be tagged as such and not recalculated when
>>amounts change on either side of the transfer.
>>    
>>
>
>No, that's not how it works.  When you create a transaction it
>determines the transaction currency (based on your default currency or
>the currency of the account), and then for each split it stores the
>split's amount (which is denoted in the split's account's
>commodity/currency) and the split's value (which is denoted in the
>transaction currency).  The exchange rate is the ratio between the
>amount and the value.
>
>When you view an account, all amounts are shown in that account's
>currency.  So, when you open your EUR account, all amounts are
>converted to EUR.  When you view your DKK account, all amounts are
>converted to DKK.  When you edit the amounts, it re-converts back as
>if all splits are in that currency; the amount-to-value ratio remains
>the same through all edits.
>
>What you want to do is "Edit Exchange Rate".  Select the transaction
>you need to change and then click on Actions -> Edit Exchange Rate.
>Then change the exchange rate to what you need it to be.  This will do
>what you want to do -- change the ratio between the "amount" and the
>"value".
>  
>
Now, this is exactly what I assumed gnucash was doing. However, my point 
is exactly that when the user specifies the transaction using the "To 
amount" method, he is really saying that it is not the exchange rate but 
the exact amount that matters. So when gnucash makes a "translation" of 
an amount relation to an exchange rate and then uses that for all 
subsequent recalculations, my opinion is that the spirit of the "To 
amount" method is violated.

I.e. when the user has specified the transaction using an exchange rate 
I find it perfectly reasonable that a change of either side of the 
transaction results in a change of the other, but when the "To amount" 
method is used I would prefer that the side that is changed changes, but 
leaves the other side unchanged. (I understand this might give 
interesting problems when the transaction has multiple splits, but it 
does not seem impossible to make it work as well e.g by simply leaving 
all the other amounts remain fixed (which would correspond to what I 
intend anyway)).

In synthesis, if the "To Amount" method is used to specify a currency 
transfer, a change of either side of the transaction should simply 
change _that_ amount and nothing else. No need for manually opening 
dialogs etc.

>>The only alternative method I can see to get my transaction right is
>>that I completely delete it when the statement arrives and then
>>reinsert it with the correct numbers (which is what I do for now).
>>    
>>
>
>You could do that, but you don't need to.  Just use the Edit Exchange
>Rate function to change it in-place.
>
I have found that dialog in the meantime, and I understand that I can do 
this. However, it does not really change my opinion about how this thing 
should work. But we can agree to disagree on this point !!

>>2) When making a transfer between two differently currencied accounts
>>from the ledger gnucash apparently automatically finds some old
>>exchange rate (probably from the pricedb, even though the price editor
>>it empty (but then I might have misunderstood the use of the price
>>editor)). IMHO it should at least be possible to configure a
>>preference that a) automatically brings up the transfer dialog
>>identical to the toolbar transfer button when making a transfer
>>between two accounts with different currencies or b) do as it does now
>>(even though I'm not really sure how it works, but it does not matter
>>too much for me as I probably would use the other method anyway).
>>    
>>
>
>I don't think I understand what you mean here.  When you are in the
>ledger and enter a txn between accounts of different currencies, it
>should pop up the exchange-rate editor (which looks a lot like the
>transfer dialog) for you to edit the exchange rate.
>
I did not get a transaction dialog as you describe, but then I was 
probably getting a quickfill result as it was a repeated operation. 
However, I think this is still unfortunate. In my opinion, when a 
transaction is performed between two accounts with different currencies, 
I think the transaction dialog should be opened unconditionally  (but 
this might be a result of my usage pattern, so perhaps a user preference 
could be made for this).

>Note that it is possible that what is confusing you is the register's
>quickfill system.  If that is what is happening, then yes, it will
>automatically re-use the previous exchange rate (filled in from the
>previous transaction) and you will have to manually change it.
>
>This may be considered a bug, but then again it may not.  If you are
>using the auto-completion to duplicate a transaction why should
>gnucash assume the exchange rate is different?
>  
>
Because exchange rates changes frequently ;-) Quickfill is just a 
convenience, not an accounting principle (not that I would recognize an 
accounting principle if it jumped up and bit me).

>>3) Reports:
>>    
>>
>[snip -- I'll leave this for another person/day]
>  
>
If you looked at these problems, you would probably understand that my 
assertion about US$ above made a minimum of sense ;-) However, what this 
basically boils down to is a bunch of problems with using locales for 
determining report currencies (I think there should at least be a user 
overrideable preference (I think locales might have some use, but apart 
from changing menu languages, formatting dates etc I can't really think 
of any now)), some reports are incomprehensible due to poor graphics and 
layout, and many of the report "page links" gives a "Badly formed 
options URL: report-idXXX" (which I think are real bugs).

In addition, I think the work flow of setting up some of the reports is 
simply wrong (see another earlier mail in this thread for more on that, 
the use of the toolbar Options button as an integrated part is particularly

Finally, there are a lot of unfortunately named menu points, options, 
page links etc (labels must be short, but also discriminating and 
informative, whereas many of the report labels are bland, forgettable or 
downright misleading). Disclaimer: I am not a usability expert although 
I have spent some time on the subject, and have some practical knowledge 
of the issue from dealing with our own clients ;-)

>>I have not been able to test the business reports !!!!
>>    
>>
>
>Any particular reason?  Or just lack of time?
>
I don't have any business transactions in my data (for now I am only 
using gnucash for my personal income and expense accounting).

All the best and happy new year

Jan