Cohorts
At a minimum all cohorts must be associated with a timetable structure and timetable term as these define various characteristics around the cohorts timetabling.
...
From there you have a couple of choices as to how the timetabling process will work for a specific cohort. These are largely defined by the checkbox called timetable managed externally. If this box is checked then it is assumed that an external platform such as Edval Daily will be interfacing with the platform and creating individual sessions in the school calendar as required.
If on the other hand this box is unchecked then PosiEd assumes the responsibility of creating and managing the timetable using the associated timetable structure and timetable term. This process can either be done through an external platform such as Edval which will provide PosiEd with a list of cohort schedules via its published timetable capability or cohort scheduled records can be created manually which is commonly the case for simple timetable structures e.g. primary schools.
Let's look more closely at these two structures from a technical point of view.
Timetable Managed Externally equals True
In this situation PosiEd is relinquishing control of the process of creating individual classes in (sessions) in the calendar.
External timetabling platforms such as Edval Daily utilise the LISS API to perform a publish daily data and publish daily delta timetable data to create and update session entries for each specific cohort that they manage. This means that the PosiEd generate calendar process is not utilised.
In many cases this will mean that there are no cohort schedule records visible for such cohorts, however daily users can still perform a publish timetable process which will create these cohort schedule records. In this case, PosiEd does not use these cohort schedule records to generate the timetable, however it does use them to display the students timetable component on the student account page. This is its only function in this situation.
Timetable Managed Externally equals False
In this mode the timetable of each cohort is defined through cohort session records. These can be either set up manually or created through your timetabling software. For example, by using the Edval publish timetable function.
When created, a cohort schedule looks something like this.
...
Here you can see a list of cohorts scheduled records at the top and below it is a list of sessions that have been created after the generate calendar process has been executed. We'll get to that section a bit later, but for now, we will focus on the cohort schedule creation.
Each cohort schedule record looks something like this:
...
Cohort Schedules
...
Bell Time
This is a link to the bell time in the timetable structure specified in the cohort. This bell time record will define a number of things including:
the period this class is in
the day in the week or two week cycle the class is in
start and end time of the period.
Start Date and End Date
These fields define the start and end dates of this cohort’s schedule. These values default to the start and end dates of the term of the cohort.
Start Time and End Time
These values define the start and end time of the class on a specific day. These default to the start time and end time of the Bell time record if one is specified, otherwise if no bell time is specified, then you can manually enter a start time and end time. This is particularly useful if the cohort schedule does not align with previously defined Bell time rules.
Primary Staff Member and Primary Location
These define the primary staff, member and location of this particular class. These are calculated by looking at the cohort schedule connection records and identifying the primary staff member and primary location respectively defined in this object. If no staff members and/or no location has been defined then the cohort schedule may not have a primary staff member or location.
The cohort schedule primary staff member and location is often used to calculate the default primary staff member and location off the cohort itself. The cohort schedule record that is used to define these defaults is picked at random as there is no way to calculate reliably these values at the cohort level. The school should override these values at the cohort level if they are inaccurate.
Joint Session Type
This field allows you to specify this particular cohort schedule is for a joint class. There are two types of joint classes supported by PosiEd.
Vertical Classes
A vertical class means that two or more cohorts have been aligned such that students can interact between either of the cohorts. For example a year 11 and 12 art class might be aligned such that advanced Year 11 students might take part in the year 12 class and less advanced Year 12 students might remain with the year 11 class.
In this situation the two or more classes will still operate independently, however students may be moved between classes as required. All students from all cohorts included in this structure will be included in each of the mark roll lists so that they can be included in the mark roll regardless of which class they attend.
Composite Classes
A composite class is where two or more cohorts join together in a single class often with combined teaching staff and sometimes with multiple locations included. For example, two math classes might be combined in one on each Monday class in a specific double classroom with both teachers present.
If either of these joint Session types are selected then the operator will need to also provide a reference to the master class. In these situations if two or more classes are taking part in either type of joint program, then any class can be allocated as the master class, and this class will assume certain priorities in the calendar generation and other processes.