> On Feb 16, 2018, at 12:20 AM, Adrien Monteleone <adrien.montele...@gmail.com> > wrote: > > At least on my version of the Trial Balance report, there is no ‘Imbalance > entry’ specifically. > > There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed > along with the others. > > There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have > the latter, even though the report duration was a single day with no price > changes, I gave up trying to figure that one out) > > The ‘imbalance’ I’m speaking of trying to resolve, or at least finally > attributed to a rounding error with the XAG account, was simply the > difference between what the report shows as Total Debits & Total Credits. > (note, these aren’t labeled as such on the report - but they appear at the > bottom, and that’s clearly what they are) There is no figure on the report > that shows this difference. I had to calculate it manually. When I decided to > audit the report for each account is when I found the foreign currency > account out of whack. The remaining difference was attributable entirely to > the ‘unrealized losses’ line. > > So, the full difference between debits and credi is the SUM of the > ‘Unrealized Gains/Losses’ line and the discrepancy due to rounding. > > At least in my case. > > So there are two problems with the report: > > 1) There should be no losses or gains if there were no trading transactions. > Certainly, this is impossible if there is only one day on the range of the > report and the price is the same. If all you have are opening entries and you > attempt to run a trial balance for that same day, you can’t have either a > gain or a loss, unrealized or not. > > 2) Because the Equity:Opening Balances account is the result of rounded > figures for each entry in a foreign currency, the report’s method of taking > the foreign currency ending balance as of a date and doing the exchange rate > calculation at the end, will always produce a discrepancy. The report would > have to sum the book-default currency amounts individually or somehow a > book-default currency balance would have to be maintained and that used > instead. Alternatively, a foreign currency account could use the same > precision as the foreign currency itself, thus removing the potential for > rounding errors if not eliminating them. > > Possibly, increasing the decimal places and re-entering the transactions for > the XAG account might resolve the rounding issue. (only because now the USD > amounts sum correctly to match since they don’t round enough) But then ALL > USD accounts would have this extra precision which is not desirable generally. > > The alternative would be to reduce the precision of the XAG account, but > again, that is undesirable for accurate tracking of ownership quantities of > the actual metal. (or currency if that’s the case) > > The per-account precision setting seems to only affect the default currency > for that account, in this case, XAG, not USD, which seems only to be > controlled by the book setting.
Adriene, Pay close attention to the price source on the Trial Balance report. The default value of “Nearest in Time” can produce anomalous results. Try “Average Cost”, but be mindful of https://bugzilla.gnome.org/show_bug.cgi?id=775368 <https://bugzilla.gnome.org/show_bug.cgi?id=775368>. The default precision (“smallest commodity unit” or SCU) for an account *is* the value for the commodity/currency in which it’s denominated. For most currencies that’s 1/100. Prices aren’t rounded by GnuCash, but the prices you get from Finance::Quote are, so if you have trades from before 2.6.12 (when GnuCash started entering calculated prices into the pricedb) or have replaced calculated prices with market prices then you’ll get a rounding error. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
