trial balance - how to find mismatch question

[Adrien Monteleone]

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