Subject Database MANUAL (Full) · Subject Database via integration, with the exception of the following fields, which need to be maintained via SMP Subject Database as COSMOS does

SSD-SYS-MAN-002 SMP Subject Database MANUAL for COSMOS Mastered Subjects Page 1 of 37 Hardcopies of this document are considered uncontrolled please refer to Subject Database log in pages

https://staff.uow.edu.au/smp/subjectdatabase/index.html for latest version.

Student Services Division – Student Systems

Subject Database MANUAL – COSMOS Mastered Subjects Contents 1 Introduction ................................................................................................................................ 2 2 COSMOS Mastered Subjects .................................................................................................... 3

2.1 COSMOS Mastered Subjects in SMP Subject Database ................................................. 4 3 COSMOS to SMP Subject Database - Integration .................................................................... 5

3.1 COSMOS – Create a new subject .................................................................................... 5 3.2 COSMOS – Revise Subject .............................................................................................. 6 3.3 COSMOS Version Updates .............................................................................................. 7 3.4 COSMOS / SMP Integration Errors .................................................................................. 8 3.5 COSMOS / SMP Subject DB Integration - Mapping of fields ........................................... 9

4 SMP Subject DB - Maintain Subject ........................................................................................15 4.1 Pre/Co-Requisite and Equivalence .................................................................................17

4.1.1 Subject Regulations – Electronic Checking Rules ......................................................18 4.1.2 Adding Pre-Requisites ................................................................................................20 4.1.2.1 Rules to consider when using Subject Regulation rules: ............................................20 4.1.2.2 Examples of Subject Regulations ...............................................................................21 4.1.3 Adding Exceptions to Pre-Requisites: ........................................................................22 4.1.4 Adding Co-Requisites .................................................................................................24 4.1.5 Adding Equivalences ..................................................................................................25 4.1.6 Saving your Changes ..................................................................................................26 4.1.7 Reporting on Subject Regulations: .............................................................................26

5 SMP Subject DB – Maintain Subject Instance ........................................................................27 5.1 Quota Reset ....................................................................................................................27

5.1.1 Default Subjects Override Quotas ..............................................................................28 5.2 Reporting on Subject Instance Data ...............................................................................29 5.3 Instance Constraints .......................................................................................................29

5.3.1 Campus Constraints ...................................................................................................29 5.3.2 Course Constraints .....................................................................................................32

5.4 Subject Synonyms ..........................................................................................................32 5.5 Add Staff Association ......................................................................................................32

5.5.1.1 Inconsistencies with Staff Names ...............................................................................33 6 Frequently Asked Questions ...................................................................................................34 7 Version Control Table ..............................................................................................................37

https://staff.uow.edu.au/smp/subjectdatabase/index.html



1 Introduction NOTE: This SMP Subject Database manual is for COSMOS Mastered Subjects (subjects that are created and maintained in COSMOS). If your subjects are Subject DB Mastered (subjects that are created and maintained in the SMP Subject Database), please refer to SMP Subject DB Manual. From 15 April 2020, 2 core systems are being used to master subject information:

• COSMOS (Course and Subject Management Online System) • SMP Subject Database

The SMP Subject Database contains a list of Subject Codes and Subject Instances (session, campus, delivery method) for each year and calendar. Students enrol in subject instances from the SMP Subject Database. There are 4 Subject Databases in SMP (Student Management Package). Table below outlines if subjects are COSMOS or Subject DB mastered: SMP Subject Database Subjects and instances are

mastered in Detail

UOW Subject Database COSMOS All subjects and subject instances are mastered in COSMOS and core data is transferred to SMP Subject Database via integration

UOW College Subject Database

COSMOS SMP Subject Database

Refer to UOW College staff and AQS for details on which subjects are COSMOS Mastered

UOWD College Subject Database

SMP Subject Database

Hong Kong College Subject Database

SMP Subject Database




2 COSMOS Mastered Subjects When staff create a new subject, or amend an existing subject in COSMOS, the changes will automatically flow through to SMP Subject Database. For subjects that are COSMOS mastered: All changes to Subject and Subject Instance information need to be made in COSMOS EXCEPT for the following information, which needs to be maintained in SMP Subject Database as COSMOS does not have the functionality to maintain this data. Subject level information

• Pre Requisite – Electronic Checking rules • Co Requisite – Electronic Checking rules • Equivalence – Electronic Checking rules • Faculty Approval Date

Subject instance level information

• Quota Reset • Instance Constraints – Campus Constraints • Instance Constraints – Course Constraints • Subject Synonyms – Maintained by Student Systems Team

Until the COSMOS Handbook is in production, any changes to the following 7 fields must be made in COSMOS AND SMP Subject Database:

1. Subject Description 2. Subject Learning Outcomes 3. Generic Extra Information 4. Tutorial Enrolment Information 5. Restrictions on Entry 6. Assessment 7. Text Books

