[Gnucash-changes] r13199 - gnucash/trunk/src/app-utils - Change the reports from using a hard-coded fiscal year to using the global

[Derek Atkins]

Chris Shoemaker <c.shoemaker at cox.net> writes:

> On Sat, Feb 11, 2006 at 10:08:28AM -0500, Derek Atkins wrote:
>> A couple of issues with this change:
>> 
>> 1) I think users want the ability to report on both the "current"
>>    accounting period as well as the "previous" accounting period.
>>    This patch removes the ability to do that.
>
> It never offered an arbitrary "previous" accounting period.  Just
> exactly one year before the beginning of the hard-coded fiscal year
> start.  Now, users can set the accounting period to any arbitrary
> period, either the current or in the past, and use that interval for
> all reports.

Wait, so now I need to go into the Preferences every year to update my
"current accounting period"?  I don't like that.  I want to be able to
say something like "July 1 - June 30" and have the dates roll year to
year...  In which case having a "previous period" and "current period"
works just fine.  In fact, all you need to do is take the delta
between the period-start and period-end and apply it in reverse.

> If they want to run simultaneous reports using two different
> accounting periods its probably safest and most useful to make them
> choose the second interval explicitly in the other report.  I don't
> think we should try to guess when the previous accounting period
> started based on when the current one started - it's not reliable and
> it's just as easy for the user to set it explicitly and get exactly
> what they want.

Why not?  I think users expect a program to support two periods, the
current period and the previous period.  Yea, beyond that they should
set the dates.  But I think we should still have two.

>> 2) Users who had reports that had "current/previous financial year"
>>    set will now crash (or at least fail to load properly) because
>>    their option setting wont be available.  If we care about report
>>    migration from 1.8->2.0 we need to handle that somehow.  If we
>>    don't care then we just need to make sure that reports generated
>>    with this option in 1.8 don't crash during the migration to 2.0.
>
> I think the goal is that old reports don't crash new gnucash, but it's
> ok for a migrated report to either a) just not re-open or b) open with
> an error message, requiring the user to reset the options for that
> report.  I thought that this change fell into case b).

That should be fine.  I just wanted to make sure.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available