Main Menu

SIS 2000+ Mass Course Request Changes

This highly flexible application adds, changes or removes course requests from/to a set of students. A separate Scheduling application, The Course Request Editor, displays students' course requests per student and, in turn, will reflect any changes made through the Mass Course Request process. The Mass Course Request procedure is different from the procedure used in the Course Request Editor in that it allows additions or changes to be made to more than one student at a time. Also, the Mass Course Request Changes program allows for previewing results on a trial run basis before actually posting the changes to the database.

See Course Request Editor for more information on course requests.

There are three types of Mass Course Request Actions available:

• Add Requests
• Change Requests
• Remove Requests

Fig. 1

Screen Layout

Initially, the opening screen, 'Pending Actions', will be empty (Fig. 1). Actions (Add Requests, Change Requests, and Remove Request) are adding via the Add command button. The Actions that are created are not stored in the database but rather exist in a temporary queue on this screen until the Process button is used to execute them, they are deleted, or the application is exited. As long as actions exist in the queue the VCR buttons and the List button are disabled, since moving to another track would require that the actions be discarded. Fig. 14 below is an example of Pending Actions in a queue ready to be processed.
 

2. Select a Track
Mass Course Request Changes are applied to one track at a time. Select the target track, either by using the VCR buttons or by using the List command button.
 

3. Add Actions
Three types of Actions are available in the Mass Course Requests process. Each Action is defined in detail according to selection criteria made in a corresponding dialog screen and then assigned to a set of students in the track. A single Action or any combination of Actions may be defined for processing.

Click on the Add command button at the bottom of the 'Pending Actions' screen to view a list of available Actions in the 'Select type of Action...' screen (Fig. 2). Click on an Action command button to proceed to the corresponding criteria selection screen, or Done to exit and return to the main screen.

Fig. 2
 

3.1 Add Requests
In its minimum configuration, this Action will add a specified course request to all students in the track as a Primary or Alternate request. By further defining conditions and criteria, the course request can be configured to be added only to those students with a specified existing course request.




Fig. 3
 

3.1.1 Select a Course Request to Add
In the upper portion of the 'Add Requests' screen (Fig. 4) select a Course, Group, or Team to add as a course request.


Fig. 4
 

• Primary -

Check this field to add the course request as a Primary request.
• Alternate -

Check this field to add the course request as an Alternate request. This action will activate the 'To students with an existing 'Request For' fields directly below. The Alternate course request that is being added must be associated with a Primary course request in the 'Request For' fields.
• Type -

Select "Course", "Group", or "Team". The selection made here will filter the available selections in the next two fields. If "Course" is selected then all courses assigned to the selected track (via the Track Course Selection procedure) will be available for selection. If "Group" is selected then only the names of Course Groups (as defined in the Group Editor application) will be available for selection. All courses within a selected group will be added as course requests. If "Team" is selected then only the names of Teams (As Defined in the Team Editor application) will be available for selection. All course sections within a selected group will be added as course requests.
• Code -

If the code of the target Course, Group, or Team is known, enter it here. If the code entered is valid, a corresponding Description will be displayed in the next field.
• Description -

If the Code is not known, select the target Course, Group, or Team from this drop-down list. The corresponding code of the selection will automatically display in the Code field to the left.
 
3.1.2 Determine Minimum Requirements
 
- for Primary requests
If the Course, Group, or Team to be added was selected a Primary request then the minimum requirements are fulfilled for this Action to be processed. Follow Steps 3.1.6-3.1.7 to add this request to all students in the selected track. To select further criteria for how this request will be added or to further define the set of students who will receive this request, execute Steps 3.1.3-3.1.7.

- for Alternate requests
If the request to be added was selected as an Alternate then the 'To students with an existing Request For' fields directly below will be enabled. Enter the course Code or Description of the course that will act as the Primary request for the Alternate request that is being added. This will set a condition that will add the Alternate request only to those students who have the Primary course request already in the database. In the example of Fig. 5, 'Algebra 1' will be added as an Alternate request to any student who already has a Primary request for 'Appl Math 1'. This will fulfill the minimum requirement for adding an Alternate request. To apply this Action to all students in the selected track go to Step 3.1.6-3.1.7. To select further criteria for how this request will be added or to further define the set of students who will receive this request, continue with Steps 3.1.3-3.1.7.


Fig. 5
 

3.1.3 Define a conditional existing request (optional)
In the next group of fields the request to be added can be made conditional only 'To students with an existing request for' a specified course request already in the database. The conditional existing request can be specified to be a Primary request, an Alternate request, or either/or (by checking both fields). In the example being used in Fig. 6, 'Biology' will added as a course request only to those students who already have 'Anthropology' as a Primary course request.


Fig. 6