Related Subject Information needs to be maintained by Institutional Research Government Reporting (IRGR) team via SAI – Maintain Source Files – Subject Control Values as COSMOS does not hold this data:

• Student Contribution Bands • Discipline Group • Work Experience (Work Integrated Learning in COSMOS is not the same as this field) • Report Owner • Reporting Responsibility • Course Weighting

** Subject Shares are maintained in COSMOS – Subject Information – Subject Share School/Unit ** This information needs to be maintained before subjects can be Faculty approved




2.1 COSMOS Mastered Subjects in SMP Subject Database

• All Subjects in the UOW Subject Database – Undergraduate and Postgraduate, will be COSMOS Mastered.

• Once integration is turned on, when you click to maintain a subject, you will see COSMOS mastered subject: Version 2000.01 at the top of the screen.

• This version number will update once approved changes successfully flow through from COSMOS

SAI – Subject Database – Subject Master Report details whether subjects are COSMOS or SMP Mastered and the COSMOS Version.




3 COSMOS to SMP Subject Database - Integration When new subjects are created, or existing subjects revised in COSMOS, once the proposal is completed, the changes will flow through to SMP Subject Database via Integration.

3.1 COSMOS – Create a new subject Create a new subject

• Master status must be changed from Draft to Active in COSMOS • Status must be changed from Proposed to Approved • Stage needs to be Complete




3.2 COSMOS – Revise Subject Amendment or Discontinuation

A




3.3 COSMOS Version Updates Table details what a COSMOS Version will update in SMP Subject Database.

COSMOS Version Number

SMP Subject DB Year

SMP COSMOS Mastered Subject Version 2019.NN 2020.NN 2021.NN 2022.NN 2023.NN

2019 2000.01 update No update No update No update No update 2019.NN update No update No update No update No update

2020 2000.NN update update No update No update No update 2019.NN update update No update No update No update 2020.NN No update update No update No update No update

2021

2000.01 update update update No update No update 2019.NN update update update No update No update 2020.NN No update update update No update No update 2021.NN No update No update update No update No update

2022

2000.01 update update update update No update 2019.NN update update update update No update 2020.NN No update update update update No update 2021.NN No update No update update update No update 2022.NN No update No update No update update No update

2023

2000.01 update update update update update 2019.NN update update update update update 2020.NN No update update update update update 2021.NN No update No update update update update 2022.NN No update No update No update update update 2023.NN No update No update No update No update update




3.4 COSMOS / SMP Integration Errors The SMP Subject Database is the gold standard for subject information for UOW’s Student Information System (SMP). Integration was developed to transfer Subject information from COSMOS to SMP Subject Database. As COSMOS, does not contain some of the controls required to ensure the subject data is correct in SMP for enrolment, the integration layer performs a number of checks before allowing subject information to integrate from COSMOS to SMP. There are 133 data integrity checks that may be undertaken when data from COSMOS is integrated with SMP.

If a subject proposal completed in COSMOS fails to integrate with SMP, an integration error will be generated and AQS staff will receive details of the error and liaise with relevant staff to address the issue in COSMOS. Once the issue is identified, a new proposal needs to be created in COSMOS (and completed) to trigger integration. SAI – Subject Database – Subject Integration Event Report – has been developed to assist IT staff to troubleshoot integration errors. There are also certain scenarios that will trigger an integration warning – Integration will still occur, but there is a warning to staff. For the full list of integration integrity checks, please refer to - https://cmsprd.uow.edu.au/UOW_Intranet/studentsystems/cosmos-smp-intergration/index.html


https://cmsprd.uow.edu.au/UOW_Intranet/studentsystems/cosmos-smp-intergration/index.html



3.5 COSMOS / SMP Subject DB Integration - Mapping of fields This table outlines which field in COSMOS updates the SMP Subject Field Subject Level SMP Subject DB Field

Example from Subject DB

COSMOS Field Comments

Year 2019 COSMOS Version number, eg 2020.02

Revise – asks for a Commencement Year Commencement Date / integration date – the date that integration will update the information in the SMP Subject Database

Calendar Type Undergraduate Subject Information Award Type

Subject ACCY111 Subject Information Subject Code

Department SAEF Subject Information Owning School/Unit

Subject Level 100 Subject Information Subject Level

Abbreviated Subject Name

Acctg in Society Subject Information Abbreviation

Visible Y COSMOS Master Status

Visible field (or Status field) can be derived from the Master Status. COSMOS Subject Master Status Active = Subject DB Visible Yes / Status is Active. COSMOS Master Status Discontinued - Visible flag at subject level will be set to N

General Schedule Subject

Y Subject Information Schedules

Subject Name Accounting Fundamentals in Society

Subject Information Subject Name

Subject name field in SMP is 68 Chars

Credit Points 6 Subject Information Credit Points




Related Subject Information

SMP Subject DB Field



Student Contribution Band

Exempt Band 1 Band 2 Band 3 Band 1 – Nursing and Education Band 3 – Acct, Admin, Econ, Comm NPA – Maths, Science, Stats

