trial balance - how to find mismatch question
sunfish62 at yahoo.com
Mon Mar 5 21:08:33 EST 2018
> On Mar 6, 2018, at 4:27 AM, David Carlson <david.carlson.417 at gmail.com> wrote:
> 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.
Can you clarify the reports that you submit to governmental agencies that use market value? My government (the US) doesn’t require any reporting of asset market value that I am aware of. As far as I know, the only reporting that is required is actual, realized, gains—and not book value of holdings. And as far as I understand, GnuCash doesn’t use price db entries to track this information; the preferred methods (as outlined in various sources) is to enter the gains literally, based on the price entered and stored in the transactions.
> 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.
Here, I think you unwittingly point to a significant problem inherent in trying to track market value of even a moderate portfolio: there is no means of determining the effective valuation date. If, as Adrien points out, you retrieve prices monthly, then the values can be almost a month out of date. If, as you point out, some prices fail to update, then some may be from last week, while others from today. So, obtaining an accurate valuation is a significant challenge. Perhaps this suggests that the entire portfolio valuation proposal is quixotic in its goal of Absolute Valuation, and should be considered only as a rough guide at best?
> 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
More information about the gnucash-devel