Multi currency issues CVS 11/14/2002

[Jan Nielsen]

Hi Derek,

Thanks for your patience; I have actually read through the bugzilla database to 
some degree but it is not always easy to see that the behavior seen is already 
described.

> Jan Nielsen <nielsen@revicon.com> writes:
> 
> 
>>Hi,
>>
>>A few observations about problems seen using the new multicurrency
>>handling in CVS as of Nov 14.
>>
>>I have only tested these things with bank accounts, but I assume that
>>simular things exist with other types of accounts.
> 
> 
> Yep.

Okay
> 
> 
>>1) Transferring from e.g a EUR bank account to a DKK bank account
>>using the register directly does not seem to work correctly. I would
>>assume that gnucash should realize that two accounts with different
>>currencies requires special handling and should open a transfer window
>>to specficy exchange rate or amount in target account (at least this
>>is what Quicken does in this case).
> 
> 
> This is a known bug (see # 97690)

Good
> 
> 
>>2) Transferring from e.g a EUR bank account to a DKK bank account
>>using the transfer button in the toolbar correcly opens the transfer
>>dialog and allows for    setting up the transfer correctly. However,
>>in the destination account the transaction amount is the origin amount
>>(in this case in EUR), but the balance is in the destination currency
>>(as expected). I would expect that all amounts in the destination
>>account would be in its currency. An example would be
>>
>>EUR account
>>
>>Date 		Description	Transfer       Debit    Credit     Balance
>>11/13/2002 .................................................         30.00
>>11/13/2002 Tx DKK               Bank DK         10.00                20.00
>>
>>DKK account
>>
>>Date
>>11/13/2002 ..................................................       100.00
>>11/13/2002 Tx DKK               Bank EUR                  10.00     175.00
>>                                                           ^^^^^
>>3) As observed earlier, the entry currency for a bank account should
>>be forced to match the account currency, where now it seems to follow
>>the locale and/or the the gnucash preference setting.
> 
> 
> The problem is that a _TRANSACTION_ has a "common currency".  That
> means each _SPLIT_ must be denoted in the _same_ transaction currency
> (there is no way to denote multiple splits in the same currency).
> What you see here is correct.  You have a 10EUR transaction where you
> obtained 175DKK.  So, this transaction is absolutely correct.  The
> only problem is that there is no way to _denote_ the fact that the
> transaction (credit) is in Euro.

I am not sure that I follow the reasoning here, but anyway. My concern is that 
when my DK bank sends me an account statement, they are most certainly not going 
to tell me that I deposited 10 EUR. They will tell me that I deposited 75 DKK. 
So reconciling the danish account is going to be a nightmare where _I_ will have 
to subtract the running balances to see whether I got it right (or whether they 
did). I agree that the transaction is correct, but in my opinion the danish 
account should _show_ the (known) danish counter value of the 10 EUR (and only 
the danish counter value). Again this is what Quicken does in this sort of 
situation.


> 
> 
>>4) A couple of minor things not related to currency handling: the
>>calendar view in the register is now always shown correctly. It seems
>>to follow this pattern: An entry is made into the register. A new
>>entry is created; when clicking on the calendar view for this new
>>entry, the calendar comes up blank but can be "repainted" by moving
>>the mouse over the dialog. Changing the calendar month repaints it
>>correctly at this point.
> 
> 
> Also a known bug (although I can't seem to find it in bugzilla).
> 
> 
Okay

>>5) Entering a "stored transaction" (ie. a previously used combination
>>of description and transfer) works correctly and the register is
>>updated correctly with the new balance and a new entry ready to
>>use. Entering a "new transaction" with a new description, transfer and
>>amount behaves differently. Hitting enter at this point does not have
>>any effect at all, whereas hitting tab updates the balance; neither of
>>these actions creates a new empty transaction.
> 
> 
> I'm not sure about this bug... Some of this was fixed yesterday, but
> I'm not sure what you mean here..  I _think_ you mean that when you
> autocomplete a transaction it works fine, but entering a new transaction
> isn't working correctly.  If that is true, then I think you need to
> CVS update again because I believe this has been fixed (late yesterday).
> 

You got the interpretation right. I guess I have to study a bit of terminology 
before making a fool of myself here again ;-) I'll give it a new try tonight to 
see if this has changed.

> 
>>It might very well be that this is the same effect that has been
>>observed by others in recent messages, and that the problem has been
>>fixed.

Thanks

Jan
-- 
Jan Nielsen
Revicon Srl, Via G.T.Invrea 14/2, 16129 Genova, Italy
Phone: +39 010 530 3700 Fax: +39 010 5760224
E-mail: nielsen@revicon.com