GNOME Bugzilla – Bug 775903
Lots feature: Base currency selection seems to be reversed when using lots for currencies
Last modified: 2018-06-29 23:52:33 UTC
Created attachment 341691 [details] sample GnuCash file reproducing the bug Situation: Base currency: USD Foreign currency cash account: EUR Steps to reproduce: 1. Create purchase/sell transaction in EUR account - from EUR account register 2. Go to "Show Lots" Observed behavior The free splits are shown with amount _and_ value both being reported in EUR. GnuCash is not able to "scrub" the account. Expected behavior: Free splits are shown with amount in EUR, and value in USD. Gnucash "scrub" function creates the lots as needed. Note: If the transactions are not created from the EUR account register, but from an USD register (into the EUR account), they will shown up correctly in the Lots dialog (with USD value as expected).
Created attachment 341692 [details] screenshot
I am having the same problem when using accounts with different currencies. My default currency is USD. Say I make a transaction from a USD account to an XTS account, then look at the transaction in the View Lots window from the USD account, and again look at the same transaction in the View Lots window from the XTS account. In the USD account, the transaction in the View Lots window will show both "Amount" and "Value" in USD, which seems wrong since there is a conversion taking place. However, in the XTS account the View Lots window will show the transaction with "Amount" in XTS and the "Value" in USD, which seems correct, since there are two currencies involved, therefore two different values for this transaction (the native USD value and the converted XTS value). The same behavior is happening when transferring from an XTS account to a USD account. The View Lots from the XTS account will then show Amount and Value as the same XTS amount/value (no USD value is shown), but the View Lots from the USD account will show Amount and Value as the corresponding USD/XTS values as expected.
The behavior is correct. Every transaction has a transaction currency in which "value" is denominated. In most cases that will be the currency of the account in which the transaction is begun; when using the Transfer dialog is will be the currency of the "from" account. So for every multi-currency transaction there will be a split in the "other" currency that represents an exchage and one in the transaction currency which does not.
Thank you, I was suspecting something like that. Unfortunately, this makes it impossible to use the Scrub Lots tool to calculate gains/losses in my default currency (USD), when the account I am entering transactions into is in a different currency (XTS). In a currency pair transaction like USD/XTS, a gain in USD would be a loss in XTS; and vice-versa. So ideally, gnucash would be able to calculate gains/losses regardless of which account/currency the transactions were initially entered into. But the current behavior does not allow this, as far as I can tell. As a workaround, I could enter the transactions in an account which uses USD as its currency, but this is counter-intuitive, as I would not be able to enter transactions directly into the account that I am keeping track of. Ideally it wouldn't matter which account the transactions are entered into, as long as it is a currency pair/trading transaction, I would like gnucash to be able to calculate gains/losses. Anyway, thanks for the confirmation of what I was suspecting.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=775903. Please update any external references or bookmarks.