3.1.4 Select more criteria for conditional existing request
The next group of data fields (Fig. 7) apply only to a conditional existing request defined in the previous group of fields. These selection criteria will be compared against identical "course request attributes" defined for the existing request in the Course Request Editor application. Only existing requests that match all criteria selected in this step will qualify as conditional in this Action.


Fig. 7
 

• Faculty -

Optional: Select a faculty preference for the existing requested course or leave blank if there is no preference.
• Schedule with this faculty -

Check here to define the name in the Faculty field as a preference.
• Do not schedule with this faculty -

Check here to define the name in the Faculty field as an exclusion, i.e. the student prefers not to be scheduled with the selected teacher.
• Faculty Selection Must Be Honored -

Check this field if the faculty preference or exclusion is required as a condition for scheduling the student in the requested course.
 
• Priority -

Course requests with highest priority will be scheduled first in SIS 2000+'s Student Loader program. The Loader will accept priority values ranging from 1-999, with "1" being the highest priority. The priority system is used when automatically building a schedule to ensure that the students who need a specific course the most are the first ones to be scheduled into the class. The default for this field is "1". Entering a zero (0) would be interpreted by the Loader as "1000", or lowest priority.
• Lock Request -

The locked mode prevents the course request from being cleared by certain automatic functions in SIS 2000+, such as the "Clear Unlocked Requests" feature in the Career Plan Editor application (See Career Plan Editor, Step 6.2) or the Generate Course Requests from a Career Plan procedure (Step 6 below). Deselect this field to allow the course to be cleared by these automatic functions.
• Term -

Select the desired term for enrollment. Choices available are determined by the terms defined for the current track of the selected student.
• Use only this term -

Check here to define the value in the Term field as a preference (default)
• Exclude this term -

Check here to define the value in the Term field as an exclusion, i.e. the student prefers not to be scheduled in the selected term.
• Term Selection Must Be Honored -

Check this field if the term preference or exclusion is required as a condition for scheduling the student in the course.
• TA -

Put a check in this box if the student is requesting to be a Teaching Assistant in this course.
 
3.1.5 Select a Set of Students (optional)
The Action defined in the previous steps will be applied to all active students in the selected track by default unless a specific set of students is selected in this step. The procedure that follows is almost identical to the Select Queries procedures in standard SIS 2000+ reports. See General Reporting Procedures, Step 2.2, Apply Select Queries for more information.
 
3.1.5.1 Initiate select query



Click on the Select Students command button to open the 'Select Students' dialog (Fig. 8).


Fig. 8

3.1.5.2 Select a category to edit
Select a category by clicking on an entry until it is highlighted in gray (Fig. 8). Then click on the Edit command button to open a query (Fig. 9)

3.1.5.3 Select criteria and apply a query
Click on criteria to apply as a query to the selected category. To select more than one criteria, hold the CTRL down while clicking with the mouse (Fig. 9). Deselect criteria by reversing this process. Click on the Done command button to save the query and return to 'Select Students' screen, or Cancel to abort.


Fig. 9

3.1.5.4 Review criteria and apply all queries
Queries applied will be indicated by codes for each category in the 'Select Students' screen (Fig. 10). Click on the Done command button to apply all queries, Edit to modify queries, or Reset to set all categories back to their default of 'All'. If Done, the view will revert to the 'Add Requests' screen (Fig. 3)


Fig. 10
 

3.1.6 Save completed Add Requests Action



From the 'Add Requests' screen (Fig. 3), click on the Save command button and then the Done command button, or Undo to clear conditions and criteria. If Save/Done, the view will revert to the 'Select type of Action...' screen (Fig. 2).



At the bottom of the 'Select type of Action...' screen click on the Done command button again to go back to the main 'Pending Actions' screen to view the completed Action as an entry in a queue on the screen (Fig. 11).


Fig. 11

3.1.7 Continue or Process

• Go to Steps 4-5.3 to process this Action, or
• Repeat Steps 3.1-3.1.7 to create more Add Requests Actions, or
• Continue with Steps 3.2 and 3.3 to add other types of Actions before processing.
 
3.2 Change Requests
This Action will look for a specified a course request already existing in the database and change its attributes to conditions defined.




Fig. 12
 

3.2.1 Select an Existing Course Request to Change
In the upper portion of the 'Change Requests' screen select a Course, Group, or Team to be changed.
 
• Primary -

Check this field if the existing course request to be changed must be a Primary request.
• Alternate -

Check this field if the existing course request to be changed must be an Alternate request.
• Any -

Check this field if the existing course request to be changed for can be either Primary or alternate.
• Type -

Select "Course", "Group", or "Team".
• Code -

If the code of the target Course, Group, or Team is known, enter it here. If the code entered is valid, a corresponding Description will be displayed in the next field.
• Description -

If the Code is not known select the target Course, Group, or Team from this drop-down list. The corresponding code of the selection will automatically display in the Code field to the left.
 
