Multi currency issues CVS 11/14/2002

[Derek Atkins]

Hi.

Most of this should be working now (in CVS, and in 1.7.5).  The actual
behavior is still a bit rough on the edges, but it should work now.
Can you please try it and let me know?

Thanks,

-derek

Jan Nielsen <nielsen@revicon.com> writes:

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

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