N/A IRGR maintain via SAI – Maintain Source Files – Subject Control Vales

Work Experience No Wrk Exp Directed by UOW Wrk Exp Supported by UOW Wrk Exp Not Supported by UOW

N/A

Engagement with UOW Curriculum Model and Design Priorities Work Integrated Learning Values in COSMOS don’t align with UOW If IRGR requires this information it will be available in DICE that can be migrated to DB

Reporting Report Owner Reporting Responsibility None DEST Publishing DEST Return

N/A IRGR maintain via SAI – Maintain Source Files – Subject Control Vales

Subject Shares Subject Information Subject Share School / Unit Share Faculty Share School/Unit Share Percentage

If IRGR requires this information it will be available in DICE that can be migrated to DB. IRGR requested for notification to be sent every time this field is updated. This specific notification requirement is yet to be discussed with UOW DICE team.

Course Weightings N/A IRGR maintain via SAI – Maintain Source Files – Subject Control Vales




Pre/Co Req Information SMP Subject DB Field



Electronic Checking N/A Electronic checking info must be maintained in SMP Subject DB

Pre-requisites N/A Electronic checking info must be maintained in SMP Subject DB

Co-requisites N/A Electronic checking info must be maintained in SMP Subject DB

Equivalence N/A Electronic checking info must be maintained in SMP Subject DB

Display Information Pre-requisites Enrolment Rules

Course Restrictions Pre-Requisite

Co-requisites Enrolment Rules Course Restrictions Co-Requisite

Equivalence Subject Information Related Subjects

COSMOS has the following values: Double Badged Equivalent Subject Equivalent UOW Subject Equivalent UOW College Subject Equivalent UOW Dubai Subject

Approval Information Department Approval Date

N/A

Faculty Approval Date N/A Approval statuses from COSMOS before integration to SMP Subject DB will occur – functionality still to be developed




Subject Instance Level – Campus and Session Information SMP Subject DB Field



Delivered in Year 2019 Year of the COSMOS Version Number, eg 2020.02

Subject instance in SMP Subject Database belongs to the year in which the census date of the session falls

Subject Code FIN 323 Subject Information Subject Code

Abbreviated Subject Name

Subject Information Abbreviation

Subject Name Subject Information Subject Name

Session Autumn 2019 Subject Availability Session

COSMOS uses SMP Short Session Name

Start date N/A Dates from SMP Session Key Dates

End Date N/A Dates from SMP Session Key Dates

Census Date N/A Dates from SMP Session Key Dates

Campus Subject Availability Delivery Location

Delivery Method Subject Availability Delivery Mode

Instance Name Class 1 Class 2 – Exec Cohort

Subject Availability Instance

Commence with default instance (Class 1)? If Y, Class 1 will be the default Class Name in SMP If No, staff manually enter Class Name in COSMOS Note: Default Instance Class Name must be 1 where there are multiple instances for same Session, Campus, Delivery and timetabling is required

Contact Hours Eg BUS 980 3 hour seminar

Learning and Teaching Activities Engagement Hours Select if applies to all instances

Contact Hours are displayed on the Timetable In SMP, Contact hours are at instance level – different instances have different contact hours – eg ACCY 111

Instance Comment Eg ACCY801 YUM Cohort

Subject Availability Subject Instances Additional Details

Instance comment is not displayed in SMP when student is enrolling in subject.




Students will only see Instance Comment via SMP if they click on subject link to view SMP Subject Database information

Quota Subject Availability Quota

Quota Reset N/A COSMOS Integration will default Quota Reset to N in SMP If you want to prevent students from enrolling in a subject instance once the quota has been reached and students subsequently withdraw, you should set the Quota Reset option to Y. If you don’t care who enrols in the subject once the quota has been reached and students start to withdraw, leave the Quota Reset option set to N.

Visible Combination of COSMOS Master status and Subject Availability Subject Instances On Offer

Refer to COSMOS Revise subject flowchart in this doc

Instance Status Combination of COSMOS Master status and Subject Availability Subject Instances On Offer

Refer to COSMOS Revise subject flowchart in this doc

Reason for Edit

N/A

Staff Association Lecturer Academic Staff

Lecturer

Coordinator Academic Staff Subject Coordinator

Tutor Academic Staff Tutor

WCA Lecturer Academic Staff Subject Coordinator Lecturer Tutor

If Entity = UOW in COSMOS, then map in Subject DB: Subject Coordinator = Coordinator Lecturer = Lecturer Tutor = Tutor




If the Owning Faculty = UOWCA in COSMOS, then map in subject DB: Co-ordinator = Co-ordinator Lecturer = WCA Lecturer Tutor = WCA Lecturer

Consultation Time N/A SMP Public Subject database will no longer exist (it will be replaced by COSMOS Subject Search) – so no need to maintain Consultation times for staff associations in SMP