3.2.2 Change Attributes of specified Course Request
Put a check mark in each course request attribute to be modified. As this is done the corresponding read-only fields to the right of the check box will be enabled. A minimum of one attribute must be selected in order to save and process this Action.
 
• Change Course


Fig. 13

The course request queried will be changed to the new course request indicated (Fig. 13). Enter a new Code or Description.
 

• Change Faculty name and Preference/Exclusion status


Fig. 14

Change the Faculty name for preference or exclusion by selecting a new teacher in the drop-down list (Fig. 14). Then select or deselect preference/exclusion attributes with the radio buttons to the immediate right. (Leave the Faculty name field blank to change the preference/exclusion status of the existing course request without changing the name of the Faculty requested.)
 

• Schedule with this faculty -

Check here to define the new name in the Faculty field (or the existing Faculty requested if left blank) as a preference.
• Do not schedule with this faculty -

Check here to define the new name in the Faculty field (or the existing Faculty requested if left blank) as an exclusion, i.e. the student prefers not to be scheduled with the selected teacher.
• No Change -

Check this box to leave the existing preference/exclusion status intact for the course request being changed. Any new teacher selected will automatically be classified as a preference or exclusion according to the original attributes of the course request being changed.
• Faculty Selection Must Be Honored -

Activate this field using the Change check box to its immediate left. Put a check in the Faculty Selection Must Be Honored field this if the faculty preference or exclusion is required as a condition for scheduling the student in the requested course, or deselect the field to remove that condition.
 
• Change Priority


Fig. 15

Enter a new Priority value (Fig. 15). Course requests with highest priority will be scheduled first in SIS 2000+'s Student Loader program. The Loader will accept priority values ranging from 1-999, with "1" being the highest priority. The priority system is used when automatically building a schedule to ensure that the students who need a specific course the most are the first ones to be scheduled into the class. The default for this field is "1". Entering a zero (0) would be interpreted by the Loader as "1000", or lowest priority.
 

• Change Term


Fig. 16

Change the Term name for preference or exclusion by selecting a new Term in the drop-down list (Fig. 16). Then select or deselect preference/exclusion attributes with the radio buttons to the immediate right. (Leave the Term field blank to change the preference/exclusion status of the existing course request without changing the Term requested.)
 

• Use only with this term -

Check here to define the new Term (or the existing Term requested if left blank) as a preference.
• Exclude this term -

Check here to define the new Term (or the existing Term requested if left blank) as an exclusion, i.e. the student prefers not to be scheduled with the selected teacher.
• No Change -

Check this box to leave the existing preference/exclusion status intact for the course request being changed. Any new Term selected will automatically be classified as a preference or exclusion according to the original attributes of the course request being changed.
• Term Selection Must Be Honored -

Activate this field using the Change check box to its immediate left. Put a check in the Term Selection Must Be Honored field this if the Term preference or exclusion is required as a condition for scheduling the student in the requested course, or deselect the field to remove that condition.
 
• Change T/A status


Fig. 17

Select or deselect the T/A field to specify whether or not this is a request for a teaching assistant position.
 

3.2.3 Select a set of Students (optional)
See Step 3.1.5.

3.2.4 Save completed Change Requests Action
See Step 3.1.6.

3.2.5 Continue or Process

• Follow Steps 4-5.3 to process this Action, or
• Repeat Steps 3.2-3.2.4 to create more Change Requests Actions, or
• Go to Steps 3.1 and 3.3 to add other types of Actions before processing.

 
3.3 Remove Requests
In its minimum configuration, this Action will remove a specified course request from all active students in the selected track who have requested it. By adding a condition, the course request can be configured to be removed from only those students with a specified existing course request. Furthermore, when removing a course request that is a Primary request, the Action can be configured to either remove all associated Alternate requests along with the Primary request or promote any associated Alternate requests to Primary request status in place of the request that was removed.




Fig. 18
 

3.3.1 Select Course Request to Remove
In the upper portion of the 'Remove Requests' screen (Fig. 19) select a Course, Group, or Team to remove.


Fig. 19
 

• Primary -

Check this field remove the course request only from students who have it designated as a Primary request. Then choose either Remove alternates or Promote alternate to primary in the button group below (Fig. 20).


Fig. 20
 

• Remove alternates -

Remove all associated Alternate requests along with the Primary request.
• Promote alternate to Primary -

Promotes any associated Alternate requests to Primary request status in place of the request that was removed.
 
• Alternate -

Check this field remove the course request only from students who have it designated as an Alternate request.
• Any -

Check this field to remove the course request whether it is designated as an Alternate request or a Primary request.
• Type -

Select "Course", "Group", or "Team". The selection made here will filter the available selections in the next two fields.
• Code -

If the code of the target Course, Group, or Team is known, enter it here. If the code entered is valid, a corresponding Description will be displayed in the next field.
• Description -

