Receivable Aging error

[warlord at MIT.EDU]

Quoting Charles Day <cedayiv at gmail.com>:

> On Fri, Aug 29, 2008 at 1:13 PM, <warlord at mit.edu> wrote:
>
>> Quoting Charles Day <cedayiv at gmail.com>:
>>
>>  At least for 2.2.7, I think I should change the reporting system back to
>>> using a default date of 'today'. For reports that allow you specify a date
>>> range, I will definitely keep the default start date as "beginning of
>>> period" (in 2.2.5 it was "beginning of year" which threw users with custom
>>> periods off), but I can change the end date back to 'today'.
>>>
>>> This will fix the immediate problem with the aging reports, though they
>>> probably would be better off making their own default instead of relying
>>> on
>>> the reporting system's default.
>>>
>>
>> I think there are two types of reports -- reports against the period
>> and reports-to-date.  I think we need to take a close look at each report
>> and determine which category it belongs in.
>>
>> The aging reports definitely belong in the reports-to-date category
>> so they should default to "today".
>>
>> The P&L definitely belongs in the report-against-period.
>>
>
> OK, so you're saying it is OK for the P&L to include future transactions by
> default. That's the way we have it now in 2.2.6.
>
> The 2.2.6 default is to treat every report as being in the "against the
> period" category. Reports that allow the user to specify a date range
> default to 'beginning of period' to 'end of period'. On reports that only
> let the user specify an end date, the default is 'end of period'.
>
> Since these defaults don't work for reports in the "report-to-date"
> category, like aging reports, how would you suggest fixing it?  It would be
> quite easy to treat reports that use a date range as
> "report-against-period", and all others as "report-to-date", but I don't
> know if that's quite correct. That would mean, for example:
> Default balance sheet: today
> Default income statement: period
> Default trial balance: period
>
> But there are some reports (and charts) that would not fit either of these
> categories, since they involve a series. For example, the Net Worth barchart
> is essentially a series of balance sheets. So even though its options
> involve a date range, I would think that the preferred end date would be
> 'today'.
>
> So it seems to me that reports could be categorized at least four ways:
> "range", such as income statement, where the user can specify a start and
> end date
> "snapshot", such as balance sheet, where the user specifies a single date
> "series of ranges", such as income and expense barchart, or a multi-column
> income and expense (if we had one), where the user specifies a start date,
> end date, an a step size
> "series of snapshots". such as net worth barchart, where the user specifies
> a start date, end date, and a step size
>
> Perhaps if we can decide on defaults for those four types (are there more?)
> then I could start coding something up.

I think each report needs to make its own choice.  I don't think you
can just make blanket statements based on the date input requirements.

For the record I think the Balance Sheet should also be "Period".  However
I also believe that the current Period implementation is broken because
you can ONLY specify exact dates and not rolling dates (see bug #547383
<http://bugzilla.gnome.org/show_bug.cgi?id=547383>).   That notwithstanding,
I think most reports are probably period-based but some exceptions should
be made and default to Today..  And those reports can know which ones
they are.

You, as a human, need to assess each report's requirements and needs to
decide which bucket.

I dont think there are four buckets, I still think there are only two:
Period and Today...   Keeping in mind the issues in bug #547383.
If you're going to modify each report you should add a "Previous Period"
setting as well.

-derek