Consultation time is not displayed on the timetable

Instance Constraints All instance constraints need to be maintained in SMP Subject Database

Campus Constraints N/A Maintain in SMP Course Constraints N/A Maintain in SMP Sponsor Constraints N/A Maintain in SMP Synonym Field used by Student

Systems to manage combined classes in SMP

Instance synonym N/A Combined classes are managed by Student Systems in SMP

Department Listings Department Listings Does not appear in

subject listings of other departments Or tick department

Course Handbook Publish to Course Handbook? Yes Display in other School/Unit then appears

Not applicable for SMP subject database as there will no longer a public view of the SMP Subject Database when COSMOS Handbook is live.

Editing History Edited By Username

Date/time Comment

Edited By - COSMOS




4 SMP Subject DB - Maintain Subject For COSMOS Mastered Subjects, the majority of the fields in the SMP Subject Database will be read only as changes to these fields must be made in COSMOS and changes will flow through to the SMP Subject Database via integration, with the exception of the following fields, which need to be maintained via SMP Subject Database as COSMOS does not manage this information **Refer to section 2 of this document for the list of 7 fields that also need to maintained in SMP until the COSMOS Handbook is implemented): Subject level information

• Pre Requisite – Electronic Checking rules • Co Requisite – Electronic Checking rules • Equivalence – Electronic Checking rules

Subject instance level information





MAINTAIN SUBJECT DETAILS New The New button will not appear in the Subject DB for COSMOS Mastered

Subjects. If a new COSMOS Mastered Subject is required, staff need to create the Subject in COSMOS via + Create a new subject

Display Refreshes the screen Save Saves changes

If a reason is not entered when required, an error message will appear when user clicks to save

Return To List Click to return to Department subject listing EDITING HISTORY Edited by If changes have been made to the Subject via COSMOS/SMP Integration,




there will be an entry in the Editing History

Reason for Edit Certain fields require a reason to be entered when changes are made and the system will prompt users to enter reason for edit.

SEARCH CRITERIA If you receive a message - Subject not found

Search Results – ‘Sorry, could not find any information for’ ABCD101 This message will appear if the subject is showing as ‘Not Available in YYYY’ – which means there are no active instances setup for the subject (either no instances or the existing instances are invisible). Users will need to drill down through the Faculty and then school in the subject database to locate the subject as it will not appear through the search table function

4.1 Pre/Co-Requisite and Equivalence The SMP Subject Database contains electronic checking rules for pre-requisites, co-requisites and equivalence, and it also contains display information for these fields, information that students see when they enrol. COSMOS only contains the display information, which will be transferred to SMP Subject Database via integration. As COSMOS does not have the ability to capture the electronic checking rules that the system requires to check whether students have satisfied the pre/co req or are enrolling in an equivalent subject, these rules need to be maintained via SMP Subject Database. Pre/Co-Requisite Information Electronic Checking Electronic Checking

Where a user can set up the system rules for the subject regulations. This should match what a user describes in the Pre and Co req and Equivalent text fields in ‘Display Information’

Pre-requisites This field displays the Pre-requisites entered via Maintain Electronic Pre/Co Requisites button

Pre/req - a subject which must be completed satisfactorily before the subject for which it is prescribed may be taken

Co-Requisites This field displays the Co-requisites entered via Maintain Electronic Pre/Co Requisites button

Co-req - a subject which must be completed satisfactorily before, taken concurrently with or, at the discretion of the Head, attempted before the subject for which it is prescribed




Equivalence – not to count for credit with

This field displays the Equivalence(s) entered via Maintain Electronic Pre/Co Requisites button

A subject which is not to count with the subject for which it is prescribed Display Information Display Information

The display information is a separate field from the electronic checking rules –The display information is what students see. Display information introduces risk, as electronic rules and display information may not be the same. Display information comes from COSMOS for COSMOS Mastered Subjects. Faculty staff can check the differences between electronic and display information using SAI – Report System – Subject Regulations

Pre-requisites Pre-req text comes from COSMOS Co-requisites Co-req text comes from COSMOS Equivalence Equivalence text comes from COSMOS

4.1.1 Subject Regulations – Electronic Checking Rules Maintain Electronic checking for:

• Pre-requisites • Co-Requisites • Equivalence

From the SAI Main Menu select the following: Subject Database Maintain the UOW Subject Database Click on the required calendar Enter the Subject in the Search Field or search the School Please note: Using the search box will bring up ‘no results found’ if a subject has no subject instances active.

If you receive this error, click through the Faculty > School links to locate the subject you wish to maintain.




Click to maintain the data on ‘Click Here’:

Scroll down to the Pre/Co Requisite Information section:

Information has to be maintained in two separate fields within the Maintain Subject Details screen:

• Electronic Checking contains the actual rules (subject regulations). • Display information is the detail (text) that students see when they enrol – needs to be

maintained via COSMOS Changes must be made to BOTH the display information and the electronic checking fields. Update the Display information in COSMOS, then Click to Maintain Electronic Pre/Co Requisites.

