|
|
|
|
This section is written for specialist staff with the responsibility for setting up and maintaining the institution's calendars. The following is assumed:
In this section:
Calendars are a pivotal component of Callista. They provide a framework upon which most other Callista data is reliant. Calendars control the display of data, the timing of processes and the extraction of data by jobs and reports. They are also building blocks in the creation of other data.
The basics of calendar administration take place within the Calendar subsystem, but certain aspects unique to other subsystems are maintained from within those subsystems. Individual institutions determine how responsibility for calendar administration is distributed. It is possible that a calendar administrator would have responsibility for maintaining calendars across all subsystems. At the other extreme, subsystem specialists could be given responsibility for the maintenance of calendars associated with their particular subsystem. In any event, it is recommended that an individual be assigned to oversee the calendar subsystem. Considerable dialogue needs to occur between subsystem specialists and the calendar specialist to ensure that calendar solutions are devised which do not compromise any functionality and existing or future data integrity.
Documentation of this subsystem assumes that an individual is responsible for setting up calendars for all subsystems. An exemplar university is used to illustrate recommended and tested set up methodology.
In this section:
Detailed discussion of calendars in individual subsystems is provided in the documentation for those subsystems. Refer to the Table of Contents.
The initial set up of the Calendar subsystem involves making it ready to record data about specific calendars. It requires the creation of a small set of reference data. This reference data is then used in the definition of calendars and date aliases required by other subsystems. It is recommended that wherever possible, institution defined reference data values be identical to system values. The following table details the required reference data. Further information is provided for each maintenance form. Follow the links.
|
Reference Data |
Purpose |
Mandatory ? |
Maintenance Form |
Pre-requisite Setup |
|
System Calendar Status |
Mapped to Institution defined calendar statuses which are then assigned to calendar instances to indicate the 'state' of the calendar. Values are: ACTIVE - applies to calendar instances that are currently in use. PLANNED - applies typically to calendar instances which are not yet in use. This is normally during the setup or rollover phase of a calendar. However, some PLANNED calendars can be 'used'. E.g. a PLANNED graduation calendar can be used to create a graduation ceremony round. INACTIVE - applies to calendar instances which are not currently in use but which have not been permanently closed to future use. |
System defined |
Not user maintainable. |
none |
|
Calendar Status |
Institution defined values that indicate the 'state' of calendars. Each institution defined value must be mapped to a System Calendar Status to provide functionality. For example, the institution may wish to use CURRENT as a calendar status rather than the System value ACTIVE. CURRENT must however be mapped to ACTIVE to provide system functionality. Each calendar instance is assigned a calendar status (in CALF0220). |
Yes |
none |
|
|
Calendar Category |
System defined classification of calendars (and optionally date aliases) indicating the function to which each applies. They are applied to calendar types in CALF0220 and optionally to date aliases in CALF0420. Linking a date alias to a particular calendar category restricts the use of instances of the date alias to calendars in the same category. |
System defined |
Not user maintainable. |
none |
|
Date Alias Category |
Institution defined classification of date aliases. Being institution defined, they are not critical to system functionality. They can be used to identify date aliases as being applicable to particular functions. Initially, the set of date alias categories could be set up as identical to the set of calendar categories. Each date alias must be assigned a date alias category (in CALF0420). |
Yes |
none |
The Data Dependencies diagram graphically represents the relationships between calendar reference data and calendar details.
Calendar types and instances of calendar types are set up using CALF0220. Recommendations about how calendars should be set up occur throughout the calendar (and subsystem) documentation. The start and end dates of most calendar instances are not functionally significant, however, the recommendations for particular calendars should be noted. Calendars of particular calendar categories must have alternate codes recorded against them in order for other System functions to operate. For example, the display/selection of a course commencement period in a number of forms requires that academic calendars and admission calendars each have alternate codes recorded against them. Recommendations about alternate codes, and the calendars that require them, are made throughout the Special Topics section.
The relationships between calendars are maintained using CALF0330 (best accessed through CALF0220). Links are made between previously created calendar instances. Recommendations about required calendar relationships are made throughout the Special Topics section. Maintain Calendar Instance Relationships contains a table describing permissible calendar relationships. The following diagram graphically illustrates these relationships.
About this diagram:
Date aliases are created using CALF0420. Instances of a particular date alias may be created and linked to the calendar instances in which they occur using CALF0511 (accessed via CALF0420).
An alternative approach (where required date aliases are created as a preliminary step, using CALF0420) is to use CALF0512 (accessed via CALF0220 in the context of a single calendar instance) and create instances of the existing date aliases related to a specific calendar instance.
A date in Callista can be specified in terms of its relationship to another date. The time difference between the two dates is called the 'offset'. For example, institution policy may be that the final date for receipt of admission applications is 14 days after the due date for receipt of applications. Rather than creating fixed instances of both dates in each admission calendar in Callista, the final date for receipt of applications could be defined as being offset 14 days from the due date. The application due date would be manually recorded for an admission calendar. When an instance of the final application receipt date is recorded for the admission calendar its date would automatically be derived as 14 days after the application due date.
Using CALF0420, offsets can be used to define date aliases, so that when the two date aliases involved occur in any one calendar and a date is recorded for the offset date alias, the other date alias's date is automatically calculated and entered.
Using CALF0512 (accessed via CALF0220), an offset can be used to define a particular date alias instance in a particular calendar instance. The two dates involved can be in different calendar instances of different calendar type.
Offset constraints work in conjunction with date alias and date alias instance offsets to ensure that a particular date alias instance, defined by an offset, either will or will not fall on specified days. Callista calculates the date based on its offset and if the calculated date falls on a day or within a period recorded as a constraint, Callista adjusts the date until an unconstrained date is achieved. The number of days and the direction in which adjustments take place can be set. For example, the constraint HOLIDAY MUST NOT -2 would mean that a calculated date falling on a single date recorded in a Holiday calendar would be adjusted backwards two days to resolve the conflict.
Offset constraints can be set against date aliases in CALF0442 (CALF0420 > CALF0442) or against date alias instances in CALF0520 (CALF0220 > CALF0512 > CALF0520 or CALF0420 > CALF0511 > CALF0520).
Two date aliases, or date alias instances, can be related as a pair, effectively defining a period of time. The period of time is inclusive of the two dates. Date alias pairs are created in CALF0420. Date alias instance pairs are created in CALF0512 (CALF0220 > CALF 0512).
As at Callista release 2.1, the only application of this functionality was to define institution breaks by pairing two dates within a Holiday calendar. Institution breaks may be specified as offset constraints.
Most dates in Callista are user definable. To enable Callista to recognise the date aliases chosen by institutions to represent critical dates, the date aliases must be identified to the System. This is required in a number of subsystems and is identified as a requirement in their documentation. A typical example is Enrolment Calendar Configuration, performed in ENRF01F0.
With calendar reference data established, the calendar subsystem is used to set up the calendars that support functionality in other subsystems. Calendars should be set up initially for one academic period. The Calendar Rollover Process provides an efficient mechanism for creation of calendars for subsequent academic periods.
Calendars should be built up, subsystem by subsystem, as required. Functionality in one subsystem may require the existence of calendars in another subsystem.
There is no required order of set up. This will depend on the subsystems being implemented. However it is recommended that a sequence similar to that outlined in An Approach to Setting Up Calendars be used. There are some data dependencies that rely on the existence of specific calendars. For example, units are offered in particular teaching calendar instances. To set up a curriculum, the required teaching calendars must be established first. Another example is the pre-enrolment process, which requires not only admission calendars but also enrolment, teaching and academic calendars to have been established.
Assuming that the institution has determined the calendars it requires, the following are typical steps in recording this information (for a particular calendar category or subsystem) in Callista.
This section provides a quick reference for the initial set up of subsystem calendars and can be used as a checklist. Each category of calendars is discussed in greater detail in the Special Topics section. Calendar set up for particular subsystems is discussed in detail in each subsystem section of the manual.
Create a calendar type for academic calendars (e.g. ACAD-YR) and an instance of this calendar type (e.g. ACAD-YR 01/01/1999 31/12/1999) for one academic period (Calendar category = ACADEMIC).
Create a unique calendar type for each of the institution's teaching periods that commence in the previously recorded academic period. (Calendar category = TEACHING). Create the instance of each calendar type commencing in the academic period. Typical examples of calendar types might be SEM-1, SEM-2, SUMMER1, YR-LONG and S1-E1 (representing a teaching period commencing in semester 1 and finishing at the end of semester 1 of the following year). These codes are determined by the institution. Teaching periods in subsequent academic periods will simply be new instances of the same calendar types.
Link each teaching period to its superior academic calendar(s).
The institution must first determine whether separate research calendars are required or whether the set of teaching calendars will suffice. Research calendars are merely an additional set of teaching calendars and hence are also of calendar category TEACHING. Set them up as for teaching calendars, including linking to academic calendars. Typical research calendar types might be RES-1, RES-2.
Create a unique calendar type for each enrolment period in the academic period (Calendar category = ENROLMENT). Create the instance of each calendar type relevant to the academic period. Link each enrolment calendar instance to the superior academic calendar. Create date aliases for each of the configuration dates in ENRF01F0 (refer to Enrolment Calendar Configuration for details). Record these date aliases in ENRF01F0. Determine the requirement for instances of these date aliases and create instances of each required date alias in the previously created academic, teaching, research and enrolment calendar instances, where appropriate.
Create a unique calendar type for each admission period relating to the previously created academic period (i.e. targeting teaching periods within the academic period), noting that any single admission period can only target one enrolment period. ). Create the instance of each calendar type relevant to the academic period. Link the admission periods to the superior academic period. Link each admission period as a subordinate to all the teaching periods that it targets. Link each admission period to its single subordinate enrolment period. Create date aliases for each of the configuration dates in ADMF02R0 and record them in ADMF02R0. Create instances of the configuration date aliases in each admission calendar (academic calendar for completion date aliases).
Configuring Admission Calendars describes these processes in greater detail.
The requirements for establishing load calendars should be studied carefully. Whilst it is possible to provide general guidelines for creating load calendars, their flexibility means that individual institutions may wish, or need, to use them in diverse ways. Load calendars used for attendance type and point-in-time load calculations may be established as an initial exercise. The need for other load calendars may only become apparent as the establishment of calendars in other subsystems proceeds.
Create standard load calendars. Each load calendar within the academic period must have a unique calendar type (Calendar Category = LOAD). Create instances of each calendar type required in the academic period. Create aggregate load calendar instances where this is a known requirement and link each aggregate load calendar to its subordinate standard load calendars. Link load calendars to other calendars as required. All load calendars should be linked to their superior academic calendar. Link enrolment calendars to their subordinate load calendars to facilitate enrolment and encumbrance checking.
Teaching calendars are linked to standard load calendars in ENRF01K0. This linking apportions the load from teaching calendars between load calendars. Follow the instructions in Student Load Structure and Management to set up load apportionment. Aggregate load calendars are not linked to teaching periods. They 'collect' load from their subordinate standard load calendars.
Load calendars are linked to government semesters, for government reporting, using STAF1340. Government reporting can utilise standard or aggregate load calendars.
Create a unique calendar type for each assessment period in the academic period (Calendar category = ASSESSMENT). Create an instance of each calendar type relevant to the academic period. Link each assessment period to a single (single is recommended) superior academic calendar and its subordinate teaching calendars.
Create a unique calendar type for each exam period within the academic period (Calendar category = EXAM) and create the instance of each calendar type within the academic period. Link each exam calendar to the superior academic calendar and to the subordinate teaching calendars with units that will be examined during the exam period. Create a unique date alias for each day within an exam period on which exams will be held. If generic date aliases such as EXAM-DAY1, EXAM-DAY2 etc. are created they can be re-used in other exam periods in this and other academic periods. Create instances of each of the date aliases to represent the examination dates within the exam periods. Note: the start data for an examination calendar instance must be a Monday if ETI is used.
Create a unique calendar type for each progression period within the academic period (Calendar category = PROGRESS) and create the instance of each calendar type within the academic period. Link the progression calendars to their superior academic calendar. Link each progression calendar to the subordinate teaching calendars in which course and/or unit attempts might be considered by progression rules. A progression calendar can be linked to a single subordinate load calendar where attendance type related rules are required. Perform system wide progression calendar configuration. Create date aliases for each of the required configuration dates in PRGF2100 and record them in PRGF2100. Identify System progression calendars by recording them in PRGF2100. Create instances of the configuration date aliases in each progression calendar. Optionally perform progression calendar configuration at an organisational unit and/or course version level in PRGF2300 and PRGF2200 respectively.
Progression calendar set up is described in more detail in the Progression subsystem sections Setting Up Progression Date Aliases and Setting Up Progression Calendars.
Create a unique calendar type for each graduation period within the academic period (Calendar category = GRADUATION) and create the instance of each calendar type within the academic period. Create an institution defined date alias category (in CALF0410) to which graduation date aliases must belong (e.g. GRAD). Create the required graduation date aliases and instances of each date alias in each graduation period.
Graduation calendar set up is described in more detail in the Graduation Specialist Overview.
Create a financial year calendar type and the instance of the calendar type which starts in the academic period (Calendar category = FINANCE). Create a unique calendar type for each fee period in the financial period (Calendar category = FEE) and create the instance of each fee period within the financial period. Link the fee calendars to the superior financial year calendar. Create an institution defined date alias category (in CALF0410) used to classify date aliases in the student finance subsystem (e.g. FEE). Create the required student finance date aliases. A set of instances of these date aliases must be created in each fee calendar to enable functionality.
Student Finance calendar set up is described in more detail in the Student Finance Specialist Overview.
Create one or more calendar types representing the holiday calendars required by the institution and create the holiday calendar instances which commence in the academic period (Calendar category = HOLIDAY). Link holiday calendars to the superior academic calendar. Create an institution defined holiday date alias category to classify date aliases related to holiday calendars (e.g. HOLIDAY). Create date aliases representing single day holiday events, the start of holiday periods and the end of holiday periods. Pair holiday period start and end dates. Create instances of the date aliases in the previously created holiday calendar(s). Once established, holiday calendars provide the opportunity to record offset constraints against date aliases and date alias instances in other calendars.
Create user defined calendar types and their instances, as required (Calendar category = USERDEF). Link to other calendars as required. Date alias instances can be created in user defined calendars but will have no system functionality.
Calendar Quality Check
Run the Calendar Quality Check report (CALR0100) during (if required) and at the conclusion of calendar set up sessions, to check for set up problems.
|
Calendar Date Report |
A list of date alias instances for selected combination of date alias category/cal type/cal status/date/sub cal/date range
|
|
|
Calendar Quality Check Report |
This report is used to identify potential calendar related problems that cannot be validated through the various forms
|
|
|
Date Alias Instance Report |
A list of date alias instance details for selected combination of cal cat/cal status/cal type/date alias/date alias cat/date range combination. Option to include offset and pairs details.
|
|
|
Rollover Calendar Report |
A report detailing the new calendar instances, their relationships and the new date alias instances created as a result of running the Rollover Calendar process from CRSF0220. Exceptions are recorded for those values for which rollover could not be completed successfully.
|
Calendar rollover describes the process of automatically creating new calendars based on existing calendars. The Rollover process is performed for a particular calendar instance, using form CALF0320. The existing instance is selected, the start date of the new instance is entered, Callista calculates the end date of the new instance, and selection of the Rollover Calendar button causes the rollover to be performed.
Performing a single rollover not only rolls the existing calendar instance, but also:
The Calendar Rollover process enables the institution to set up calendars and calendar related data for one academic year and, potentially, roll much of this data into subsequent academic years simply by rolling the academic calendar instance. It also allows a rollover to be performed, a new subordinate calendar to be added to the pre-existing structure, and the new calendar to be rolled subsequently, creating a link to the previously rolled superior.
There are many issues involved in the calendar rollover process. Refer to the Calendar Rollover Issues section.
The Calendar Rollover report (CALR0320) is an integral part of the rollover process. It captures details of the new calendar instances and their relationships and the new date alias instances. Exceptions are reported for those calendars/dates that could not be successfully rolled. The report is checked to resolve the exceptions and to determine the calendars and dates that require changes.
The Rollover report should be printed as soon as the process has completed, as subsequent changes to the database may make it impossible to accurately reproduce the report later.
The rules associated with the calendar rollover process are primarily concerned with how it handles calendars of different calendar status, how it handles missing data and how anomalies are treated. Rollover Calendar Instance contains full details.
The Calendar Rollover process rolls calendars and associated dates. Typically, the rollover of a calendar also rolls over subordinate calendars from other subsystems. Some calendar related data in particular subsystems is not rolled with the calendars to which it is related. Each subsystem where this is an issue is discussed below.
Courses are offered in particular academic periods and units are offered in particular teaching periods. In order to roll the institution's curriculum from year to year, the target academic calendar and teaching calendars must be created. Rolling over an academic calendar also rolls over teaching calendars. Course offering patterns are then rolled over to the new academic period using CRSJ0010. Unit offering options are rolled over to their new teaching periods using CRSJ0020.
Rolling over admission calendars does not roll over the admission period category/process/course offering restriction details attached to admission periods. Rolling this data requires that course structure rollovers are performed first. This is to enable rolled over admission period course offering option restrictions to be created to the new course offering options (in ADMF2M61). The rollover of admissions data can be performed for individual admission periods in ADMF2M61 or for all admission periods in an academic period using the batch process ADMJ2M63. For more detailed information see the Admissions Specialist section.
The rollover of Student Finance fee structures depends on the prior rollover of financial and fee calendars and associated date aliases. Rollover is normally performed on a yearly basis, potentially by rolling over a finance calendar, which also rolls its subordinate fee calendars. The rolled calendars and dates are checked and adjusted where necessary.
There are many issues that impact on the calendar rollover process.
The automatic process will roll almost all of an institution's calendars from one year to the next by simply specifying the academic period, but only where the target academic period does not already exist. Academic periods may need to exist beyond the current year for various reasons.
Example 1
Future academic period must exist in order for admission applicants to defer admission to a later period. The recording of teaching calendars that straddle academic periods requires that both academic periods exist. This means that to perform an automatic rollover of all related calendars, it is likely that this will have to take place for academic calendars a number of years into the future.
Example 2
If the institution allows admission deferral for twelve month periods, and the current year is 2000, the academic calendar for 2001 must exist. Rollover from 2000 to 2001 should have been performed in 1999 at the latest. Rollover from 2001 to 2002 should be performed in 2000 at the latest.
Institutions may choose not to perform a bulk rollover two or three years in advance. In this case, the target academic period may already have been created. Rollover must then be performed on calendars subordinate to academic calendars. This option should be thoroughly investigated, prior to performing any rollover activity, to determine the effects of rolling different calendars in the structure. The alternative is to create the future calendar structure manually.
Calendar Rollover will not create a new calendar instance if an identical one already exists. If future calendars have been manually created, performing an automatic rollover will not roll an existing calendar that corresponds to one of the future calendars, nor will it roll any calendar structure subordinate to the corresponding existing calendars.
Consider also a situation where future calendars have been created, and had their start and/or end dates slightly modified so that they differ from the current year's calendars (a highly likely scenario). A rollover is performed on an existing superior calendar. Callista checks that no calendars identical to the old calendars exist, and creates new instances of the old calendars. Two instances of almost identical calendars would now exist. Not only that, the automatic process will have created any subordinate calendar structure and date aliases under the newly created calendars.
The following is a typical (though hypothetical) example of the possible problems when some calendars are manually created and others are subsequently rolled over.
The 2001 academic calendar instance already existed and therefore could not be used to roll teaching periods from 2000 into 2001. The decision was taken to create the teaching periods manually. After reviewing the start and end dates of the 2000 teaching calendar instances, most 2001 instances were created with start and end dates one or two (because of the leap year) days earlier (so they would start and end on a Monday and Friday as did the 2000 instances). Later in the process, the decision was made to roll an exam calendar (e.g. EXAM-S1, the semester 1 exam period). This calendar is superior to a number of teaching calendars (e.g. the semester 1 and year-long teaching calendars). The EXAM-S1 rollover attempts to roll the subordinate teaching calendars from 2000 to 2001. If the process finds a 2000 calendar instance with identical start and end dates it does nothing and moves on. However we have changed the start and end dates. The process assumes (understandably) that a further instance of each calendar type is required, and creates it. As a result, two instances of each teaching calendar exist (e.g. SEM-1 01/01/2001 29/06/2001 and SEM-1 03/01/2001 30/06/2001). The first created manually with the preferred start and end dates and a second and unwanted instance created by the EXAM-S1 rollover.
Teaching periods are subordinate to academic, assessment, examination and progression calendars. Any of these superior calendars could have been chosen as the vehicle to roll teaching calendars, with the same consequential issues.
Once created, unwanted calendars must be manually 'unpicked'. This is laborious and difficult. In the previous example, just one of the unwanted teaching calendars could involve at least one superior calendar relationship, many child and grandchild subordinate calendar relationships (and potentially many unwanted subordinate calendars) and numerous date alias instances. The date alias instances themselves may involve offset relationships which have to be converted to absolute dates and then deleted one by one.
In the example above, problems could have been avoided by ensuring that all calendars had been rolled (albeit in a piecemeal fashion) before the start and/or end dates of any of the rolled calendars was changed.
A rollover of the entire calendar structure provides an excellent base structure in which calendars can be modified as necessary for the target academic period. A piecemeal rollover, or a manual approach, can involve far greater amounts of manual set up and consequent risk.
It is recommended that:
|
|
Academic calendars (Calendar category = ACADEMIC) do not belong to a particular subsystem. They are used to represent (typically) twelve month business periods of the institution. A typical Southern hemisphere academic calendar might be ACAD-YR 01/01/2000 31/12/2000, while in the Northern hemisphere it might be ACAD-YR 01/07/2000 30/06/2001. The institution determines how its academic calendars are set up, according to its annual cycles. It is possible to have more than one series of academic calendars (each series having a different calendar type), to cater, for example, for an offshore campus which operates according to academic periods which are different to those of the onshore campus(es). Academic calendars from different series (different calendar type) can overlap or be entirely concurrent. Academic calendars with the same calendar type should not overlap. Each academic calendar must have a unique alternate code.
Academic calendars are used throughout Callista. Their most important direct use is in forming part of the definition of course offering instances. That is, courses are offered in particular academic periods. This allows a course to be offered for a defined period. For example, a course could be offered in 1998, 1999, 2000 and 2001 only.
Also of importance is the status of academic calendars, being superior to most other calendars. The rollover process creates a new instance of a calendar from an existing instance. It also rolls calendars that are subordinate to the existing calendar. Rolling an academic calendar is the most efficient way of rolling the entire calendar structure from one year to the next. There are, however, many issues relating to rollover which should be understood prior to using this function.
Academic calendars are important for providing links to other calendars, being superior to most calendars. These relationships are used by Callista to determine valid data entry, data to be displayed in lists of values, data to be included in reports and data to be processed by certain jobs. For example, the course offering patterns available to applicants for admission are those offered in the academic period to which the admission period is related.
A number of date alias instances are required in academic calendars in order to enable functionality in various subsystems. These date aliases are discussed in following sections dealing with specific subsystem calendars.
Consider an exemplar institution where the academic year parallels the calendar year and where initial calendar setup is taking place for the year 2000. An academic calendar is set up by creating a calendar type ACAD-YR with a calendar category ACADEMIC. An instance of the calendar type is set up with a start date of 01/01/2000, an end date 31/12/2000, a status of ACTIVE (because this is an initial setup) and the default alternate code 2000. An instance of ACAD-YR is also created for 2001 (start date 01/01/2001, end date 31/12/2001, alternate code 2001), to allow linking of teaching periods which start in 2000 and end in 2001. (refer Teaching Calendars example)
Teaching calendars do not belong to a particular subsystem. They are used to represent the teaching periods of the institution. Typically this will mean semesters, trimesters or terms, although institutions may need calendars for summer semesters and other short non-standard teaching periods. For example, SEM-1 01/01/2000 30/06/2000 could be used to represent semester 1, 2000. SUMMER 03/01/2001 20/02/2001 could represent a summer semester in 2001. Note that two or more teaching periods can run concurrently.
Teaching calendars are used directly in the Course Structure and Planning subsystem. A teaching period forms part of the definition of a unit offering pattern. That is, units are offered in particular teaching periods. In this way, for example, a unit may be offered in semester 1 and summer semester, but not in semester 2. The institution's curriculum cannot be set up in Callista without first establishing the relevant teaching calendars.
A student's course attempt status is derived from a combination of the teaching period start date and the existence of one or more enrolled units.
The relationship between student unit attempts and the teaching periods in which they are being studied is the basis of many functions throughout Callista. For example, the relationships between exam calendars and teaching calendars allow Callista to identify the units and unit attempts to be examined in particular exam periods.
Every teaching calendar must be assigned an alternate code. This code should be as short as possible, meaningful and unique to a calendar type within an academic period. Alternate codes are used throughout Callista but most particularly in Enrolments and Admissions where they simplify data entry and display. For example, SEM-1 in any academic year could be given the alternate code 1.
Every teaching calendar must be assigned an ARTS code. Sites which do not use ARTS codes, should close any existing ARTS codes and create or modify a suitable dummy code (say 9, NOT APPLICABLE) in ADMF02Q0, and assign their teaching calendars this code.
Teaching calendar instances are linked to academic calendars to identify the academic periods in which they operate. A standard semester teaching calendar is linked to a single academic period. A multi-semester teaching calendar, such as S1-E2 (starting semester 1 in one year and ending in semester 2 of the following year) is linked to both of the academic periods in which it operates. A number of Callista functions rely on the relationship between academic and teaching calendars, both directly and indirectly. These include:
Teaching periods are related to appropriate admission periods. For a particular admission period, the units for which applicants may apply are those offered in the related teaching periods.
In the Assessments subsystem, teaching calendars are linked to relevant assessment periods in order to group them. The assessment periods are used as job and report parameters, allowing jobs to be run for a group of (rather than individual) teaching periods.
Teaching calendars are also linked to examination calendars in Assessments. Callista determines which student unit attempts should be considered for exam timetabling purposes by selecting unit attempts in teaching periods related to the selected exam period(s).
Each teaching calendar is linked to one or more progression periods so that Callista can determine which teaching periods and hence which unit attempts to consider when measuring a student's progress.
Every teaching calendar must contain a Census Date. The actual date alias instance in each calendar is determined according to the DEST specification for census dates. Census dates are used directly in Callista for government reporting, encumbrance checking, fee calculation and unit discontinuation. They may also be used indirectly by using the census date alias to represent other calendar configuration date aliases and by offsetting other dates from census dates.
Date alias instances required by other subsystems must also be included in teaching calendars. These dates are defined as part of the calendar configuration of those subsystems.
The following table shows the typical teaching calendars required for the exemplar institution, for a single academic period. A unique calendar type is required for each teaching period commencing within an academic period. Corresponding teaching periods in subsequent academic periods are simply new instances of these calendar types. Each calendar type is assigned the calendar category TEACHING. Each teaching calendar must be linked to its superior academic calendar(s). This means that for most teaching periods that straddle academic periods, both academic periods must exist. The exceptions to this rule are some short teaching periods that straddle academic years, such as those involving summer semester (SS) in the table below. These should be linked only to the later academic period. (Refer to Statistics Pre-requisites - Calendar Structure for more information.)
|
Teaching Calendar Instance |
|
|
||
|
Calendar Type |
Start Date |
End Date |
Superior Academic Calendar(s) |
Teaching Period Description |
|
S1-E1 |
01/01/2000 |
30/06/2001 |
2000, 2001 |
Starting semester 1 and ending semester 1 of the following year |
|
S1-E2 |
01/01/2000 |
31/12/2001 |
2000, 2001 |
Starting semester 1 and ending semester 2 of the following year |
|
S2- E1 |
01/07/2000 |
30/06/2001 |
2000, 2001 |
Starting semester 2 and ending semester 1 of the following year |
|
S2-E2 |
01/07/2000 |
31/12/2001 |
2000, 2001 |
Starting semester 2 and ending semester 2 of the following year |
|
SEM-1 |
01/01/2000 |
30/06/2000 |
2000 |
Semester 1 |
|
SEM-2 |
01/07/2000 |
31/12/2000 |
2000 |
Semester 2 |
|
SS-E1 |
27/11/2000 |
30/06/2001 |
2001 |
Starting summer semester and ending semester 1 |
|
SS-E2 |
27/11/2000 |
31/12/2001 |
2001 |
Starting summer semester and ending semester 2 |
|
SUM |
27/11/2000 |
28/02/2001 |
2001 |
Summer semester |
|
YR-LONG |
01/01/2000 |
31/12/2000 |
2000 |
Year-long teaching period |
Load calendars are used in:
Specific uses are:
Through their relationships with other categories of calendar, they are a mechanism for determining if, and how, load incurred by student unit attempts should be considered in the above situations.
Some load calendars are created specifically for point-in-time load and attendance type calculation. Others are created for specific fee calculation circumstances or for specific use by the Progression subsystem. Load calendars are assigned the calendar category LOAD. Where required, the load from a number of standard load calendars can be consolidated by an aggregate load calendar. Load calendars can be concurrent. Concurrent 'point-in-time load/attendance type' load calendars may be required where 'non-standard' (i.e. non-consecutive) teaching periods are used. 'Other, specific purpose' load calendars are normally concurrent with ' point-in-time load/attendance type ' load calendars.
Essentially, 'point-in-time load/attendance type' load calendars are set up to correspond approximately to the 'standard' teaching periods of an institution. The need for an exact correlation is determined by, for instance, how the institution views or calculates attendance and load across teaching periods, and how teaching periods relate to reporting periods. A teaching period can span one or more load calendars by virtue of the ability within Callista to apportion load from a teaching calendar to multiple load calendars.
Specific 'Fee' load calendars are required where there is no 'point-in-time' load calendar covering a period over which a fee is assessed. For example, a fee that is assessed on an annual basis may require a year-long load calendar, whereas 'point-in-time' load calendars may exist which correspond to the teaching periods semester 1 and semester 2. Specific 'Progression' load calendars are required where progression is determined over a period which is covered by more than one 'point-in-time' load calendar. In this case, the progression load calendar can aggregate load from the 'point-in-time' load calendars.
Each load calendar is linked to one superior academic calendar. This relationship is used by government reporting (Statistics subsystem) to derive a student's attendance type for the submission year.
Teaching calendars are linked to load calendars for government reporting and EFTSU calculation purposes. A teaching calendar can be linked to more than one load calendar in order to distribute the load attributable to unit attempts undertaken in the teaching period. A simple example is of units in a year-long teaching period contributing half their load to a semester 1 load calendar and half to a semester 2 load calendar.
The exemplar institution set up 'point-in-time' load calendars corresponding exactly, in a one to one relationship, to its standard teaching calendars. (I.e. LOAD-CAL1 01/01/2000 30/06/2000, LOAD-CAL2 01/07/2000 31/12/2000 etc.) It also created load calendars to collect load from non-standard teaching calendars. The following table shows the set of load calendar instances for 2000 and the teaching calendars that contribute load (through load apportionment) to them.
|
Load calendar |
Contributing Teaching Calendar(s) |
|
LOAD-CAL1 01/01/2000 30/06/2000 |
S1-E1 01/01/1999 30/06/2000 34% |
|
LOAD-CAL2 01/07/2000 31/12/2000 |
S1-E1 01/01/2000 30/06/2001 33% |
|
LOAD-SUMM 26/11/1999 27/02/2000 |
SUM 26/11/1999 27/02/2000 100% |
These three load calendars can be used for the point-in-time calculations of load and attendance type required by the exemplar institution. I.e. at the semester 1 and 2 census dates and for the summer teaching period.
Other essential information is available in:
Admission calendars represent the periods of time when admissions are processed for particular broad intakes of students. For example, an admission period ADM-PER-1 could represent the period during which admissions are processed for courses commencing at the start of the academic year. ADM-PER-2 could represent the processing period for an intake of students commencing courses mid-year, and so on. A single admission period relates to a single enrolment (or intake) period although two or more admission periods can relate to the same enrolment period.
Every admission calendar must be assigned an alternate code. This code should be as short as possible, meaningful and unique to a calendar type within an academic period. Alternate codes are used throughout Callista but most particularly in Enrolments and Admissions where they simplify data entry and display. For example, ADM-PER-1 in any academic year could be given the alternate code 1.
Enrolment Calendars further explains the admission calendar - enrolment calendar relationship.
Each admission period must be linked to a superior academic period. This link allows Callista to identify which academic year the admissions period applies to and hence the available course offerings for the admission period.
Admission periods must be linked to related teaching calendars. Teaching calendars are superior to admission calendars. This linkage allows Callista to identify the unit offerings available to an admission period. For example, a mid-year admission period is relevant to unit offerings in semester 2 but not to those in semester 1 or year-long teaching periods.
Each admission period is linked to one enrolment period. The pre-enrolment process uses this relationship to determine the enrolment period into which admission applicants must be enrolled.
For full Admissions functionality, it is necessary to set up a number of institution defined date aliases so they are recognisable by the System. Institution defined names are given to critical Admission events using ADMF02R0. When the System encounters one of these date aliases, specific functionality is triggered. For example, a date alias must be set up to represent the Offer Response Date. If an applicant does not respond to an offer before the System encounters this date alias, the offer lapses. The section Maintain Admission Calendar Configuration (using ADMF02R0) describes set up of these date aliases fully.
More detailed information about configuring admission calendars is provided in Configuring Admission Calendars. It is most efficient to create admission calendars for one academic period and then use the Calendar Rollover Process to create the admission calendars in future academic periods.
For academic year 2000, our exemplar institution has three student intakes; at the start of the year, mid year and prior to summer. As a consequence, three enrolment periods are required, say ENR-PER-1, ENR-PER-2 and ENR-SUMMER. The dates defining enrolment calendar instances, although not critical, are chosen to represent the actual periods during which enrolment activities take place. An admission period is set up corresponding to each enrolment period (ADM-PER-1, ADM-PER-2, ADM-SUMMER). The dates defining admission calendar instances are arbitrarily set the same as the corresponding enrolment calendar dates, to easily identify the relationship. Note, it is likely (and quite acceptable) that some dates associated with an admission calendar may be outside the calendar's start and end dates. The following table shows the admission/enrolment calendar relationships and the teaching periods targeted by each admission/enrolment period. The institution has determined which teaching periods students may apply for admission to, in a particular admission period.
|
Admission Period |
Enrolment Period |
Target Teaching Periods |
||||
|
Calendar Type |
Start Date |
End Date |
Calendar Type |
Start Date |
End Date |
|
|
ADM-PER-1 |
01/09/1999 |
31/03/2000 |
ENR-PER-1 |
01/09/1999 |
31/03/2000 |
SEM-1, SEM-2, YR-LONG, S1-E1, S1-E2, S2-E1, S2-E2 |
|
ADM-PER-2 |
01/04/2000 |
31/08/2000 |
ENR-PER-2 |
01/04/2000 |
31/08/2000 |
SEM-2, S2-E1, S2-E2 |
|
ADM-SUMMER |
01/09/1999 |
31/12/1999 |
ENR-SUMMER |
01/09/1999 |
31/12/1999 |
SUM, SEM-1, SEM-2, YR-LONG, SS-E1, SS-E2, S1-E1, S1-E2 |
Enrolment Calendars (Calendar Category = ENROLMENT) define the discrete periods during which the institution's enrolment processing takes place. Enrolment periods are set up to represent the periods when commencing students are enrolled and when continuing students are re-enrolled. Enrolment periods can be concurrent to cater for different cohorts of students. For example, commercial client students may be subject to different enrolment deadlines to those for typical undergraduates. Concurrent enrolment calendars could be created to allow a different set of date aliases to be applied in each calendar.
It is recommended that the start date of an enrolment calendar approximate the date on which enrolment processing commences and that the end date approximate the anticipated date by which enrolment processing will be completed.
The primary purpose of enrolment calendars is as a framework for the pre-enrolment process. Pre-enrolment of an admission application when an offer is made can only occur when the admission period has been linked to the target enrolment period. The ongoing processing of the enrolment is then influenced by date aliases associated with this enrolment period.
Each enrolment calendar must be linked to a superior academic calendar to identify the context academic period for the pre-enrolment process. As mentioned, a link must also exist between an admission period and the subordinate enrolment period to which its admission applications apply. More than one admission period can target the same enrolment period.
Each enrolment calendar must be linked to its subordinate load calendars for enrolment checking to function. This linkage is required for point-in-time load and attendance type calculations. This is discussed further in Load Calendars - Special Topics.
To complete the establishment of enrolment calendars, a number of critical dates must be defined. These are dates recognised by the system that affect System processes. Their definition involves assigning institution defined date alias names to pre-defined events using the Enrolment Calendar Configuration form. Some of these date aliases are attached to enrolment calendars. The majority are attached to either teaching or academic calendars.
The example for Admission Calendars shows the enrolment calendars that the exemplar institution needed for academic year 2000. The following table shows the date aliases chosen for the exemplar institution (in the Enrolment Calendar Configuration form) and an example of how an instance of each was determined. Refer to Enrolment Calendar Configuration for an explanation of each System configuration date.
|
System Requirement |
Chosen Date Alias |
Calendar Category |
Determination of Date Alias Instance |
||
|
Census Date Alias |
CENSUS |
Teaching |
Determined according to DEST specifications. In SEM-1 the instance CENSUS 31/03/2000 was created. |
||
|
Crs Completion Cutoff Date Alias |
CRS-CMPLTN |
Academic |
The institution expects that course completions resulting from either units completed in 2000 SUMMER teaching period or supplementary examinations for the previous year's teaching periods will not be finalised until April 2000. No results for current year unit attempts will be available before June. Hence a course completion cutoff date alias, CRS-CMPLTN 31/05/2000 (arbitrarily chosen between April and June) is created in the 1999 academic calendar. Similarly, CRS-CMPLTN 31/05/2001 is created in the 2000 academic calendar. |
||
|
Commencement Date Alias |
CRSCOMM |
Academic |
At the exemplar institution, teaching for 2000 commences on 28 February. The date alias CRSCOMM 28/02/2000 is created in the 2000 academic calendar. This will default for all students commencing in semester 1 but will be overridden for later commencements. |
||
|
Commence Cutoff Date Alias |
CENSUS |
Teaching |
The institution accepted the advice that this date alias should be the census date of each teaching period. The instance created for SEM-1 was CENSUS 31/03/2000. Students enrolled for the first time in semester 1, 2000 are considered commencing up to and including 30 March, after which they are no longer considered commencing. |
||
|
Record Open Date Alias |
ENR-START |
Teaching |
The exemplar institution permits enrolment in SEM-1 units during enrolment periods ENR-PER-1 and ENR-SUMMER and determines that the window during which enrolments can be processed for SEM-1 2000 is 01/01/1999 to 31/03/2000. An instance ENR-START 01/01/1999 is attached to the SEM-1 2000 teaching calendar. Similarly SEM-2 units can be enrolled during ENR-SUMMER, ENR-PER-1 and ENR-PER-2. The enrolment window for SEM-2 2000 is 01/01/1999 to 31/08/2000. An instance ENR-START 01/01/1999 is attached to the SEM-2 2000 teaching calendar. The same logic is used to determine the ENR-START date alias instances to be attached to other teaching calendar instances. Note that these date alias instances do not have to correspond to the start date of an enrolment calendar. |
||
|
Record Cutoff Date Alias |
ENR-END |
Teaching |
Using the examples given for the previous date alias, an instance ENR-END 31/03/2000 was created in the SEM-1 2000 teaching calendar and ENR-END 31/08/2000 in the SEM-2 2000 teaching calendar. The same logic is used to determine the ENR-END date alias instances to be attached to other teaching calendar instances. Note that these date alias instances do not have to correspond to the end date of an enrolment calendar. |
||
|
VAR-CUTOFF |
Teaching |
The main factor to be considered when determining instances of this date alias, is the relationship between this date and the capture of the DEST statistics submission snapshot. It would be desirable to have finalised variations to enrolments at a sufficiently early date to allow some lead-time for preparation of the statistics submission. The exemplar institution determined that enrolment variations should finish on 30 April in relation to DEST submission 1. An instance VAR-CUTOFF 30/04/2000 was attached to each of the year 2000 teaching calendars that make their first contribution of unit load to submission 1. An instance is also determined, relative to the submission 2 census date, for teaching calendars making their first contribution of load to submission 2. The instances for 'non-standard' teaching calendars were determined primarily with regard to administrative practises associated with these teaching periods. For example, SUM 27/11/2000 28/02/2001 was assigned a VAR-CUTOFF instance of 26/01/2001, recognising that teaching of units may commence at different times during this period and hence more flexibility was required. |
|||
|
Sub-unit Date Alias |
CENSUS |
Teaching |
A simple case sees a superior unit offered in the YR-LONG teaching period and its sub-units offered in SEM-1 and SEM-2. SEM-1 and SEM-2 2000 fall within the start and end dates of YR-LONG 2000. The date alias CENSUS was chosen because all teaching periods must have a census date alias instance. SEM-1 and SEM-2 2000 already contain instances of CENSUS. In checking that the sub-units are correctly enrolled in relation to the superior unit, sub-units in SEM-1 and SEM-2 will be recognised by virtue of those teaching calendars containing an instance of the sub-unit date alias CENSUS. |
||
|
Effect Enr Start Date Alias |
ENR-EFFECT |
none |
1. An instance of this date alias is created in the 2000 academic calendar (and is required in all subsequent academic calendars). The first enrolment period for 2001 (ENR-PER-1) starts in September 2000. To ensure that all enrolment processes associated with ENR-PER-2 2000 (ending on 31/08/2000) have been completed, some leeway (4 weeks) is allowed after the commencement of ENR-PER-1 2001. An instance of this date alias, ENR-EFFECT 01/10/2000, was created and attached to the 2001 academic calendar. This means that enrolment processes run after 01/10/2000 will consider 2001 as the effective academic period. 2. An instance of this date alias is created in each teaching calendar. Our exemplar institution accepted the advice to make this date alias instance coincide with the census date alias instance for each teaching period. When the enrolment form extract process (ENRJ3161) is run prior to an instance of this date alias (prior to 31/03/2000 in SEM-1 2000 teaching period) unit attempts in the teaching period are included as pre-enrolled units in the extract. Where ENRJ3161 is run after this date alias instance, unit attempts are included as academic history in the extract. |
||
|
Load Effective Date Alias |
LOAD-START |
Load |
The important thing to note is that only specific load calendars are considered for point-in-time load and attendance type calculations. That is, those linked to enrolment periods in the current academic period. Based on advice in Load Calendars - Special Topics the exemplar institution established a small set of load calendars. In this relatively simple scenario, it was easy to determine instances of LOAD-START. There was a one to one relationship between load and enrolment calendars, meaning that only one instance of LOAD-START related to each enrolment period. SEM-1 and SEM-2 are the institution's main teaching periods. The institution deemed it important that point-in-time load and attendance type information should be available for the maximum duration during these teaching periods, whilst the same information is primarily required for enrolment checking under the LOAD-SUMM load calendar. Instances of LOAD-START were set up in the three load calendars. They were: 01/01/2000 in LOAD-CAL1, 01/07/2000 in LOAD-CAL2 and 26/11/1999 in LOAD-SUMM. The LOAD-SUMM instance means that from 26/11 (a date toward the end of SEM-2) point-in-time calculations are based on the LOAD-SUMM load calendar. This was deemed acceptable as the date was well after the completion of teaching in SEM-2 and hence a calculation based on SEM-2 load was deemed less important at that time. |
||
|
Package Prod Date Alias |
PACK-PRODN |
Enrolment |
This date defaults as the date of production of a student's enrolment package, but can be overridden in the batch Pre-Enrolment Process (ENRJ3100). Either the default or override value is displayed against the student course attempt in ENRF5F00. The institution aimed to have all enrolment packages for enrolment period 1 (ENR-PER-1) in 2000, mailed by 7 January, 2000. It allowed some leeway for possible delays and set the default package production date as PACK-PRODN 14/01/2000. This date could be overridden in ENRJ3100's parameter form where pre-enrolment for a group of students is delayed beyond 14 January. |
||
|
Form Due Date Alias |
ENROL-FORM |
Enrolment |
This date defaults as the date by which students should return their enrolment form. It can be overridden in the batch Pre-Enrolment Process (ENRJ3100). Either the default or override value is displayed against the student course attempt in ENRF5F00. The institution determined that for the first enrolment period in 2000 (ENR-PER-1), enrolment forms should be returned by 31 January. The date alias instance, ENROL-FORM 31/01/2000, was created. This date could be overridden in ENRJ3100's parameter form if there was a delay in sending enrolment forms, or if more time was to be allowed, to a particular group of students. |
||
|
Enrolled Rule Cutoff Date Alias |
RULECUTOFF |
Teaching |
The institution decided that automatic updating of the status (to ENROLLED) of INVALID unit attempts that pass unit rule checks should apply up until the commencement of teaching. For semester 1, 2000 (teaching commencing on 28 February), the instance RULECUTOFF 27/02/2000 is created. After this date, the batch unit rule checking job (ENRJ0010) detects any INVALID unit attempts which now pass rule checks and reports them, but does not change the status of the affected unit attempts. |
||
|
Invalid Rule Cutoff Date Alias |
RULECUTOFF |
Teaching |
The institution decided that the cutoff date for unit attempts that fail unit rules should be the same as the Enrolled Rule Cutoff Date Alias. The same date alias instances could be used. For semester 1, 2000, RULECUTOFF 27/02/2000 was re-used. That is, it was not necessary to create a date alias instance specifically for the Invalid Rule Cutoff Date Alias in this case. |
||
|
Enrolment Cleanup Date Alias |
ENR-CLEAN |
Enrolment |
The decision was taken to clean up unconfirmed student course attempts after the end of an enrolment period but before the statistics snapshot to be used for government reporting was taken. For the first enrolment period in 2000, ENR-PER-1 01/09/1999 31/03/2000, the instance ENR-CLEAN 14/04/2000 was selected. |
||
|
Lapse Date Alias |
LAPSE-DT |
Academic |
This date was chosen to ensure that course attempts made inactive following completion of a year's study and prior to re-enrolment for the new academic period are not 'lapsed' by the job ENRJ05E0. Course attempts are made INACTIVE when a finalised result is entered for the last of a student's ENROLLED unit attempts. The institution determined that, in 2000, examinations would commence in late October and recording of results at the end of the year would not commence until late November. An instance, LAPSE-DT 10/11/2000 was created. All student course attempts that were INACTIVE prior to this date would have their status changed to LAPSED by job ENRJ05E0. The status of all course attempts made INACTIVE after the 10/11 would not change. |
||
Enrolment Calendar Configuration
The Research subsystem has its own set of peculiarities which can be met by existing teaching calendars in some circumstances but may require the establishment of research teaching calendars in others. Configuring Research Calendars and Date Aliases provides detailed information regarding separate research teaching calendars and should be referred to for other information applicable to both scenarios.
The decision as to whether separate research teaching calendars are required is based on:
Generally, creating separate research teaching calendars reduces the opportunity for confusion with existing teaching calendars and is recommended.
Research teaching calendars are the same as standard teaching calendars in most regards. Each research teaching calendar must be linked to its superior academic period and to load calendars for load and EFTSU calculation purposes and for government reporting. At the same time, a Load Research Percentage value is added to the linked load calendar to specify the proportion of calculated EFTSU attributable to the load calendar for government reporting purposes. (This arises because Research EFTSU is a per academic year calculation which must be split across load periods.)
Two date aliases must be created and identified to the System. They represent the notional start and end dates of research activity within the research teaching calendars and would usually coincide with the start of teaching in the corresponding teaching periods. Their role is explained fully in Research - Special Topics. An instance of each date alias must be assigned to each research calendar.
The exemplar institution opted for separate research calendars, to allow for easier calendar management. Three research calendar types were deemed sufficient to adequately represent research program periods, RES-1, RES-2 and RES-SUMMER. Instances of these calendars were created, with the same start and end dates as the corresponding teaching periods, semesters 1 and 2 and summer semester. The date aliases, RES-STRT and RES-END were created to represent the notional start and end dates of research activity and instances of these date aliases, identical to teaching start and end dates in the corresponding teaching calendars, were created in each research calendar instance.
Configuring Research Calendars
The Student Finance Subsystem requires the set up of specific calendars and date aliases. The following are required:
Full details are provided in the sections:
Each fee calendar instance is linked as a subordinate of its financial year calendar.
A set of paired start and end date aliases, representing the range of effective dates for fee assessment processing within a fee period, must be established, and instances created in each fee calendar. A retro date must be created, with an instance attached to each fee calendar. The retro date is the last date on which the fee assessment routine can be run for the fee assessment period. This date may quite possibly occur outside the fee calendar's date range.
The exemplar institution created a financial year calendar type, FINANCIAL, and an instance of this calendar, FINANCIAL 01/01/2000 31/12/2000. A set of fee calendar types was created reflecting the periods of time for which fees are charged. The exemplar institution charges different fees based on load calendars for the two standard teaching semesters, the summer semester and for a full year. (It was necessary to create an additional load calendar for year-long attendance type based fees, LOAD-YEAR. This was created as an aggregate calendar over all other load calendars to allow derivation of attendance type for a year.) The fee calendars and their instances for 2000 are shown in the following table.
|
FEE CALENDAR INSTANCES |
||
|
Calendar Type |
Start Date |
End Date |
|
FEE-SEM1 |
01/01/2000 |
30/06/2000 |
|
FEE-SEM2 |
01/07/2000 |
31/12/2000 |
|
FEE-SUMMER |
26/11/1999 |
27/02/2000 |
|
FEE-YEAR |
01/01/2000 |
31/12/2000 |
Assessment calendars (Calendar Category = ASSESSMENT) are calendars used for assessment purposes other than examinations. They are effectively groupings of teaching periods and are used mainly as job/report parameters. The start and end dates of assessment calendars are not critical.
Teaching calendars whose units are concurrently put through an assessment process, such as the recording of results, are linked to a single assessment calendar. Reports such as Result Sheets (ASSR5310) can be run for an assessment period and will process all linked teaching periods. This is quicker and easier than running the report individually for each teaching period. Assessment calendars can be linked to an academic calendar to facilitate calendar rollover.
The exemplar institution collects results on three occasions in each year, at the end of the standard semesters, SEM-1 and SEM-2, and at the end of summer semester. Some results are collected via electronic upload, while the remainder are collected on paper results sheets. It is deemed most efficient to produce results sheets for all assessable units as a batch job, regardless of the results collection mode. Teaching calendars, with units that may have assessments reported during a results collection period, are grouped under that period's assessment calendar. The following table illustrates this.
|
Assessment Calendar |
Subordinate Teaching Calendars |
|
ASS-SEM1 01/01/2000 30/06/2000 |
S1-E1 01/01/1999 30/06/2000 |
|
ASS-SEM2 01/07/2000 31/12/2000 |
S1-E1 01/01/2000 30/06/2001 |
|
ASS-SUMM 26/11/1999 27/02/2000 |
SUM 26/11/1999 27/02/2000 |
Examination calendars represent the institution's examination periods. In Callista, an examination period is the time during which a series of exams takes place. The start and end dates of the period should be set to the dates of the first and last exams respectively. Supplementary/Special examination periods are set up as separate exam calendars. Each calendar type used to define an exam period should be unique within an academic period. The naming of calendar types should be meaningful, enabling easy identification of standard and supplementary exam periods.
The availability of exam venues, and exam time-tabling functionality, both depend on the existence of exam calendars, exam date alias instances and exam sessions.
Exam calendars are linked as superiors of those teaching periods with units that will be examined during the exam period. Supplementary/special exam calendars are also linked as superior to the standard exam calendar to which they relate (this link may or may not be required, depending on the exam timetabling methodology and software adopted by your institution). Where combined exams are to be held (for example, supplementary exams for semester 2 1999 combined with standard exams for a summer period 2000), linking the supplementary exam calendar (EXAM-SUPP2) to the standard exam calendar (EXAM-SEM2) will automatically link the teaching periods attached to EXAM-SEM2 to EXAM-SUPP2. That is, it is not necessary to explicitly redefine the links between the supplementary exam calendar and teaching calendars for which supplementary exams are being conducted.
Each exam calendar should also be linked to an academic period. This enables exam calendars to be rolled over when an academic calendar is rolled. It also allows for an academic period to be used as a parameter in an examination related report.
Note: the start date for the examination calendar instance must be for a Monday if using ETI.
A date alias should be created for each day on which exam periods would be held, e.g. EXAM-DAY1, EXAM-DAY2 etc., and instances of each exam day created to represent the examination dates within each exam period. The examination sessions available on each day of an exam period can then be defined.
The exemplar institution conducts three standard examination periods in a year, at the end of semesters 1 and 2 and at the end of summer semester. In addition, three corresponding supplementary examination periods are conducted. Considering the examination period toward the end of semester 1, a calendar type EXAM-SEM1 was created, with an instance EXAM-SEM1 29/05/2000 09/06/2000. The start and end dates of the period were the dates of the first and last exams. A corresponding supplementary exam calendar instance was created, EXAM-SUPP1 17/07/2000 21/07/2000. The following table shows the relationships created for these two calendars.
|
Superior Calendars |
EXAMINATION CALENDAR |
Subordinate Calendars |
||
|
Calendar Category |
Calendar Instance |
Calendar Instance |
Calendar Category |
Calendar Instance |
|
ACADEMIC |
ACAD-YEAR 01/01/2000 |
EXAM-SEM1 29/05/2000 09/06/2000 |
TEACHING |
S1-E1 01/01/1999 30/06/2000 |
|
EXAM |
EXAM-SUPP1 17/07/2000 21/07/2000 |
|||
|
ACADEMIC |
ACAD-YEAR 01/01/2000 |
EXAM-SUPP1 17/07/2000 21/07/2000 |
EXAM |
EXAM-SEM1 29/05/2000 09/06/2000 |
The institution only conducts exams on weekdays. Date aliases were created to represent each day of an exam period. These date aliases were of the form EXAM-DAY1, EXAM-DAY2, up to EXAM-DAY10. The required instances of these date aliases were attached to the exam calenders as shown in the following table.
|
Exam Calendar Instance |
Date Alias Instances |
|
EXAM-SEM1 29/05/2000 09/06/2000 |
EXAM-DAY1 29/05/2000 |
|
EXAM-SUPP1 17/07/2000 21/07/2000 |
EXAM-DAY1 17/07/2000 |
Setting Up Assessments Calendars
Institutions using ETI, Callista's exam timetabling interface, and Syllabus Plus to schedule examinations should consult the documentation for those products.
Progression calendars are those calendars recorded in Callista with a calendar category of PROGRESS. Different progression calendars (those with a different calendar type) are created to represent the different periods in an academic year in which the cycle of student course progression evaluation is conducted. This is determined by institutions but usually means that progression calendars correspond to the institution's main teaching periods.
Every progression calendar must be assigned an alternate code. This code should be as short as possible, meaningful, and unique to a calendar type within an academic period. Alternate codes are used in various forms and reports, where they simplify data display. For example, the progression calendar PROG-SEM-1 in any academic year could be given the alternate code P1, or similar.
Progression calendars are linked to academic calendars to logically group the set of progression calendars applicable within the academic period and to facilitate the calendar rollover process. They are linked to teaching calendars to identify, for a progression period, the teaching periods in which course and/or unit attempts are to be considered by some progression rules.
Progression calendars (and progression rules) can operate at different levels. For example, calendars can operate System wide, for individual organisational units or for individual course versions.
A series of progression calendars can be linked by the use of Stream Numbers, to indicate the series to be used for progression testing of particular students over a number of periods. This is particularly relevant where the failure of a progression rule in one period results in application of another rule in a following period. Different calendar types forming another series would have a different stream number. For example, a series of year-long calendars would have a different stream number to a series of semester calendars.
Progression rules can be applied at different levels in much the same way as progression calendars. At the level of application of a progression rule, the rule is linked to one or more progression calendars. This makes the rule applicable only in the specified calendars at that level.
A progression calendar may be linked to a single subordinate load calendar (standard or aggregate) where progression rule applications are restricted to an attendance type and where a progression rule outcome applies an attendance type or credit point restriction
A number of date aliases must be defined in order for Callista to identify the institution specified names for events critical to the functioning of the Progression subsystem. For example, a date alias must be created to represent the date within a progression period when automatic testing against progression rules should commence. Instances of the date aliases must then be defined for each progression calendar. Setting Up Progression Date Aliases has full details of date alias setup.
There are numerous possibilities for setting up progression calendars. Some of these are explored in the sections listed under More Information.
Setting Up Progression Calendars
Setting Up Progression Date Aliases
Graduation calendars (calendar category = GRADUATION) represent the periods during which graduation ceremonies and graduation processing take place, and are used in Callista to create ceremony rounds. Each round is used to support the management of a graduation cycle. For example, course completion periods are linked to particular ceremony rounds. The students completing, or expected to complete their courses in particular completion periods become potential graduands in the linked ceremony round.
The start and end dates of a ceremony round do not affect System functionality. However, it is recommended that graduation calendars are set up to at least cover a period from the date of the first ceremony, to the date of the last ceremony, in the round.
Various institution defined date aliases must be created and linked to System dates to support graduation functionality. For example, a date alias representing the start date for automatic identification of potential graduands must be created, with instances of the date alias being created for each graduation calendar. Similarly, a date alias instance must be created for each ceremony date, to enable the creation of ceremonies.
Graduation calendars are not normally linked to any other calendars.
There are three key date aliases that must be created, and have instances defined, which can then be used to limit the time when students can be identified as possible graduands and to specify the last date on which students can be automatically allocated to graduation ceremonies. Refer to Graduation Calendars and Date Aliases for further information. A fourth date alias must be created to represent dates on which ceremonies are held. An instance of this date alias is created for each of the ceremony dates.
The exemplar institution conducts two ceremony rounds in 2000, one in April which targets students who completed their courses at the end of the previous year together with students completing their courses in the summer semester, and one in September which targets students who completed their courses mid-year.
In both cases, ceremonies are conducted over a week at various locations. Round 1 has three ceremonies, conducted on April 24, 26 and 28, 2000. Round 2 has two ceremonies, conducted on September 18 and 21, 2000. More than one ceremony could have been conducted on any given day.
The following ceremony round calendar instances are set up. Note that the start and end dates are not critical. In this case they have been chosen to define weeks in which ceremonies are held.
|
CEREMONY ROUNDS |
|||
|
Calendar Type |
Start Date |
End Date |
Calendar Category |
|
ROUND1 |
24/04/2000 |
28/04/2000 |
GRADUATION |
|
ROUND2 |
18/09/2000 |
22/09/2000 |
GRADUATION |
The set of date alias instances required are:
|
Date Alias Instance |
Description |
|
For Round 1 |
|
|
GRAD-START 08/11/1999 |
The earliest date on which job GRDJ3100 (Identify and Create Graduands) can be run for Round 1, 2000. |
|
GRAD-END 10/03/2000 |
The last date in Round 1 on which graduands can be automatically identified by running GRDJ3100. |
|
GRAD-CLOSE 24/03/2000 |
The last date in Round 1 on which the process to allocate graduands to ceremonies (GRDJ5100) can be run. |
|
GRAD-CRMNY 24/04/2000 |
The first date on which a ceremony is conducted in Round 1. |
|
GRAD-CRMNY 26/04/2000 |
The second date on which a ceremony is conducted in Round 1. |
|
GRAD-CRMNY 28/04/2000 |
The third date on which a ceremony is conducted in Round 1. |
|
For Round 2 |
|
|
GRAD-START 24/07/2000 |
The earliest date on which job GRDJ3100 (Identify and Create Graduands) can be run for Round 2, 2000. |
|
GRAD-END 18/08/2000 |
The last date in Round 2 on which graduands can be automatically identified by running GRDJ3100. |
|
GRAD-CLOSE 01/09/2000 |
The last date in Round 2 on which the process to allocate graduands to ceremonies (GRDJ5100) can be run. |
|
GRAD-CRMNY 18/09/2000 |
The first date on which a ceremony is conducted in Round 2. |
|
GRAD-CRMNY 21/09/2000 |
The second date on which a ceremony is conducted in Round 2. |
The main considerations in determining the date values of these date aliases was to allow sufficient time to record final results, to allow time for eligible students to confirm their intention to graduate in the ceremony round and to allow time for the graduands to receive correspondence detailing graduation arrangements.
Holiday calendars (calendar category = HOLIDAY) can be used to record 'holidays' relevant to the institution. The definition of what constitutes a holiday or holiday calendar is a matter for the institution. Typically, a holiday calendar type can be established with instances corresponding either to each academic period or to a calendar year. Date aliases can be created for each single day holiday event in the holiday calendar or date alias pairs can be used to represent holiday periods. Instances of these date aliases are then created in individual calendars. The main System use for holiday date aliases is as Date Alias (DA) and Date Alias Instance (DAI) Offset Constraints. These are used to ensure that where a DA or DAI is specified as an offset from another DA or DAI, the offset date either does or does not (whichever is required) fall on defined days. It is possible to specify that a particular offset DA or DAI does or does not fall on a holiday period specified by a date alias pair, or on a particular day specified by a holiday date alias.
Holiday calendars can be linked to Academic calendars and other Holiday calendars.
The institution chose to record all standard non-teaching periods and public holidays for information purposes only.
This category of calendar (USERDEF) can be used for any institution purpose. There is no System functionality associated with either user defined calendars or date aliases of calendar category USERDEF.
User defined calendars may be linked to any other category of calendar in either a superior or subordinate relationship.
The establishment of the institution's calendars is not a one-off event. It is likely that the set of calendars and date aliases will be the subject of continual fine-tuning, both to cater for the changing requirements of the institution and as use of Callista becomes more sophisticated. Most maintenance will be performed as a collaboration between a calendar specialist and subsystem specialists. The Calendar Rollover process requires a thorough understanding of all calendars and an equally thorough understanding of the impact each decision has on the system.
Updated 30 January 2002
