multi-currency transactions (was: problem with entering a stock transaction)

[Derek Atkins]

Christian Stimming <stimming@tuhh.de> writes:

> Wow. Thanks a lot! This would've been the next issue on my list. Now that this 
> is fixed, the legacy 1.6-like currency exchange transactions should be 
> editable exactly like they've been in 1.6.x. Phew. This really solved a lot 
> of my concerns about the multi-currency handling. Again thanks.

You're welcome. :)

> As for the rest of the multi-currency handling: I would still propose to 
> introduce a constraint on multi-currency transactions: They should be allowed 
> to only contain at most two different currencies. With the exception that 
> each split that goes into a stock-/currency-account may add another currency 
> to that number. 

The problem is that this constraint is _pervasive_.  It means that any
time you tried to modify a transaction you would have to verify that
this invariant still holds (namely that there are exactly two
currencies, and that one of them is the txn currency).  I think this
kind of checking is WAY TOO HARD, and honestly it's not that hard to
support the general case.

OTOH, you are correct that a user may shoot themselves if they have a
multi-split, multi-currency txn and set the exchange rates
differently.

> That way, the "edit exchange rate" dialog only has to deal with one exchange 
> rate _per transaction_. (The exchange rate for any third/4th/... currency 
> will only be editable through its own stock-account register window.)

How is the register supposed to know _which_ currencies the
exchange-rate dialog is editing?

> The edit-exchange-rate dialog then knows the exact from-amount in currency A 
> and the exakt to-amount in currency B, and the dialog can offer to either 
> edit precisely this from-amount, or the to-amount, or the rate in between, 
> just like the stock-account register does. 

Christian, did you run the example that I suggested you run, where you
edit the amount field and then pull up the dialog.  Is that the
behavior you want?  If so, I can easily _make_ that the default
behavior...

> To reconcile the transaction, the dialog can follow the rule that if there is 
> only one split with that currency, changes to from-/to-amount directly apply 
> to that split, but if there is more than one split, the splits' 
> amounts/values are unchanged and the transaction is left imbalanced.
> 
> What do you think?

Right now the dialog is not touching the transaction at all.  All it
does is return a new exchange-rate which gets stored until you
actually "save" the transaction.  All the editing logic is in the
register (in particular split-register-model-save, in the
save_debcred_cell() and save_cells() functions).

The real question is: what does it mean to edit the exchange rate?
Are you trying to change the split's amount or the split's value?  I
think that is the key question.  It get's a but more complicated when
you are editing from the "other account", but the question remains:
which gnc_numeric are you trying to change, the split->amount or the
split->value?

Note that this _changes_ based on your view of the transaction.  Even
when you are looking at a basic ledger, you sometimes change the value
and sometimes change the amount based upon the current view.  But I
think we both agree that the way the basic-cell view works is
"correct", no?

I think the only thing we're talking about right now is how to deal
with expanded transactions.  In particular I think the key is whether
we are changing the amount or value of the current split.  In expanded
view I still maintain that it should NOT change anything in the
_OTHER_ split.

Currently I am assuming that when you Edit Exchange Rate you want to
change the split->amount.  The issue here is that what this does
VISUALLY is different based upon your view.  If you are viewing the
txn from an account that matches the txn->currency, then it will work
how I think you want it to (namely you wont see a change, but it will
change the numbers in the other account).  If you are viewing the txn
from an account that does NOT match the txn->currency, it changes the
amount in the current split (because you're viewing "modified"
numbers, and the modification factor just changed).  In both cases I
am changing the "split->amount", but the difference is what is being
viewed.

If you ALWAYS want the "former" behavior, regardless of view, then I
can do that.  As I said, you can see the behavior from the test I
suggested.  If that is the behavior you want, I can do that.  You have
yet to answer that, or even explain what kind of behavior you want to
see (other than trying to limit the functionality).

> Christian

-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