Select the regulation type from the drop down menu:

• Pre-Requisites • Co-Requisites • Equivalence

The pre-reqs for the above subject are ANY 12 credit points including (AND) SCIE102 That is, SCIE102 and any other 6 cp subject will meet the 12 cp *ANY requirement.




e.g. In Spring 2016, originally COMM331 required 54 cp of *ANY and the core 7 B Comm subjects (42 cp). Therefore a student who studied only 54 cp including the 42 cp of core subjects would meet this pre-req. The intention was that the student studied 96 cp (54 + 42 cp) so *ANY should actually be 96 cp

See below for instructions on how to add and edit subject regulations.

4.1.2 Adding Pre-Requisites If you click to add new pre-requisites for a subject, the screen will appear as follows:

Click into the cell to add the first Pre-Req, then click ‘Save’ you will receive a ‘Save Successful’ message). Alternatively, if you have more rules to add, the AND/OR drop down will appear in the next row (OR is defaulted to display given AND is also an option left to right):

4.1.2.1 Rules to consider when using Subject Regulation rules:

• If you are adding a subject code, there is no need to add a credit point value as the subject’s credit point value will be used.

• For Pre-requisite rules, OR only appears Vertically, AND appears both Vertically and Horizontally. Check your rules after saving to make sure they are still logically correct.

• The system alphabetically sorts the AND / OR rule order so users need to put OR rules at the bottom of AND rules otherwise it will sort upon save to make the rule different to what the user intended.

• To set up a code rule, use the code (e.g. ACCY1* for 100 level ACCY subjects)

• The 3rd last character of a subject code depicts the level of the subject code acronym, so if you’re using a subject code with 4 numbers (e.g. 2018’s LLB1100 subjects, you have to set it up as LLB11* for 100 level, not LLB1*)

• To set up ANY subjects, use the *ANY [add credit point value] rule .This is calendar specific, so UOW College subjects would contribute to the ANY count of credits completed. See example below.

• Co-requisite checks are against any session, calendar specific. That is, if the student is enrolled in CRLP200 in Spring session 2016, the Co-requisite check will search ANY session (e.g. Autumn, Annual, Tri 2, Spring) for a co-requisite enrolment in CRLP201. See example below.




4.1.2.2 Examples of Subject Regulations E.g. (1) To study subject ABCD123, a student needs to have successfully completed:

ECON201 AND COMM111 or STAT111 or INFO111 Or ECON202 AND COMM111 or STAT111 or INFO111

This is because, COMM111 or STAT111 or INFO111 are all equivalents. The rules will be mapped like this:

And appear in the SAI subject database pre-req’s table like this: AND/OR CODES Credit points AND/OR CODES Credit points

ECON201 Leave Empty AND COMM111 Leave Empty

OR ECON201 Leave Empty AND STAT111 Leave Empty

OR ECON201 Leave Empty AND INFO111 Leave Empty

That is, AND used in each row; OR used vertically for each new line in Example 1. E.g. (2): 24 credit points of All UOW subjects: AND/OR CODES Credit

points AND/OR CODES Credit

points *ANY 24 OR E.g. (3): 12 credit points of any UOW 200 level subjects. AND/OR CODES Credit


points 200* 12 OR E.g. (4): 6 credit points of FIN 200 level with FIN 222 or FIN 241 or FIN 252 AND/OR CODES Credit

points AND/OR CODES Credit points

FIN 2* 6 AND FIN 222 Leave empty OR FIN 2* 6 AND FIN 241 Leave empty OR FIN 2* 6 AND FIN 252 Leave empty




E.g. (5), Same as e.g. (4), but with AND instead of OR: 6 credit points of FIN 200 level with FIN 222 and FIN 241 and FIN 252

AND/ OR

CODES Credit points

AND/OR CODES Credit points



FIN 2* 6 AND FIN 222 empty AND FIN 241 Empty AND FIN 252 empty

E.g. (6) Same as example (5) but you can use AND vertically as well. It may be reordered upon Save but the rules should be the same: AND/OR CODES Credit points FIN 2* 6 AND FIN 222 Leave empty AND FIN 241 Leave empty AND FIN 252 Leave empty E.g. (7): 6 credit points of FIN 200 or 300 level, AND FIN 222 or FIN 241 or FIN 252 AND/OR CODES Credit


points FIN 2* 6 AND FIN 222 empty OR FIN 2* 6 AND FIN 241 empty OR FIN 2* 6 AND FIN 252 empty OR FIN 3* 6 AND FIN 222 empty OR FIN 3* 6 AND FIN 241 empty OR FIN 3* 6 AND FIN 252 empty

4.1.3 Adding Exceptions to Pre-Requisites: Click on the Exception button:

In the example below, the Pre-Req is ANY 72 credit points at 100 Level and except for CRLP100:

The




