|
|
|
|
In this section:
Users should:
Reference Data and Setup Information is described in detail in the Specialist Function section.
To understand the basics of the Calendar subsystem it is necessary to understand the following key terms. Other Calendar terms important to a full understanding of Calendar are explained in the subsystem glossary.
|
Calendar Category |
is a system defined classification applied to a calendar to identify its function. For example, the calendar categories ADMISSION, EXAM and GRADUATION indicate that the calendars to which they are applied are related to Admission, Examination and Graduation functions respectively. |
|
Calendar Type |
is theinstitution defined name of a calendar as used by the organisation. For example, the calendar types ACAD-YR, SEM-1 and GRAD-1 could be used by an institution to name calendars representing the Academic Year, Semester 1 teaching period and the first graduation round in a year respectively. |
|
Calendar Instance |
is a specific occurrence of a calendar type defined by assigning a start and end date to the calendar type. For example, ACAD-YR 01/01/1998 - 31/12/1998 and ACAD-YR 01/01/1999 - 31/12/1999 are two instances of the calendar type ACAD-YR. |
|
Date Alias |
is the institution defined name of an event as used by the organisation. For example, CENSUS, APPL-CLOSE and END-LECT could be used by an institution to name events representing census dates, admission application closing dates and last dates of lectures respectively. |
|
Date Alias Instance |
is a specific occurrence of a date alias defined by assigning a date to the date alias. For example, APPL-CLOSE 20/12/1999 and APPL-CLOSE 17/12/2000 are two instances of the date alias APPL-CLOSE, defining the closing dates for receipt of applications for admission into courses commencing in semester 1 of 2000 and 2001 respectively. |
The Calendar subsystem is used to record periods of time, and significant events and dates linked to those periods. This framework of calendars is used within the various Callista subsystems to define data and to trigger processes. Different types of calendar are required to support the variety of business processes in the academic and administrative life of an institution.
Although the concepts are drawn directly from the types of calendar with which we are all familiar, both the organisation of data and the terminology used in this subsystem may be unfamiliar.
This section provides an overview of the calendar subsystem and the use of calendars throughout Callista. The Calendar Specialist Functions section provides more detailed information. Your calendar specialist should be consulted about the specific calendars which have been set up at your institution.
The traditional idea of a calendar is represented in Callista by a Calendar Instance. A Calendar Instance is defined by its start and end date and the calendar type to which it is assigned. For example, Semester 1, 1999 could be defined in Callista as SEM-1 01/01/1999 30/06/1999. SEM-1 being its calendar type, 01/01/1999 its start date and 30/06/1999 its end date.
A calendar 'event' is represented by a Date Alias. An event may occur in several different calendars, or a number of times in the one calendar. Each specific occurrence of an event is represented by a Date Alias Instance. For example, a Date Alias START-LECT could be used to represent the date classes commence within a teaching period. In Semester 1 1999, START-LECT might occur on 01/03/1999 while in Semester 2, START-LECT might occur on 17/07/1999. START-LECT 01/03/1999 and START-LECT 17/07/1999 are date alias instances.
A calendar instance represents a period of time. For example, an admission calendar instance ADM-SEM1 01/08/1999 28/01/2000 might represent the period during which admission activities for student commencements in semester 1, 2000 take place. For most calendars, the start and end dates are not critical. That is, they do not directly affect Callista processing. Usually, these dates are chosen to reflect the business practises of the organisation.
Critical dates or time-spans related to a calendar can be represented by a specific date alias or pair of date aliases recognised by the System.
For example, in the Graduation subsystem it is recommended that a calendar instance be set up to indicate the period during which graduation ceremonies are actually held (ceremony round 1 in this case). The start and end dates of this period have no specific functionality associated with them, and serve only to define the particular instance of ceremony round 1. Specific date alias instances are attached to this calendar to provide functionality, such as the date on which identification of potential graduands for the ceremony period can start (start date alias instance) or the three dates on which ceremonies will be held.
Note that in this example, the date on which identification of potential graduands can start is well before the start date of the ceremony round calendar. It is common within Callista for dates to occur outside the period defined by the calendar to which they are attached.
Functions within Callista can depend for their operation on relationships between calendars. For example, a relationship must exist between an admission period and the enrolment period to which its admission applications apply in order that pre-enrolment of successful admission applications occurs in the correct enrolment period. Relationships between calendars are maintained by a calendar specialist.
Most users will not be able to directly observe a calendar relationship. The effect of calendars being related is most obvious where calendar related data is displayed in a list of values (LOV). For example, when recording an application for admission, only those course offering patterns available for offer in the academic period related to the current admission period are displayed in the Direct Admissions form's LOVs. Similarly LOVs in the Direct Admissions Unit form display only those unit offering options available in teaching periods linked to the current admission period.
Callista permits the creation of date aliases to represent all of the significant events in an institution. Callista allows institutions to choose their own names for these date aliases. There are certain date aliases which the System uses to trigger processes. These are called Calendar Configuration Date Aliases, and occur in a number of subsystems. Either the calendar or subsystem specialist 'tells' the System the name which the institution has chosen for each of these date aliases. For example, in the Enrolments subsystem, the date alias for the last day in an enrolment period that enrolment variations can be processed can have any institution defined name, but this name must be recorded by a system specialist to let the System know the institution's preferred name. Your specialist will advise you of any date alias names you should know.
The extent to which individual users will need to know the names of the date aliases used by their institution depends on the subsystems they use and the tasks they perform in them.
Some periods of time are represented by a combination of calendars, the combinations being based on the relationships between data maintained by specialist users. For example, Commencement Period, in the Direct Admissions form (ADMF3000), combines academic period alternate code and admission period alternate code. A commencement period of 2001/1 would represent the combination of an academic calendar such as ACAD-YR 01/01/2001 31/12/2001 and an admission calendar such as ADM-PER1 14/08/2000 16/02/2001.
Many of the categories of calendar in Callista have their own unique requirements. The Calendar Specialist Functions section provides information about:
Last Modified on 1 February 2000