trial balance - how to find mismatch question

[David Carlson]

Adrien, I think that you summarized the problem with "nearest in time"
nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
value to future prices.  You clarify that reports are often run "as of"
historical dates (and often need to match accounting reports submitted to
government agencies) thus could be exposed to erroneous values assigned
after the "as of" date by the "nearest in time" criterion.

Your final note that ideally the prices would always be downloaded on the
date they are needed for the report is true, but as a practical matter it
is sometimes difficult to do, as the prices are often posted on the
internet several hours after the respective closing bell, and now that the
F:Q module is sometimes unable to acquire some prices on the first pass, it
is sometimes problematic whether it has even succeeded in getting all the
needed prices.  If it is done by a chron job, the job would need very
intelligent error handling capability to be confident about success.

If a developer wanted to expand the scope of the price download module to
allow downloading "as of" prices for arbitrary historical dates, I think
many of us would buy him a beer.  Alas, right now I fear that the currently
active developers have too many other things on their plates.

David C


On Mon, Mar 5, 2018 at 4:36 PM, Adrien Monteleone <
adrien.monteleone at gmail.com> wrote:

> Wm,
>
> Consider the case of running a historical Balance Sheet for a date that
> falls on a market holiday that also falls on a weekend. The latest price
> prior to that holiday might be 2 days prior. The ’nearest price’ will be
> the day after the holiday. If Gnucash is pulling the day after price, it IS
> the ’nearest price’ to the target date of the report, but it is a ‘future
> price’ with respect to the report. Had you run the report on the actual day
> of the holiday, you’d get a different result. (the price from 2 days prior
> would be used)
>
> It isn’t that people are magically downloading prices from the future, but
> that the case of running a historical report might pull in a price that is
> closer to the report date, but actually in the future with respect to the
> report date that is the problem.
>
> If 2 days prior to the report, the market for silver closed at $16.50 and
> the day after the holiday, the market closed at $17.00 and GC used $17.00
> for the commodity price because it was only 1 day from the report date as
> opposed to 2 days, the report would overstate the assets by 3% as of the
> date of the report and be incorrect.
>
> Holidays alone aren’t the problem. It happens with respect to when you
> actually ‘get prices’. Perhaps the markets weren’t closed at all crossing a
> period boundary, and you routinely get prices on the first of the month.
> Running a Balance Sheet on any end of month day will always produce the
> wrong result. GC will use price on the day after the report, not the one
> before the report.
>
> What is needed here is a ‘latest price’ (as opposed to ‘most recent’ which
> is relative to the today’s date, not the report date) or else change/add an
> option for ’nearest in time prior’.
>
> In order to avoid this problem, one has to download on input prices for
> any specific day a report is run.
>
> Regards,
> Adrien
>
> > On Mar 5, 2018, at 4:08 PM, Wm via gnucash-devel <
> gnucash-devel at gnucash.org> wrote:
> >
> > On 03/03/2018 18:52, D via gnucash-devel wrote:
> >
> >> I think having nearest in time use future dates relative to the report
> date is not useful. Mind you, matching a broker statement for value (as
> opposed to holdings) is perhaps equally not useful.
> >> I guess I could see a point to a nearest in time using later dates (for
> example, when the date history is sparse, and the only earlier date is much
> earlier). But perhaps your suggestion of a separate setting would solve the
> dilemma.
> >
> > Where the heck do you get future prices from ?
> >
> > Seriously.  This is valuable information.  I want to know how you know.
> >
> > In any event, why aren't you telling gnc what it needs to know so it can
> multiply some numbers together?
> >
> > It is a *person* that says what a commodity was worth on a date not gnc
> after all.
> >
> > --
> > Wm
> >
> > never vote for a man that doesn't understand that imposing a tax on
> metal mauy work in the inverse to what he expects. duh
> >
> >
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>