system will check for subject validity (upon Save) so ensure that you subject is a valid subject code. Then Save accordingly. The exception is not displayed under the Pre/Co Requisite Information to editors:




4.1.4 Adding Co-Requisites Click on the Regulation Type drop down menu and select Co-Requisites:

In the example above, the Co-Requisites for CRLP200 is CRLP201. NOTE: the systems (SAI and SOLS) will search for co-requisites met in ANY session. That is, if the student is enrolled in CRLP200 in Spring session 2016, the Co-requisite check will search ANY session (e.g. Autumn, Annual, Tri 2, Spring) for a co-requisite enrolment in CRLP201. That is, if CRLP201 subject status is Enrolled, Provisional or Complete (as a pass), then the student has met the co-requisite. A Completed subject status with a Fail grade DOES NOT meet the co-requisite and the student will be marked as Provisional (subject to all other subject regulations).




4.1.5 Adding Equivalences Click on the Regulation Type drop down menu and select Equivalence.

In the example above, CHEM101 is not to count with CHEM104 OR CHEM103. “Ignore enrolments with the same subject code when checking for Equivalence” Flag If students enrol in the same subject code for more than one session (and a fail grade hasn’t been declared for the first instance), the system will flag the second instance of the subject as Equivalent. It is possible to set a flag on the subject to tell the system to Ignore enrolments with the same subject code when checking for Equivalence. For example, MEDI601, students enrol in the same subject code over 3 sessions, so this flag is set so the enrolments in second and third session are not flagged as equivalent. Once the flag is set, if the Student (or staff on behalf of the student) attempts to enrol in a subject instance, if the student has been enrolled in the SAME SUBJECT CODE in a previous session or year (without a Fail grade being declared), the new instance will NOT be flagged as Equivalent. Unlike Exceptions, Equivalence ‘ignore’ flags are visible to staff at Subject level:

They are not visible to students in the public facing Subject Databases.




4.1.6 Saving your Changes Always ensure you also Save at Subject level to ensure your changes were committed. A reason is required when saving at Subject Level (lower half of the ‘edit subject’ page).

4.1.7 Reporting on Subject Regulations: The SAI Report System - Subject Regulations report (which compares display text with the Electronic rules) should be run by subject database officers to compare the electronic rules to the display rules: SAI > Subject Database > Report Systems > Subject Regulations

Once you have setup the regulations, when you click to Return to the Subject Editor, under the electronic heading ’Pre-Requisites’ you can clearly see the rules that have been entered. The reason why there is also a separate text field is because Subject Database officer (e.g. Faculty staff) may want to add additional information to be viewed on the calendar in a format that is easy to read. At present, this system can only cope with the same rules that the AS400 could. Rules that are more complicated still cannot be accommodated and alternatives suggested are using enrolment rules for the majority and then managing the minority of enrolments with Academic Approval enrolment forms.




5 SMP Subject DB – Maintain Subject Instance For COSMOS Mastered Subjects, the majority of the fields in the SMP Subject Database will be read only as changes to these fields must be made in COSMOS and changes will flow through to the SMP Subject Database via integration, with the exception of the following fields, which need to be maintained via SMP Subject Database as COSMOS does not manage this information: Subject instance level information


5.1 Quota Reset Quota is a field on the Subject Instance in COSMOS – so the Quota for Subject Instances should be maintained in COSMOS for COSMOS Mastered Subjects. Quotas are used to manage or block enrolment numbers. If a subject instance has a quota of 50, once 50 students have enrolled in the subject instance, no further enrolments will be permitted into that subject instance. Student will receive a message that the quota has been reached on the SOLS – Enrolment and Variation screen:




Once the quota has been reached, if 3 students withdraw from the subject instance, the next 3 students who attempt to enrol will be successful. The Quota Reset function can be used to prevent students from enrolling in the subject instance once the quota has been reached and students withdraw from the subject instance. Faculties may want to prevent students from enrolling if they have been managing a waitlist of students who were unable to enrol once the quota had been reached. If you don’t care who enrols in the subject once the quotas has been reached and students start to withdraw, leave the Quota Reset option set to N. If the Quota Reset function is set to Yes Once the number of students enrolled in the subject instance reaches the Quota, the Quota Reset function will reset the Quota to 1. Example

• If Quota is 30 and Quota Reset = Yes • Once 30 students enrol in the Subject Instance, system will reset the Quota to 1 • If 5 students withdraw, so only 25 students are now enrolled, next 5 students to come along to

try to enrol will not be able to (as the quota is 1) • Faculty will then be able to arrange enrolment for students who had been added to waitlist once

the quota had been reached.

Note: Staff can override quotas (including 0 quota) via enrolment in SAI > Enrolment & Variation and they will be advised that they are overriding a quota (and should only do so if appropriate):

Zero quotas can be used to allow a school to manage enrolments with Academic Approval forms (subject addition forms) for faculty managed enrolments. Students will see in SOLS that subjects with zero quotas cannot be found (“Invalid Subject Code”):

