Re: [GNC] Decimal Precision Entering Mutual Fund Transactions
I have created Bug #798352 https://bugs.gnucash.org/show_bug.cgi?id=798352 Thanks, Robin On Sun, Oct 24, 2021 at 4:47 PM John Ralls wrote: > > > > On Oct 24, 2021, at 2:24 PM, Robin Chattopadhyay > wrote: > > > > Hi all- > > > > SETUP: > > Version 4.8 (plus the commit to fix Bug 798327) > > OS: Ubuntu 20.04 LTS > > > > SCENARIO: > > My wife recently started a new job where the 401k provider maintains the > > mutual fund positions at nine decimal places (and the price is two > decimal > > places precision). I set up the security with the fraction traded set to > > 1*10^9, I set up the account's fraction traded to 'Use Commodity Value' > > > > When entering a transaction into the register directly with the full nine > > decimal places, GnuCash cuts off the last digit and appears to only save > up > > to the 8th significant digit thus introducing a small (but annoying) > > position difference between my books and the recordkeeper. > > > > However, if I import the transactions from the OFX file downloaded from > the > > recordkeeper's website, the full nine digits are imported and displayed > in > > the register. > > > > Another related item is that the share amount displayed changes from 9 > > digits to 8 digits back to 9 when moving between transactions. For > example, > > a transaction with 4.008105604 shares shows 4.0081056 as long as that > > transaction has the focus. > > > > The workaround for now appears to only import transactions from the OFX > > file, which is fine but it does seem weird to have this inconsistent > > experience. > > > > I glanced through Register-related bugs but I didn't see anything that > > jumped out at me as an open existing bug that would explain this > behavior. > > (I'll concede that my search may have been lacking because previous > > discussion on this list related to precision and integer math have gone > > over my head) > > I can replicate that. The truncation happens when one tabs out of the > field, suggesting an off-by-one clamp the register somewhere. > > Regards, > John Ralls > > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Decimal Precision Entering Mutual Fund Transactions
> On Oct 24, 2021, at 2:24 PM, Robin Chattopadhyay wrote: > > Hi all- > > SETUP: > Version 4.8 (plus the commit to fix Bug 798327) > OS: Ubuntu 20.04 LTS > > SCENARIO: > My wife recently started a new job where the 401k provider maintains the > mutual fund positions at nine decimal places (and the price is two decimal > places precision). I set up the security with the fraction traded set to > 1*10^9, I set up the account's fraction traded to 'Use Commodity Value' > > When entering a transaction into the register directly with the full nine > decimal places, GnuCash cuts off the last digit and appears to only save up > to the 8th significant digit thus introducing a small (but annoying) > position difference between my books and the recordkeeper. > > However, if I import the transactions from the OFX file downloaded from the > recordkeeper's website, the full nine digits are imported and displayed in > the register. > > Another related item is that the share amount displayed changes from 9 > digits to 8 digits back to 9 when moving between transactions. For example, > a transaction with 4.008105604 shares shows 4.0081056 as long as that > transaction has the focus. > > The workaround for now appears to only import transactions from the OFX > file, which is fine but it does seem weird to have this inconsistent > experience. > > I glanced through Register-related bugs but I didn't see anything that > jumped out at me as an open existing bug that would explain this behavior. > (I'll concede that my search may have been lacking because previous > discussion on this list related to precision and integer math have gone > over my head) I can replicate that. The truncation happens when one tabs out of the field, suggesting an off-by-one clamp the register somewhere. Regards, John Ralls ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
[GNC] Decimal Precision Entering Mutual Fund Transactions
Hi all- SETUP: Version 4.8 (plus the commit to fix Bug 798327) OS: Ubuntu 20.04 LTS SCENARIO: My wife recently started a new job where the 401k provider maintains the mutual fund positions at nine decimal places (and the price is two decimal places precision). I set up the security with the fraction traded set to 1*10^9, I set up the account's fraction traded to 'Use Commodity Value' When entering a transaction into the register directly with the full nine decimal places, GnuCash cuts off the last digit and appears to only save up to the 8th significant digit thus introducing a small (but annoying) position difference between my books and the recordkeeper. However, if I import the transactions from the OFX file downloaded from the recordkeeper's website, the full nine digits are imported and displayed in the register. Another related item is that the share amount displayed changes from 9 digits to 8 digits back to 9 when moving between transactions. For example, a transaction with 4.008105604 shares shows 4.0081056 as long as that transaction has the focus. The workaround for now appears to only import transactions from the OFX file, which is fine but it does seem weird to have this inconsistent experience. I glanced through Register-related bugs but I didn't see anything that jumped out at me as an open existing bug that would explain this behavior. (I'll concede that my search may have been lacking because previous discussion on this list related to precision and integer math have gone over my head) ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
