> On Mar 11, 2017, at 3:26 AM, Geert Janssens <[email protected]> > wrote: > > On vrijdag 10 maart 2017 22:28:03 CET John Ralls wrote: >> Updated via https://github.com/Gnucash/gnucash/commit/3889606d >> (commit) >> from https://github.com/Gnucash/gnucash/commit/bc50f3da (commit) >> >> >> >> commit 3889606dd6779564341247ec796a905b54d36426 >> Author: John Ralls <[email protected]> >> Date: Fri Mar 10 13:21:02 2017 -0800 >> >> Bug 779217 - Transactions rounded to 5 decimal places when opening file. >> >> xaccSplitSetValue and xaccSplitSetAmount round to the denominator found >> by get_currency_denom and get_commodity_denom. The problem was that if the >> commodity was unfindable because either the splitâs parent or account >> hadnât been set (as is the case during loading, because the parent >> isnât yet complete) the returned denominator would be 100000, smaller >> than the max supported. That would cause the value/amount to be prematurely >> rounded. >> >> diff --git a/src/engine/Split.c b/src/engine/Split.c >> index 8d34c23..6ed3a4e 100644 >> --- a/src/engine/Split.c >> +++ b/src/engine/Split.c >> @@ -928,7 +928,7 @@ get_currency_denom(const Split * s) >> } >> else if (!s->parent || !s->parent->common_currency) >> { >> - return 100000; >> + return 1000000; /* Max supported denom to avoid premature rounding. > > How about defining this number in gnc_numeric and using this definition > everywhere the max supported denom is used ? > > Is this restriction the same in master ?
Geert, A large part of my motivation for rewriting the numeric code was to make enough headroom to expand it to 10^ for master in order to support Bitcoin and that looney mutual fund in Slovenia, and I think that it should be defined in GncNumeric. I'd like to make that a stand-alone commit in master rather than buried in a bug fix, which is why I didn't do it here. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
