multi-currency transactions (was: problem with entering a stock transaction)
Derek Atkins
warlord@MIT.EDU
05 Jan 2003 11:16:40 -0500
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