I am not sure where Wm is going with his comments but I can state that I just ran the Trial Balance report in GnuCash release 2.6.18, which is not quite the very latest release available but is a known reference point.
I changed the report dates to start at the beginning of last year and end at the end of last year, otherwise I left all other settings at their default. The Commodity Price Source defaulted to Nearest in Time. It happens that there is 500 shares of AT&T (T) stock in this data file and there are prices in the database for Friday December 29 2017 ($38.88) and Tuesday January 2 2017 ($38.54). Given those numbers, the Trial Balance Report puts the value of those shares at $19,270.00. My year-end brokerage statement put the price at $38.88 for a value of $19,440.00. I think that the report should match my brokerage statement. Now it happens that the discrepancy comes from the report's selection of nearest in time as the price source, and the fact that GnuCash chose the January 2 price rather than the December 29 price. On January 30, 2015 I reported https://bugzilla.gnome.org/show_bug.cgi?id=743753 pointing out this behavior in Gnucash suggesting that the nearest in time criterion should not select future dates. That bug report applied to release 2.6.5 and as of today it still has a status of "New" If this criterion with it's current behavior is the desired behavior, I assert that there should be another criterion "last price on or before" so users can make their GnuCash year end reports match their brokers statements without fudging prices in their data files. David C On Sat, Mar 3, 2018 at 6:11 AM, Wm via gnucash-devel < gnucash-devel@gnucash.org> wrote: > On 16/02/2018 11:24, Christopher Lam wrote: > >> I like the way this is going. Please describe or file minimal data file >> cases in Bugzilla. Perhaps I'll be able to decode the trial balance and we >> can decide then what it should really do. >> > > It is possible I've missed a detail but in RL a TB should only be for > *one* currency or commodity or for many if they are each indicated. > > It is near impossible to reconcile a multi-variate TB because the > underlying values are changing as you attempt it. > > The reconciliation of the separate bits can involve thinking but is the > sensible approach. You take a view about values either before the TB > reconciliation or after, some governments have rules about this, etc. > > I don't know anyone that does a multivariate [1] TB and expects it to > balance live [2]. > > I pull the TB's for each class and give them to the people to reconcile, > at the end we put them together. I suggest you try this approach. > > I'm surprised and mildly disappointed JohnR has found it necessary to > contribute to this thread. I think he has better things to do. > > [1] more than one commodity / currency / something that changes during a > minute / hour / day / week / month. > > [2] not a joke, I don't think big banks do it and they are way ahead of > little people like you or I. > > -- > Wm > > never vote for a man like Trump if you believe in honest accounting, he > can't add up :) > > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel