BTW, quixotic, while based on the famous Don Quixote, is a non-proper (improper?) adjective, and thus does not need capitalization. Whether you pronounce it “key-hotic” or “quick-sotic” depends on your personal predilection, as I undetstand it.
David > On Mar 6, 2018, at 7:57 AM, David Carlson <david.carlson....@gmail.com> wrote: > > David T, I guess you do not have any IRA's or 401-K's as the IRS requires > every custodian to file either a "Fair Market Value" form or a form 5498 > which includes the fair market value for each account. The "as of" time is > calendar year end. > > When you turn 70-1/2 you get to take a "Required Minimum Distribution" each > year based on a formula outlined in Publication 590-B which uses the Fair > Market Value and an actuarial table. If you do not take the RMD, you pay a > fine and take it anyway. > > While I would not depend on GnuCash to make an accurate report without > checking on every part of the data that it used to make the calculation and > check it in an external spreadsheet where I can actually see every number, I > like to try to verify that my custodians used the method I think they should > use to calculate realized gains long and short where needed and to accurately > report FMV so that my RMD is correct. > > I did not intend to be unwitting about the problems with getting an accurate > balance report out of GnuCash, you are correct to call it Quixotic, and I > would capitalize that adjective, if it is one. In fact, I was trying to > underline some of the issues that I have personally experienced. > > David C > > On Mon, Mar 5, 2018 at 8:08 PM, David T. <sunfis...@yahoo.com > <mailto:sunfis...@yahoo.com>> wrote: > David Carlson, > > > On Mar 6, 2018, at 4:27 AM, David Carlson <david.carlson....@gmail.com > > <mailto:david.carlson....@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? > > David T. > > > > > > 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 > > > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
