Receivable Aging error

[Charles Day]

On Fri, Aug 29, 2008 at 3:59 PM, <warlord at mit.edu> wrote:

> 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.
>

So would you suggest leaving the defaults as "period" (so that most reports
don't need to set their own default) and treat the rest of the reports as
outliers that do their own defaulting?  Or do you prefer to see all reports
do their own defaulting regardless?

I haven't looked at bug 547383 yet, but it sounds like it a fix for that
could be done separately. If 2.2.7 will be released shortly, at least there
should be enough time to patch the aging report. Since I'm unfamiliar with
the business reports, could you tell me which ones need to run as 'today'?
Also, I don't think I have any business data to work with, so I can't test
those reports once the changes are made. Is there a sample file somewhere
that I could use?


> 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
>

-Charles