5.1.1 Default Subjects Override Quotas New students enrolling in a course with Default Subjects assigned will also be able to enrol into a subject (even if quota has been reached). To review or remove the subject from the Default Subjects list for new enrolling students, contact SSD-AA Enrolments team on [email protected]


mailto:[email protected]



5.2 Reporting on Subject Instance Data The Subject Quotas and Staff Assoc Report can be run to see whether the quota has been reset to 1 already. That is, enrolment quota reached and reset to 1.

From the SAI Main Menu select the following: Report System

Subject Quotas and Staff Assoc

5.3 Instance Constraints Used to maintain the following:

• Campus Constraints • Course Constraints • Sponsor Constraints

Users can report on Campus Constraints and Course Constraints through SAI > Report System > Subject Instance Constraint

5.3.1 Campus Constraints Students can only enrol in Subject Instances if:

• The Campus of their Course is the same as the Campus of the Subject Instance OR




• The Campus of their Course has been ticked in the Campus Constraints of the Subject Instance So students in a Course where, Campus = UOW Online

Will only be able to enrol in Subject Instances where: The Campus of the Subject Instance = UOW Online

Or where UOW Online has been ticked in the Campus Constraint of the Subject instance:

Students in a Course where Campus = Wollongong




Will only be able to enrol in Subject Instances where: The Campus of the Subject Instance = Wollongong

Or where Wollongong has been ticked in the Campus Constraint of the Subject instance – Note: When Subject instances are created for any Australian Campus except UOW Online, all Australian campuses are ticked by Default.




When subject instances are created, COSMOS/SMP Integration sets the following Campus Constrains by default: COSMOS Subject Availability Delivery Location

SMP Subject Database Subject Instance Campus Constraint set by Default

UOW Onshore Australian Campus All UOW Onshore Australian Campuses ticked by default UOW Online No constraints ticked by default UOW Online Wollongong No constraints ticked by default Any UOW College Campus All UOW College campuses ticked by default Dubai No constraints ticked by default UOWDCollege No constraints ticked by default All Other Campuses No constraints ticked by default

5.3.2 Course Constraints If "No Constraints" is selected,then there is no course instance check donewhen a student enrols in this subject instance. If one or more course instances are selected, then the students must be enrolled in one of these course instances to be able to enrol themselves in this subject instance.

5.4 Subject Synonyms Adding a Synonym to a subject instance allows a user of SMP_Central to see multiple subject instances in one Class Roll. As a result, the user of SMP_Central can manage the multiple instances’ groups and tasks as one Class. Therefore, to set up a Subject Synonym, the subject instances involved cannot have any tasks or groups until after the Subject Synonym is set up. Further details on how to set up Subject Synonyms can be found in the Student Systems team’s Combining Classes Procedure https://intranet.uow.edu.au/content/groups/internal/@web/@stusys/documents/doc/uow053418.pdf as this task is generally performed by the Student Systems team only.

5.5 Add Staff Association For COSMOS Mastered Subjects, Staff Associations should be updated in COSMOS – Academic Staff. As the Staff Associations on Subject Instances control the access to the Subject Instance in SMP_Central, the ability to maintain Staff Associations in SMP Subject Database has been left open temporarily so we can ensure there are no issues with the process that will impact access to publish results. Use this button to maintain SMP_Central access for academic staff. Once a staff association has been setup, users will automatically be granted access to the subject in SMP_Central. From the SAI Main Menu select the following

Subject Database Maintain the UOW Subject Database

Call up the subject that you want to setup the Staff Association for and click on the link to Maintain Data.


https://intranet.uow.edu.au/content/groups/internal/@web/@stusys/documents/doc/uow053418.pdf



Scroll down to the Subject Instance List and Click on the Instance. Scroll down and Click on Add Staff Association. The Maintain Staff Details for the Subject Instance screen will appear:

Enter the Surname of the Staff Member in the Staff Search box and click Staff Search. Click on the checkbox to select the correct staff member. Then click whether the staff member is the Lecturer and or Coordinator for the session or the Tutor (or in the case of the College, if they are the WUC Lecturer – which provides access to the WCA Attendance module).

Note: WUC Lecturer was previously used as an ‘Administration’ staff association Once you have made the selections, scroll back to the top of the screen and click Save. The instance number will then be setup in the Permissions Database giving the select staff member immediate access to the class in SMP_Central on their next log in.

5.5.1.1 Inconsistencies with Staff Names If a title of a staff member appears to be incorrect in the Subject Database, the staff member should check their details in the UOW Contact Directory first. SMP systems pulls the name from there in the first instance for the Subject Database. If there is still an inconsistency, staff can contact IMTS helpdesk on 4221 3000 to review their username history. If a unix account (username) has been deleted and reactivated, previous contact details will appear and IMTS intervention is then required for the new name to appear.




6 Frequently Asked Questions Question Answer Do I have to create my subject in COSMOS and SMP Subject Database?

