multi-currency transactions (was: problem with entering a stock transaction)
05 Jan 2003 11:16:40 -0500
Christian Stimming <email@example.com> 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
> 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
> 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
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
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
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
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).
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