After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 406127 - Multi-currency transactions can result in incorrect decimal places displayed (and used in calculations?)
Multi-currency transactions can result in incorrect decimal places displayed ...
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Register
2.0.x
Other All
: Normal normal
: ---
Assigned To: David Hampton
Chris Shoemaker
Depends on:
Blocks:
 
 
Reported: 2007-02-09 16:00 UTC by Chris Bracken
Modified: 2018-06-29 21:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of unselected split (13.65 KB, image/png)
2007-02-09 16:01 UTC, Chris Bracken
Details
Screenshot with split selected (14.73 KB, image/png)
2007-02-09 16:01 UTC, Chris Bracken
Details

Description Chris Bracken 2007-02-09 16:00:09 UTC
Please describe the problem:
When a transaction is entered with splits to accounts of currencies with different "smallest fraction" values, the "smallest fraction" of the transaction currency is used even in the account of the other currency.  Selecting the split seems to result in the number being truncated to the number of decimals of the transaction currency.


Steps to reproduce:
1. Create a new file with default currency Japanese Yen
2. Use the simple Simple Checkbook default account setup
3. Create a Canadian Dollar bank account under the Current Assets account (alongside the Checking Account)
4. Open the JPY account, enter a transaction for 10000 JPY mapping to a value of $90.40 in the Canadian account.
5. Jump to the Canadian account.
6. Show splits for the transaction (in the Canadian account)
-- The transaction line shows 90.40 but the splits show 90.4
6. Select a split.
-- The value in the split line changes from 90.4 to 90.00
7. Unselect the split.
-- The value in the split goes back to 90.4
8. Close the account windows - go to the Accounts tab.
9. Note the balance against the "Current Assets" account is -44 yen, when it should be 0.


Actual results:
The value in the split line doesn't show the full decimal places expected for a CAD transaction.
The value in the split line changes from 90.4 to 90.00 (drops decimal place values) when the split is selected.

Expected results:
I would expect the split to always show 90.40 when viewed from the CAD account, and the two sides of the transaction to balance to 0, rather than -44 JPY

Does this happen every time?
Yes

Other information:
While I did not see it in this case, it seems this might affect the Balance Sheet report as well; I see this in my own accounts.
Comment 1 Chris Bracken 2007-02-09 16:01:09 UTC
Created attachment 82229 [details]
Screenshot of unselected split
Comment 2 Chris Bracken 2007-02-09 16:01:37 UTC
Created attachment 82230 [details]
Screenshot with split selected
Comment 3 Chris Bracken 2007-02-11 15:35:12 UTC
After looking at the raw data file, it appears that because the transaction currency is JPY, the splits on the CAD side are displaying with no decimal places (as JPY amounts do).  If I change the transaction currency from JPY to CAD, everything is calculated correctly, but the JPY-side splits display with the two decimal places associated with CAD.
Comment 4 Frank H. Ellenberger 2008-08-13 22:08:26 UTC
I think, I can confirm this as one aspect of the investigations on bug 547335.
Comment 5 John Ralls 2018-06-29 21:26:06 UTC
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=406127. Please continue processing the bug there and please update any external references or bookmarks.