No If your subjects are COSMOS Mastered, once COSMOS/SMP Integration is turned on (which it was in MM/YYYY) when you create new subjects in COSMOS, the new subjects will automatically be created in SMP Subject Database via COSMOS/SMP Integration

Do I have to roll my subjects over from one year to the next?

No COSMOS Mastered Subjects will be rolled over in the SMP Subject Database via a batch process. The SMP subject database is year based and therefore the subjects need to exist in each year. If a new subject is created in COSMOS for 2020, for example, version 2020.01, integration will create the subject in the 2020 SMP Subject Database. If there are no changes to the subject for 2021, no additional versions of the subject will be created in COSMOS, so the subject will be added to the 2021 SMP Subject Database via SMP Subject DB Rollover process (which will be triggered automatically in SMP) – IMTS and Student Systems are in the process of developing this functionality

Do I have to maintain my subjects in COSMOS and SMP Subject Database?

Depends on the information you want to change as COSMOS does not contain some of the key information required for subject enrolment, such as:

• Pre/Co Requisite electronic checking information

• Instance Constraints – Campus Constraints and Course Constraints

• Quota Reset For the Majority of fields, you only need to maintain in COSMOS – refer Section 2 and to the Mapping section of this document for more information

I revised my subject in COSMOS, but the changes have not come through to the SMP Subject Database

You need to liaise with AQS – Course Management to see whether integration was successful or whether there was an exception error that needs to be dealt with. There are a number of checks that are performed before SMP will allow integration to create/update subject information – If information is missing, or incorrect information is entered in COSMOS, integration will fail

How long will it take for the changes I made in COSMOS to flow through to SMP Subject Database?

Integration is immediate – it triggers as soon as the version is complete in COSMOS – allowing a minute or so for the change to flow through to SMP

How will I know if there has been an error with Integration?

Integration errors are sent to AQS – Course Management - who have setup a mailbox to receive




integration errors ([email protected]) and access has been given to faculty SMEs – mailbox name COSMOS Integration AQS – Course Management staff will create a folder for each Faculty and will re-direct errors - Faculties will get first hand information on integration errors and will not have to rely on AQS notifying them – AQS will work closely with Faculty to manage errors, to ensure they understand how to fix. AQS will manage the closure of the error messages.

I made a mistake in COSMOS that has transferred to SMP Subject Database – How do I correct this?

You go back into COSMOS, revise the subject to create another version, make your changes – once approved/completed, the updated version will flow through to SMP Subject DB via Integration Note: All fields from the COSMOS Proposal are updated in SMP Subject Database when integration takes place (not just the fields that were changed)

Information that I entered in COSMOS and checked in SMP Subject Database has been changed

Check versions in COSMOS to see if a Subsequent Version has changed your information You also need to check the timing of versions in COSMOS, for example •If staff create a COSMOS version 2020.01 and the proposal needs to go through FEC workflow (which will take time) •Staff then need to make an operational change, version 2020.02, which is not based on 2020.01 (because this version is not yet approved). •As 2020.02 is an operational change, it’s approved immediately. •When 2020.01 is finally approved, it does not contain the changes that were in 2020.02, so COSMOS will prompt staff to check the versions that have been approved since 2020.01 was completed and staff have to manually include the additional changes in 2020.02 •If staff don’t manually add the 2020.02 changes to the 2020.01 proposal, when 2020.01 is complete and integration sends the information to SMP Subject Database 2020.01 will update all subject information and the changes made as part of 2020.02 will be wiped out

Information that I entered in COSMOS and checked in SMP Subject Database has been changed

Consider timing of Commencement / Integration Date •If staff create a COSMOS version 2020.01 and it has a commencement date of 15 July 2020 – eg make a change to a field they only want to come into effect for Spring session 2020 •The 2020.01 change will be held in the system and




only processed once the commencement date 15 July 2020 is reached •If, before 15 July 2020, staff find a spelling mistake, they make a 2020.02 version and commencement date is immediate - they would need to ‘undo’ the change they made as part of version 2020.01 (because they don’t want this change applied before Spring session 2020) •This change will update SMP subject database immediately, but on 15 July 2020, when the 2020.01 change is applied, it would wipe out the change made as part of 2020.02 (as 2020.01 did not contain the spelling mistake change) •So staff need to think about the changes they are making, after they make the 2020.02 version, they would need to make a 2020.03 version with a commencement date of 15 July 2020, that contains the 2020.01 change and the spelling mistake change




7 Version Control Table Version Control

Date Released yymmdd

Approved By Amendment

1.0 200414 Debbie Sartori – Senior Manager Student Systems – Student Services Division

First Released Version Manual to outline the integration and maintenance of COSMOS Mastered subjects in the SMP Subject Database


Documents

Subject Database MANUAL (Full) · Subject Database via integration, with the exception of the following fields, which need to be maintained via SMP Subject Database as COSMOS does