trial balance - how to find mismatch question

[David Carlson]

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 at 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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>