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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>
--
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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
