GNOME Bugzilla – Bug 495137
Shares traded in foreign currency have zero value when transferring to account of same foreign currency
Last modified: 2018-06-29 21:54:05 UTC
Please describe the problem: I work principally in GBP, but I have some bank accounts in USD, and I trade shares in USD. If I buy or sell USD-traded shares and transfer the cash to/from a USD account, the balance of the USD account does not change. The register shows blanks in the deposit and withdrawal cells Steps to reproduce: 1. Create GBP account structure 2. Create USD bank account 3. Create Stock account on security NASDAQ/BRCM 4. Buy BRCM shares using funds in USD account Actual results: The USD bank account balance is not affected in any way by the purchase of BRCM shares Expected results: I would expect the purchase price of the shares to be withdrawn from the USD account Does this happen every time? Yes Other information: This bug existed in 2.0.5 This bug is reproducible in 2.2.1 in Linux and Windows
Created attachment 98791 [details] Example of foreign shares not affecting foreign currency bank account
Confirmed. I can reproduce this in 2.2.5.
It's very, very ugly but I think I've found a way to make this partially work. When you enter a transaction in a stock register, it's first important to recognize that all currency figures are in terms of your default currency (GBP in your example). Therefore the price per share should be entered in GBP. Then on the second split, enter the USD amount in the "shares" column, the GBP-USD exchange rate in the "price" column, then the total in the "sell" column. I said "partially work" above because once the transaction has been entered, you can't go back and change the amounts. The register won't allow it.
Actually, here's an even better way: make the parent account of the stock account denominated in the stock's settlement currency. For example: Assets:USD Investments:BRCM, where "USD Investments" is denominated in USD. Now when you enter the transaction in the stock account's register, all the currency figures are in USD, and the reporting works too! So I think that GnuCash can fully support what you are trying to do, but the practice of having the parent account denominated in the settlement currency is either unintended or not well documented (if at all). I'm not sure what the proper resolution is here. Do we need a code change, a documentation change, or both? Perhaps another developer can respond.
Aye, that seems to work. Thank you. I'd guess that the major thing should be documentation, but adding a bit of code to detect when this occurs (maybe using a knowledge of the currencies used by the major stock exchanges), alerting users to the relevant documentation would also be handy. Thanks again, Paul.
There is a note in gnucash-docs/trunk/guide/C/ch_currency.xml aka "10.6. Recording Purchases in a Foreign Currency (How-To)" about bug 335101 – Transfering money gives 0 in one account (non default currencies). No matter, it seems, I ran in this issue also. ;-)
For documentation, I see that the Tutorial and Concepts Guide shows foreign stock purchases being entered via the register of the account used to make payment (rather than the stock account's register). But that really isn't a warning against entering purchases in the stock register, and the section needs some updates anyway, so I will go ahead and make some changes. This bug is essentially a duplicate of bug 334255, but I think I will keep both open. We can track the immediate fix to the documentation at bug 334255, and track any code changes here, along with any necessary documentation once those code changes have happened.
The initial documentation fix has been committed as r17481 (see bug 334255).
*** Bug 574317 has been marked as a duplicate of this bug. ***
The workaround in comment 4 would be acceptable if it worked, but I've just confirmed that it does not work in version 2.0.5. Since the workaround works for Charles Day, perhaps it works in later versions. Version 2.0.5 is apparently unusable for foreign stocks. I would say with certainty that it's a bug that should eventually be fully corrected in the code. The workaround needlessly restricts users to structure their hierarchy in a way that may not come natural to them.
(In reply to comment #10) > ... that it does not work in version 2.0.5. Sorry, but the developement on the 2.0 branch stopped 3 years ago. That means, it is no longer supported. In 2.2.x were some other commodity related fixes, which could have an impact on this issue. Could you please update e.g. to the latest stable 2.2.9?
Created attachment 162290 [details] A fresh guncash file showing the problem
I didn't commit my comments on the previous submission; just wanted to say that the problem is still there in version 2.2.0 (This copy was built from r17949M on 2010-03-23.)
Sorry, I meant 2.2.9.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=495137. Please continue processing the bug there and please update any external references or bookmarks.