If the Code is not known select the target Course, Group, or Team from this drop-down list. The corresponding code of the selection will automatically display in the Code field to the left.
 
3.3.2 Determine Minimum Requirements
This Action can now be saved and processed without further conditions. Follow Steps 3.3.5-3.3.6 to remove this request from all students in the selected track. To select a condition for the removal of this course request or to define a set of students who will be affected by this Action, continue with Steps 3.3.3-3.3.6.

3.3.3 Define a conditional existing request (optional)
In the next group of fields a condition can be set to remove the request 'From students with an existing request for' a specified request already in the database. The conditional existing request can be specified to be a Primary request, an Alternate request, or either/or (by checking both fields). In the example being used in Fig. 18, 'Pre Alg' will be removed as a course request only from those students who already have 'Fun of Alg' as a Primary course request.

3.3.4 Select a set of Students (optional)
See Step 3.1.5.

3.3.5 Save completed Remove Requests Action
See Step 3.1.6.

3.3.6 Continue or Process

• Follow Steps 4 and 5 to process this Action, or
• Repeat Steps 3.3-3.3.6 to create more Remove Requests Actions, or
• Go back to Steps 3.1 or 3.2 to add other types of Actions before processing.

 

• Review Actions

After each Action is saved click the Done command button twice to go back to the 'Pending Actions' screen. A list of all Actions saved in the current session will be listed for review (Fig. 21). If all is satisfactory, continue to Step 5 to Process the actions.
• Edit Actions

To edit an Action click on the target entry until it is highlighted in gray and then click on the Edit command button to go into the edit mode of its corresponding criteria selection screen.
• Delete Actions

Click on an Action in the list until it is highlighted in gray. Click on the Delete command button to remove the selected Action from the list.
• Sort Actions

The Actions listed will be processed in the order they appear in the list, from first to last. One Action may affect another Action. Therefore, the order in which a group of Actions is processed could have a dramatic effect on the final results of the course requests database. Sort the Actions to the desired order by dragging and dropping a selection to a different position on the list using the mover bar . In the example of Fig. 21 and Fig. 22 below the "Remove/Course/Algebra 1" Action was moved from third place to first place in the list.

Fig. 21


Fig. 22
 
 

5.1 Initiate
Click on the Process command button at the bottom of the 'Pending Actions' screen.

5.2 Select Preview and Print Options
Reports are available in a variety of configurations as the Actions are being processed. In the 'Process Actions' screen that appears (Fig. 23) select the following options:


Fig. 23 - default print options


• Display Summary Report -

A summary of Actions processed. Similar to the list in the 'Pending Actions' screen.

Fig. 24 - sample 'Summary Report'
 
• Detail for all students -

This report details the actions, if any, taken for each student. All students in the set are listed, even if they were not affected by any action. Caution: if the track or set contains many students, this report will issue many pages.

Fig. 25 - sample 'Detail for all students'
 
• Detail for students with matching requests -

Reports only on those students for whom an action is performed, including exceptions. An "exception" is a failure to add a request because a student already has a request for the course/team or failure to change when a course/team is being changed because the student already has a request for the the course/team.

Fig. 26 - sample 'Detail for students with matching requests'

• Detail for students with exceptions -

Reports only on exceptions. An "exception" is a failure to add a request because a student already has a request for the course/team or failure to change when a course/team is being changed because the student already has a request for the the course/team.

Fig. 27 - sample 'Detail for students with exceptions'

• No detail -

Displays no detail report. Use this option when only a Summary Report is needed.
• Preview and Print -

Displays a print preview with the option to print. See General Reporting Procedures, Step 3, Preview for more information on previewing reports.
• Preview Only -

Displays a print preview with no option to print.
• Print Only -

Prints hard copy of report directly to default printer without preview. See General Reporting Procedures, Step 4, Print Report for more information on printing reports.
• Do not change data -

Processes Actions on a trial run basis in RAM memory only. The results are available for analysis as a print preview or a hard copy report (according to preview and print options selected above) but the SIS 2000+ database will not be affected.


Fig. 28

Actions will remain in the 'Pending Actions' queue after processing.


5.3 Complete Processing
After selections are made in the 'Process Actions' screen, click on the Process command button again. A screen gauge will show the progress of the processing (Fig. 29).


Fig. 29

This may take a short period of time or a long period of time depending on the size of the database, speed of the network, and the number and criteria of the Actions being processed. Press ESC to cancel the processing. After all Actions are executed the view will return to the print preview, if selected as an option, or to the 'Pending Actions' screen if no preview was requested. Successfully processed Actions will be removed from the Pending Actions screen (unless the "Do not change data" option was selected.)

7. Exit program
Click on the Quit command button to exit the Mass Course Requests program.
 

Main Menu