Multiple Currency Transactions

[Michael Culbertson]

Hello,

   Okay, I see now that the exchange rate in the dialog defaults to a
rate in the rate table.  But, there seem to be a couple of bugs in how
the exchange rate dialog display is handled.  Let me give you a few
senarios of the unexpected behavior I'm experiencing.  I'm using
GnuCash version 1.8.9.

  Consider three of my accounts: Assets (type ASSET, USD), Assets:Cash
(type CASH, USD), Assets:Euro (type CASH, EUR).  I open the
Assets:Euro account register in Auto-split Ledger mode.

1. I press tab 6 times to move to the Debit field of the first split
and enter 10.
2. I press tab 4 more times to move to the Account field of the second
split, and Assets:Euro is automatically filled in for the first split.
3. I enter Assets:Cash for the second split, which already has the
balancing 10 in the credit column, and press enter to record the
transaction.

Here I would have expected the exchange rate dialog to pop up, but it
doesn't.  The transaction is recorded.  If I open the Assets:Cash
account, I see that the exchange rate information has not been
adequately processed since the values in the debit and credit columns
are empty and the balance remains unchanged.  The same thing happens
if I press tab to move to the blank split before pressing enter to
record the transaction.

  If, on the other hand, I start with the USD split (still in the
Assets:Euro register), the following happens:

1. I press tab 5 times to move to the Account field of the first split
and enter Assets:Cash.
2. I press tab 2 times to move to the credit field and enter 10.
3. I press tab once to move to the next split, and the transfer dialog
box pops up.
4. I enter 1 EUR = 1.22 USD and click OK.
5. I press tab 2 times to move to the account field of the second
split and enter Assets:Euro.
6. When I tab to the blank split (or press return to record the
transaction), the first split's account is changed to Assets:Euro.

Now the transaction is all messed up.  The net effect of the erroneous
transaction is to decrease the balance on the Assets:Euro account by
2.20 (credit of 10*1.22, debit of 10).  I think I noticed this kind of
behavior (changing the first split account to that of the open
register) long ago,
but I guess I've just been working around it.

  I can get something close to the desired behavior if I go through
these steps, though:

1. Press tab 6 times, enter 10.
2. Press tab 4 times, enter Assets:Cash.
3. Choose Actions->Edit Exchange Rate from the menu.
4. Enter the rate and click OK.
5. Record the transaction.

But, this has to be done for each and every foreign currency split in
a given multi-split transaction, even if the foreign currencies are
the same.  I can perhaps see why you would want to verify with the
user that the stored
pricedb exchange rate is valid for each transaction by displaying the
dialog with the default value, but shouldn't the exchange rate be the
same for different accounts with the same currency within the same
transaction?

  There's a more complicating factor.  If I press tab between steps 2
and 3 above when the transaction I'm editing is the first after
opening the register window and there are no prices in the price
database, the account
field of the second split is cleared and the cursor jumps back to the
transasction description field after the exchange rate dialog box is
closed.

  It seems to me that, assuming you want the user to verify the
exchange rate for each transaction, the transfer dialog should pop up
automatically and once for each foreign currency involved in the
transaction, no matter the number of splits in that currency.  Is
there a bug in the code
determining when the dialog should be displayed, or am I still not
understanding how these sorts of transactions were intended to work?

  Then there's something more on top of this.  If a new exchange rate
is entered for a second transaction on a given date, the new rate
isn't entered into the price database, and the default value for
subsequent transactions
is still the first rate entered on that date.  Why bother forcing the
user to verify the exchange rate for multiple transactions on a given
date if any updated information isn't stored in the price database for
future use?

Thanks for you help in working through these issues,
Michael Culbertson