Identification of "School year"
In all systems up to FSM , the academic year lines up with the calendar year, so we can identify the year simply by the integer value 2015, 2016, 2017 etc.
In FSM, the school year cross calendar years, and is referred to as SY2015-2016, SY2016-2017 etc.
The situation is commonly encountered in financial systems that have to deal with varying tax years Apr-Mar, Jan-Dec, July-June.
2 issues: given that we do NOT want to change the data model to make svyYear as string, we need a rule to map the school year SY2016-2017 to a svyYear integer. ie should it be 2016, or 2017?
Second, we need a mechanism to convert an integer year into a string for reporting and presentation.
ISSUE 1: I propose that svyYear 2016 represent SY2016-2017 ie we use the calendar year of the START date of the school year.
ISSUE2: We introduce a Filter to render the year appropriately in the User interface. Some care over the semantics of "year" will need to be taken to decide in a particular case whether a year value means a calendar year, or should be trated as a "school year".
Comments (5)
-
-
ISSUE 1: this has since changed to be svyYear 2018 means SY2017-2018 for both RMI and FSM. The data was "fixed" to reflect this convention in both RMI and FSM.
ISSUE 2: is now high priority
-
- marked as critical
-
reporter ISSUE2: Implemented through a new angular filter, surveyYear. This relies on a sysParam, SURVEY_YEAR_FORMAT which is a template for the format. The template may contain these tokens:
yyyy : 4 digit survey year
yy : 2 digit survey year
nnnn : 4 digit next year
nn : 2 digit next year
e.g. token SYyyyy-nn for value 2015 produces
SY2015-16
This is incorporated into default school SurveyList.cshtml
For reporting it may be useful to get this conversion done in the server, in the recordset presented to the report.
For this you can use the Sql UDF common.surveyYearFormat
e.g.
Select common.surveyYearFormat(svyYear) surveyYear from SchoolSurvey
-
reporter - changed status to resolved
- Log in to comment
ISSUE 1: the way you propose it is how I always thought of it as well so no resistance here.
ISSUE 2: Sounds like a good approach.