Multi currency issues CVS 11/14/2002

[Derek Atkins]

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.

> 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)

> 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.

> 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).

> 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).

> 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.
> 
> All the best
> 
> Jan

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available