Receivable Aging error

[Charles Day]

On Fri, Aug 29, 2008 at 11:03 AM, Andrew Sackville-West <
andrew at swclan.homelinux.org> wrote:

> On Fri, Aug 29, 2008 at 09:07:50AM -0700, Charles Day wrote:
> > On Fri, Aug 29, 2008 at 8:24 AM, Andrew Sackville-West <
> > andrew at swclan.homelinux.org> wrote:
> >
> > > On Thu, Aug 28, 2008 at 08:16:31PM -0700, Charles Day wrote:
> > > > The problem is that users can set a custom financial year, which may
> end
> > > > before today. On the other hand, it seems obvious that the aging
> report
> > > > ought to be run with a default of ''today'.  So we'll have to change
> the
> > > > default end date back to 'today', or give the aging report its own
> > > default,
> > > > or perhaps try to get the best of both worlds by defaulting to
> 'today' or
> > > > 'end of financial period', whichever is earlier.
> > > >
> > > > I'm not sure which way to go.
> > >
> > > my .02 is that the aging reports should default to "today". The age of
> > > an invoice really has no meaning relative to some day other than
> > > today. At least for most cases I can think of. If someone needs to
> > > know who old invoices were a month ago or will be 3 months from now, I
> > > expect that they would expect to have to change the dates for that.
> > >
> > > So I say change the default for the aging reports only.
> > >
> >
> > Yeah, I think the aging reports should default to 'today' regardless of
> how
> > the accounting period is set. For other reports, I kind of like the idea
> of
> > making the date range end 'today' if the accounting period hasn't
> finished,
> > or the end of the period if it has. In other words, if the accounting
> period
> > has already finished, just report over the accounting period. Otherwise,
> > report period-to-date.
> >
> > But I'm not sure... When you run a balance sheet and the period hasn't
> ended
> > yet, is it preferred to use period-to-date, or the entire period? The
> latter
> > would include any future transactions entered for the period, whereas the
> > former would not.
>
> the accounting period is *never* over as one starts at the same moment
> one ends. So reporting on today, unless the accounting period has
> ended, is meaningless because a new accounting period will have
> started... if you follow me there. But maybe I misunderstand the way
> the accounting period works. Frankly, I've not looked at it all, even
> as a user.
>

Currently, to set a custom accounting period you must pick an exact date to
start and to end. So actually the accounting period can be over, and we
don't know the end date of the next one.

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 the right thing to do, for the aging reports only, at this
> point, is default to "today".
>
> As for the others, I just don't know either. I find, inevitably, that
> the default report date is *never* what I want. I just change it, and
> if it's a report I use lot (like previous month Income Statement) I
> just save it. shrug.
>
> A
>
> Cheers,
Charles