CVS update: gnucash/src/register/ledger-core

[Derek Atkins]

David Hampton <hampton@employees.org> writes:

> On Tue, 2002-12-24 at 06:46, Derek Atkins wrote:
> > Note that when the user types 1000 into the Amount field and "1.56"
> > into the "price" field (which is exactly how it is labeled), it will
> > show you the "641.02" in the "To Amount" field, which is exactly what
> > gets posted in the transaction.
> 
> Which confused me as well as the poster of the bug report.

Fair enough...

> > In what way did you change the logic in the xfer dialog (other than
> > the fact that the dialog denoted the price, not the exchange rate)?
> 
> Well, I obviously had to change the division to multiplication. :-)

Well, yea, if you're going to change from a price to an exchange rate..
But that will be confusing for stock transfers...

> The pricedb is now populated from the exchange rate field instead of
> calculating it at the last moment.  The first time I tried the transfer
> dialog I entered an amount of $10.00 and an exchange rate of 1.556, but
> what got put into the pricedb was an exchange rate of 1.542.  Not what I
> entered.  Turns out the precision of the computed exchange rate was
> affected by the size of the amount transferred.  Better to just take the
> value out of the exchange rate field. (If the user entered an exchange
> rate, you get their exact number. If they entered an amount, you get the
> result of the same calculation as before, only its already been
> computed.)

This sounds reasonable...

> I changed code to update the pricedb to check for an existing exchange
> rate entry on the day of the transaction, not at the exact second of the
> transaction.  This prevents multiple entries for the same exchange rate
> on the same day.

Please revert this -- I did this for a reason.  Right now, all txns in
one day have the same Timespec, but in the future if we support a
timestamp I want to allow support for multiple exchange rates in one
day.  Right now it should do the right thing with my old code because
all txns in one day have the same timestamp, so it should do the same
thing as your code, but down the road when we support a time-of-day
for a txn I want the behavior I had before.

> I added non-editable fields showing how the number in the exchange rate
> field applies to the two currencies. I.E.
> 
> 	Exchange Rate: 1.556
> 	1 CAD = 1.556000 USD
> 	1 USD = 0.642675 CAD

Cool!

> > I was very careful to test this with all different sorts or scenarios
> > when multi-currency transactions and editing the transactions and
> > exchange rates from different accounts...  Did you make sure it all
> > still works and "does the right thing" in all cases?
> 
> I tested my default currency to/from another currency A, my default
> currency to/from a different currency B, and currency A to/from currency
> B.

So you did try from both registers?  And did you change the value in
the amount field and the exchange rate at the same time?  Just trying
to make sure.  Thanks...

> > Another thing to note is that checking the forward and reverse
> > exchange rates is a Bad Idea, because they MAY be different.  For
> > example, go to a bank, ask to exchange $1000USD to CAD; they've give
> > you, say, $1560CAD.  Now get back in line and ask to exchange that
> > back to USD, and they'll probably give you something more like
> > $990USD.... 
> 
> Not what I'd consider doing for fun. :-)  This is more likely because
> the bank is charging a fee for each transaction (built into the rate)
> than it is the actual exchange rates differ.

True, but the fee is hidden in the exchange rate.  That's why I consider
them different.  USD->CAD != CAD->USD.

> >  The order DOES matter, which is why I had that extra
> > logic in there....
> 
> This was a user convenience. If you know the exchange rate in one
> direction, then you know (or approximately know) the exchange rate in
> the other direction.  What's the likelihood that users are going to want
> to transfer money to/from the same currency in the same day?  (Is there
> a currency trader in out midst?)

There may be a currency trader in our midst.  I don't know, but why
eit them if you don't have to?  In general the register as it was would
do the right thing and assume the "right" currency.

> David

Thanks,

-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