Receivable Aging error

[Charles Day]

On Fri, Aug 29, 2008 at 11:28 PM, Charles Day <cedayiv at gmail.com> wrote:

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

Derek, don't worry about the sample data. I made some. I have already
committed the fix for the aging reports as r17483.  -Charles


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