GNOME Bugzilla – Bug 796527
invalid currency on scheduled transactions
Last modified: 2018-06-30 00:11:24 UTC
Whenever I create a scheduled transaction which involves a non-default currency, and then post an occurrence into the ledger, the currency conversion window pops up. A little investigation shows that both the scheduled transaction and the posted transaction are in the default currency (EUR). All the splits, however, are in another currency (USD). There is no way to adjust the currency of the transaction in the GUI that I know of. Based on the above, it seems that a transaction which is created through the Scheduled Transactions -> New option is using the default currency. The other transactions, which are created by first creating a ledger transaction and then selecting and using the option Schedule, seem to have the correct currency as they don't have the conversion dialog popping up when adjusting the amounts.
If the modification happens on the Search Results window, after auto-generating the transactions, it is not possible to get out of the edit mode as the conversion dialog keeps popping up.
The only solution to the above is to close the Search Results tab. Only then the prompt about discarding the transaction will be shown.
Yes, I can confirm that when a scheduled transaction is created from a ledger, the currency of that account is used. So, to explain the real case: my default account is Euro. I'm receiving a distribution in USD. If I create a new Scheduled Transaction from the Sch.Tx Editor, the transaction is linked to Euro commodity. It is possible to post it to an account. However, if one wants to modify the numbers, the conversion pops up, which is highly counter-intuitive at first sight. All the splits are in USD so it is confusing to see a conversion dialog. I can also confirm that if I - create a real transaction in the USD account, with the same USD splits as before, - create a scheduled transaction by using the Schedule option on this transaction the resulting Scheduled Transaction is in USD and creates no problems later on. Not sure what the best solution would be here. I'm wondering why the transaction has a commodity when splits can belong to accounts in different commodities.
Remember that every split has two numbers: an amount in the split account's currency and a value in the transaction currency. consider the possibility of a transaction with three splits, each of has an account in a different currency: How else besides a transaction currency could GnuCash decide in what currency to denominate the values of the split? Anyway, to the SX problem: As you've observed, interactively-created transactions adopt the currency of the register with focus at their creation, on the natural assumption that a user wouldn't create a transaction from a register if the register's account isn't going to be one of the splits. I haven't looked at the SX code yet, but it sounds like there being no register in focus when they're created that the transaction currency is set to the default currency. If that's the case it should be fairly simple to use the currency of the first split instead.
Hi, The suggested solution would probably work. I'm not sure if it would cover the scenario with multiple currencies, which you mentioned. This, however, is probably due to my misunderstanding of the problem. > How else besides a transaction currency could GnuCash decide in what currency to denominate the values of the split? I still fail to understand where does the need to select the currency for display of the values come from. I mean, doesn't the currency of the value come from the account to which the split is linked? Transaction, on the other hand, may contain splits that are linked to different accounts, and in different commodities (both currencies and others), so I somehow don't see the point of the currency on a transaction level. This, however, is irrelevant to the actual issue but I would appreciate some comments, just to enhance my GnuCash understanding in general. Thanks!
No, AMOUNT is in the currency of the account to which the split is linked. VALUE is the amount in the transaction currency in which the transaction is balanced. Price is amount/value. This isn't for display purposes, it's necessary to balance the transaction: One can't do that without converting all of the splits to a common currency.
Ah, I see. That complicates the case as there is no base account for Scheduled Transactions. A few interesting details - the real/posted transaction transaction can be created from a scheduled one. It obviously balances and passes the validation during creation (I enter the formula values for "amount", "tax", "amount-tax"). Once the transaction is edited, the pop-up appears. And even if the transaction balances (in USD) or the original number is restored, it still requires the entry of the exchange rate. Perhaps the problem is only this last part. But then it raises the question how did it pass the validation during creation? In any case, I don't expect to go too much into depth here. I will generate Scheduled Transactions from real ones to avoid any ambiguity. You should implement any correction you see fit within the various existing considerations. The fact that there is no similar bug probably means that not too many users ran into this issue so it is probably not a big deal at the moment. Cheers!
I'm going to go into depth anyway as notes to myself. It took a day to work this out and I need to write it down so that I remember to fix both parts. Also, maybe Geert will see it in bugmail and have some suggestions about how to proceed. If you save to XML so that you can see the structure of the data more easily and then look at a scheduled transaction you'll see that it doesn't have a list of transactions, it has an account. That is a "template account" that never shows up in the CoA; it's named with the guid of the SX. I think that if the template transaction is created from a regular transaction that it gets the regular transaction's currency--but the splits get the template account because that's how everything is associated with the SX. When the SX is created in the editor then the transaction gets the book default currency. Every split in every transaction belonging to that SX is in the SX's account with amount and value 0/1. The *actual* account and the credit and/or debit formulae are stored in slots. When the SX is "realized" into a real transaction by the SLR dialog a new transaction is created and the new splits have their proper accounts but the new "real" transaction inherits the template-transaction's currency. If a split account's currency differs from the transaction currency you get the Transfer Dialog to enter the exchange rate. OTOH, if you edit an SX created from a real one so that it has a non-default currency then when you go to commit your edits the register in the sx editor sees that there are splits with a currency different from the transaction's and puts up the Transfer Dialog to get a (useless) exchange rate. The sx editor's register creates the "blank transaction" when it's created because that's how the register works. There aren't any splits yet so it naturally uses the template account's currency. I think the place to adjust the transaction's currency is when the splits' accounts and amounts are moved to KVP and replaced. Then the register needs a flag to prevent it from popping the Transfer Dialog when the split account is a template account.
It turned out the register already had an is_template flag, so less surgery than I thought. This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
That's great news! Thank you, John. This will also come up in the next Windows nightly? I can also try it there, right?
Yes, it will be in tomorrow's nightly.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=796527. Please update any external references or bookmarks.