Docstoc

OCE-BRD-V1-4-100326

Document Sample
OCE-BRD-V1-4-100326 Powered By Docstoc
					EUCLID




Edinburgh University Complete
Lifecycle Integrated Development
Business requirements document (BRD)




Online Course Enrolment (OCE)
Document for use by Testing, Training and Support Staff


v1.4




Author: Susan Ward, Franck Bergeret


20100303




                                                          Page 1 of 47
Contributors
Please provide details of all contributors to this document.
 Role                  Department                Name
 Owner                 EUCLID                    Susan Ward
 Contributor           EUCLID                    Mike Calvert
 Contributor           EUCLID                    Franck Bergeret



Version Control
Please document all changes made to this document since initial distribution.
 Date      Version         Author        Section      Amendment
 12/08/    1.2             Franck        6.2          DoS,Supervisors,Programmes Dir stored in
 09                        Bergeret                   RDX
                                         7.4          OCE amendment: RSM process
                                         8            New: process details and other technical
                                                      changes
 22/2/1    1.2             FB            1.3          Added Cancel/withdrawal functions at RSM
 0
 03/03/    1.3             FB            All          Update     with    new  scope and      new
 2010                                                 functionalities/screens
 10/03     1.3             FB            7.2,         GSD errors
                                         6.3.4        Entry requirements
                                         6.3.5        Submit courses
                                         6.1,6.2      Programmes list
                                         2.2.5        GSD and retake of courses
                                         6.3.7 &      Book courses, un-book courses
                                         6.3.8
 15/3/1    1.3             Fb            All          Feedback from other BA
 0
 17/3      1.3             FB            2            VS. Withdraw: updates SMR_RSLT
 18/3      1.3             FB            6.3, 7.7,    List programmes for a stu, batch job, list
                                         6.1          programmes
 22/3      1.4             FB            2.2          GSD
                                         6.4.10,      Confirm selections,
                                         7.5,7.6,     Withdrawal, Change mode of study, batch
                                         7.7, 7.8     RDX
                                         6.4,         List my students
                                         6.5.4        Adanced search vs display list
                                         1.4          Out of scope



Approval
Please note date of approval.

 Date            Version            Approved by
 15/3/10         1.3                Gavin Pennycook, Gareth Phillips and Chris Giles (Euclid
                                    project)




Associated Documentation
Please note all associated documents.
 Date       Title               Author         Location
            CCAM BRD            Susan          K:\Euclid\Portfolios\CurriculumManagement\CCA

                                                                                    Page 2 of 47
                      Ward,          M\05-BRD\05 BRD\
                      Chris Giles,
                      BA
         DPT BRD      Susan          K:\Euclid\Portfolios\CurriculumManagement\DPT\
                      Ward,          05 BRD\
                      Franck
                      Bergeret,
                      BA
         Visiting     Dr Helen       K:\Euclid\Portfolios\Admissions\VisitingStudents\
         Students     McElhinney,
                                     05-BRD\BRD\VS-BRD.HM\
         BRD          Morag
                      Ianetta, BA
11/08/   OCSS build   Franck         K:\Euclid\Portfolios\CurriculumManagement\OCS
09                    Bergeret
                                     S\6 SDS
                                     It is the detailed XLS of the OCE/RSM build
         Tribal doc   Tribal         file:///I:/STAR_DEV/vision/manuals/8.3.0/index.
                                     htm then menu Programmes/Student
                                     Scheduling/Web Module Registration




                                                                           Page 3 of 47
CONTENTS

1        INTRODUCTION ............................................................................ 6
1.1      Current Course Enrolment ................................................................ 6
1.2      Online Course Enrolment Visiting Students ......................................... 6
1.3      Online Course Enrolment Non Visiting Students ................................... 7
1.4      Out of Scope ................................................................................... 8

2        DETAILED PROCESS RE-ENGINEERING ....................................... 10
2.1      Technical Set Up............................................................................ 10
2.2      Generating course enrolment for a student ....................................... 11

3        OCE PROCESS AND TIMESCALE IN FIRST YEAR OF OPERATION.. 14
3.1      Timescale and process in first year of operation ................................ 14
3.2      Non Visiting Students ..................................................................... 14

4    GENERATING A DEGREE PROGRAMME TABLE FROM A BUSINESS
PROCESS PESPECTIVE ........................................................................... 15
4.1  DPT rules...................................................................................... 15
4.2  Visiting Students „Degree Programme Tables‟.................................... 15
4.3  Setting Up a Degree Programme ..................................................... 16
4.4  OCE Relationship with CCAM Timetabling (Event) Data ....................... 16
4.5  Programmes Starting in January or after .......................................... 16

5        ONLINE COURSE ENROLMENT ROLE HOLDERS ............................ 18
5.1      Admissions Management Function for Approval/Rejection of VS Choices18
5.2      Director of Studies Role .................................................................. 18
5.3      OCE School Administrator Role ........................................................ 18
5.4      OCE Registry role .......................................................................... 18

6        OVERVIEW OF THE OCE PROCESSES ........................................... 19
6.1      List students per programmes ......................................................... 21
6.2      List students attached to a programme ............................................ 22
6.3      List Programmes for a student ........................................................ 23
6.4      List my Students ........................................................................... 23
6.5      Course selection using DPT rules ..................................................... 24
6.6      Timetable ..................................................................................... 35
6.7      OCE Amendments and screen shots ................................................. 36

7        PROCESSES AND TECHNICAL CHANGES ...................................... 39
7.1      GSD process built in EUCLID Portal .................................................. 39
7.2      GSD process in client server ........................................................... 39
7.3      Course enrolment on client server ................................................... 40
7.4      RSM process ................................................................................. 40
7.5      Cancellation/withdrawal process ...................................................... 41
7.6      Change mode of study ................................................................... 42
7.7      Batch job ...................................................................................... 42
7.8      RDX to store DoS/Programme Director/Supervisor............................. 43
7.9      Role groups .................................................................................. 43
7.10     MMR entry requirement .................................................................. 44
7.11     HTS file ........................................................................................ 44
7.12     Boiler plate text............................................................................. 44
7.13     System Parameters ....................................................................... 44
7.14     Performance issues ........................................................................ 45

                                                                                                Page 4 of 47
7.15     Tribal fix to be done ....................................................................... 45
7.16     Outstanding .................................................................................. 45

APPENDIX I ........................................................................................... 46
I (i)   Reasons for the existing Cancel and Withdraw processes .................... 46
I (ii)  Numbers of withdrawals and cancellations ........................................ 46
I (iii) Managing course mode of study at enrolment ................................... 46

APPENDIX II ......................................................................................... 47
II (i) Submit later creates „confirmed‟ SMS ............................................... 47
II (ii) Submit Later: event of order ........................................................... 47




                                                                                              Page 5 of 47
1    INTRODUCTION
     This document is a „how to‟ document intended to act as a basis for the
     development of Testing scripts, Training Materials and to assist Support
     Staff in understanding the developed system.       This means that the
     existing process will not be fully documented, but will be touched on
     briefly.



1.1 Current Course Enrolment

     1.1.1 Course enrolment
     At present, Directors of Studies (DoS)/Student Support Officers (SSO)
     enrol students on any of their outside courses using WISARD, subject to
     the course quota. Continuing students pre-register within the school, and
     the information is uploaded into Wisard. This should follow on from their
     mutual discussions regarding the best choices to make.
     Currently, TimeTab can be used to give a timetable view of when and
     where courses are being held. TimeTab is updated by date entered in the
     current Course Creation and Amendment system, accessible in Wisard,
     and relies on accurate information being entered on courses by the Course
     Organisers/Secretaries.

     In DACS currently, course enrolment of elective courses is opened up in
     April, the roll forward is run end of June and the compulsory courses aren't
     seeded until end of August.

     1.1.2 Course Cancellation on Wisard:
     On Wisard a DoS can:
           Cancel a student on a course up to 6 weeks after the course
            delivery period.
           After the 6 weeks, he needs to request it to Registry, who will
            cancel it on DACS. This is done so by Registry to ensure that the
            examination schedule is stable.
           Once cancelled the course is not displayed on Wisard/Nesi, but it is
            not deleted in DACS. It is flagged in the history record with updated
            fields „cancelled date‟ and „cancelled by‟

     1.1.3 Course withdrawal on Wisard
           The DoS can withdraw a student on a course at any time after the 6
            week deadline (before the 6 weeks: he can only cancel it).
           Withdrawing will be stored as a result 'WD' in DACS and is shown as
            the result for that course on the student's transcript. For Registry,
            withdrawals will mean that those students will not show up at the
            exam.

1.2 Online Course Enrolment Visiting Students
     In EUCLID, the Online Course Enrolment system is made available to
     Visiting Students at the application stage. Visiting Student applicants can
     apply to a number of courses and submit this application. The VS
                                                                       Page 6 of 47
     Admissions process includes the approval/rejection of selections as well as
     allowing the addition of new course selections.



1.3 Online Course Enrolment Non Visiting Students

     1.3.1 Enrolment, scope
     Due to system load issues, as Non Visiting Students would hit the system
     in far greater numbers that Visiting Students, it has been decided by
     EUCLID Quality Assurance and Information Systems that only Directors of
     Studies (and Programme Directors/Supervisors for PG, as well as Registry)
     will be allowed to enrol these students on their optional courses. Once the
     load issues have been resolved, it will open the possibility of allowing
     students to self-enrol. Once a new student is Unconditional Firm and if the
     date is within 6 weeks of the commencement of the course, they will be
     automatically enrolled on their compulsory courses, but the DoS will have
     a facility to carry out this function if it has not already occurred. If a new
     student is UF before 6 weeks before the beginning of the course, they will
     be enrolled on the compulsory courses at the 6 week point.
     For continuing student, compulsory courses will also automatically be
     seeded in EUCLID from the DPT.

     In EUCLID there is no seeding of non-compulsory courses. The only
     mechanism to get these non-compulsory course selections into EUCLID is
     for school staff to enter them for each student. For 2010, this keying task
     can only start once the Student Data Migration has been run and validated
     - from w/c 26-July 2010.
     Once enrolled, the DoS can run a report on their students‟ choices. If they
     spot they have made an unwise choice, despite their discussions, they can
     meet with the student again and move them to another course using the
     Resolve Student Module (RSM) facility. The RSM facility is called by the
     „view and change course‟ link, available under Curriculum Management.

     Determining who can take the oversubscribed courses will be completed
     off line by the course‟s owning school (as is happening currently).
     The Schools owning the courses will have to communicate to DoS those
     students who have been allowed to take the course (this communication
     must take place currently at some point). The DoS will register their
     students on the other school's course in Euclid using OCE (and/or RSM).

     The changes are: it is the DoS who will actually make all the students‟
     course selection:
         for courses the DoS' s school owns,
         AND for courses owned by other schools. This will be done by the
           DoS using OCE and RSM.
     The risk is that DoS' s external to the owning school enrol their students
     on a course before those students who have been designated for the
     course have been enrolled through OCE, thus taking up a place and
     preventing a 'legitimate' student from being enrolled. To correct this, the
     owning school would have to contact the relevant DoS and ask them to
     remove the student from the course (using RSM).


                                                                         Page 7 of 47
     It is worth highlighting one 'feature' of OCE with regard to selection of
     optional courses, easiest explained by an example: Say a DPT specifies
     that 40 credits must be taken from collection A. If a student wishes to
     take 4 courses of 10 credits, but the 4th course is an outside course
     requiring permission from the owning school, the 3 other selections cannot
     be saved (i.e. reserving a place on the course for the student). All
     selections must be submitted together. This „might‟ be able to be
     managed in some cases by splitting the collections into 2 groups, one
     dedicated for outside courses.

     OCE / RSM will also validate against a course instance quota.



     1.3.2 Cancel within 6 weeks of the course delivery period
     The university will not claim funding for these students. Cancellation will
     be done by DoS on the EUCLID portal using RSM.

     The Euclid process is detailed in „Processes and technical changes‟ chapter
     below.

     1.3.3 Withdraw after 6 weeks
     Update current record so that university can claim cash for the student
     who started the course. No time limit,
     This will appear on the student transcript as WD.
     Withdrawal is to be done by DoS on the EUCLID portal using RSM.

     1.3.4 Allow Cancellation after 6 weeks, managed by Registry
     Cancelling after 6 weeks will mean that the university will not claim
     funding for the students and the course will not appear on the student
     transcript.
     How will DoS notify registry: as done at the moment, off system.
     Registry will use the EUCLID portal RSM build to cancel courses 6 weeks
     after their delivery period.

     1.3.5 Managing course mode of study at enrolment
     In Euclid we will record the mode of study set on the course on the course
     enrolment records. Dos/Registry will also be able to change it at enrolment
     stage.

1.4 Out of Scope
     The following areas are not within the scope of the OCE BRD:




                                                                        Page 8 of 47
1.4.1 The University‟s Academic Timetable and the scheduling of rooms.

This is being undertaken by the Academic Timetable Review Group
Convened by Professor Simon van Heyningen, Vice Principal of Teaching
and Learning.

There are no timetable events created in EUCLID, therefore no automatic
scheduling or clash will take place.

1.4.2 Pre enrolment before July 2010
The student migration is taking place in July 2010, so pre enrolment for
2010 is not possible.
Euclid system enables pre-enrolment (based on the Next Programme, Next
Route, Next Course, Next Block and Next Year information on the current
SCE record). However it has not been built for summer 2010. It could be
done for 2011 as a separate project depending on resources and scope.
Note that with the current academic model in place. it can be done for UG
only, but not for PG (though current academic model could be changed).
Jira 3834

1.4.3 Course ring fencing
Students on a programme may have an option to choose 2 out of 3
courses, but it is mandatory for their programme that all 3 be available to
them. Students on different programmes who can choose these courses
(from wider collections) but who don't need to, should not be allowed to
fill up places on these 3 courses first. Jira 1638.

1.4.4 Undo registration
There is a SITS functionality, which enables to undo the final confirmation
of the enrolment records for a student. Project management decided that
resources could not be made available.




                                                                 Page 9 of 47
2   DETAILED PROCESS RE-ENGINEERING

2.1 Technical Set Up
     The OCE system is rules based and requires certain elements to be in
     place to enable it to work. Some of the following acronyms are primarily
     to assist those involved in technical development, but will also assist with
     clarity to other users.

     2.1.1 Courses (MOD – Modules)

     2.1.2 Course occurrences (MAV – Module Occurrence)
        This is the course delivery instance. MAV assessment pattern must be
        set to create the SMR record.

     2.1.3 A diet and a collection

        It is one year of a degree programme, i.e. Degree Programme Table.
        Tables PDT and PDM1, accessed by form DMD. On the diet a list of
        collection is set with the credit rules. A collection can be a single course
        or a group of courses to choose from. There are three types of group
        collections:
           Those linked to a programme (code prefix with ROU_)
           Those linked to a subject (code prefix with SUB_)
           Those from one or several schools (code prefix with SCH_)

     2.1.4 Student course enrolment (SCE)

        It records the details of a student enrolling onto a programme i.e. an
            occurrence of a programme during a specific academic year.

     2.1.5 Classes (TEL/FRQ/FQE) –

        A class can be a lecture, tutorial, seminar or laboratory Information
        from The University Timetable regarding times and venues.(out of
        scope)
     The course enrolment records are:

     2.1.6 Optional courses (SME)
        They are optional courses created at enrolment stage (ATR process and
        roll over both call GSD)

     2.1.7 Selected courses (SMS)
        They are made up of compulsory courses and selected optional courses
        (transferred from SME and SMA: visiting students‟ application)

     2.1.8 Courses taken (SMO)
        They are the actual courses being taken by a student. The details in
        this table are generated automatically as a consequence of the
        scheduling process.


                                                                         Page 10 of 47
     2.1.9 Courses application (SMA)
        Used at transfer stage (ATR) for VS application to create SMS, and non
        VS to create SMC.

     2.1.10Student Course Credits (SMC)
     SMC records hold information for a student who has received credits for a
       course approved prior learning (APL).

     2.1.11 Courses Results (SMR and SAS)
     SMR records the course result for each course being taken by a student.
     SAS is a child of SMR. SMR and SAS are created by an automatic batch
     job.
     SRA, the student reassessment record, is also a child of SMR, but is only
     created when the student‟s result from their SAS triggers a resit on their
     mark scheme



     2.1.12 System parameters (SIW_MRG, CAM02, CAM_XXSM, CAM_CMD).
     For more information on SYP, see doc syp_live_OCE.xls on
     K:\Euclid\Portfolios\CurriculumManagement\OCSS\6 SDS
     CAM04_CMD parameters are managed by assessment project.



2.2 Generating course enrolment for a student
 A „diet‟ is a SITS software term for one year of a Degree Programme Table in
 University of Edinburgh terminology. In order for a DoS/student to view their
 mandatory degree programme courses, their student record has to have
 passed through the ATR/roll over process. This process is in the domain of the
 Student Administration suite of projects.



     2.2.1 The Applicant Transfer (ATR) Process for new students
     Programmes can start at anytime during the year. ATR will be run from
     six weeks before the programme start. ATR will occur on a student by
     student basis by way of a nightly batch run by using the “RUN LATER”
     button. A Batch Programme Control Set-up screen should contain the
     date/time for the process to be run. When batch ATR is run, a Batch
     Process Control (BPC) record is created and can be viewed using View
     Batch Programs (VBP).

     ATR will call the Generating Student Diets (GSD) process to generate
     course enrolment records for all new students, when their application
     records are transferred prior to matriculation.

     2.2.2 Roll over for continuing students

     The generation of the diets will be done as part of the students roll over.

     They will be rolled over by an annual batch run in July for the Aug/Sept
     start date programmes. For the other start dates, students will be rolled

                                                                        Page 11 of 47
over by batch on the 1st of the month prior to the month start date. Roll
over will also call the GSD process and create the course enrolment
records.

2.2.3 ATR for Visiting Students


Visiting Students will have their timetables manually rescheduled by the
International Office Admissions staff as late as mid July 2009 (performed
by manipulating SMA records) and can be changed anytime before ATR is
run. Only Approved SMA will be picked at ATR, and selected course
records (SMS) will be created. After ATR/GSD a batch process (SST
scheduling) will run to have all selections set to courses taken and
confirmed (need to converts SMS into SMO). o/s jira 3579 ATR/GSD will
be performed 6 weeks before programme start.

2.2.4 The Generating Student Diets (GSD) Process

Our diets/DPTs are based on Student Course Enrolment (SCE) records.
SCE records are checked to determine whether the student can be enrolled
on the programme.
Programme, Route, Course, Block and Occurrence fields are also populated
on the (diet) DMD screen, and if matched with the same SCE fields, the
GSD process creates SME (Student Module Electives) records for optional
courses and SMS records (Student Module Selection) and SMO (Taken
courses) records for compulsory courses.
The DMD diet record is year based and rolled forward every year. GSD will
pick the diet set to „online‟ („manual‟ ones will be disregarded).
DoS will also be able to run GSD from the OCE screen for a student. This
may be required when a DPT has been amended with new courses/new
rules, and needs to be reflected on the student(s). If errors occur, the user
will be able to email them to Euclid Support from the EUCLID portal.
GSD process does not validate against the course quota (MAV target) for
compulsory (seeded) courses.
Note that if a SCE with -for example- an occurrence of B and a DPT set
with an occurrence of A will not be matched. All fields Programme, Route,
Course, block and occurrence must match between both records.
Note that GSD for Visiting Students Creates SMS records from Approved
SMA records and SME records from the VS DPT.          None of the VS
programmes have compulsory courses so no SMOs are ever created at this
stage.

2.2.5 GSD and retake of courses
A student who failed an exam may need to retake the course and will need
to re-enroll on it. Tribal use the word 'retake' when talking about taking
the course in a later year, and „resit‟ to mean SRA in the same year


- Either the course is in the next year DPT and (providing the course has
not been taken and completed CAM02_17) the enrolment is created at roll
over,


                                                                  Page 12 of 47
- Or the DoS enrolls the student using RSM and picks up the next year
course instance (providing the previous course instance has not been
passed-validation not in scope for this year jira 3833).

2.2.6 GSD against completed and passed SMR
GSD will not create course enrolment records if a SMR record has been
flagged as completed and passed (SYP CAM02_17).

2.2.7 Course enrolment process after GSD has been run:




                                                           Page 13 of 47
3   OCE PROCESS AND TIMESCALE IN FIRST YEAR OF OPERATION



3.1 Timescale and process in first year of operation
     Visiting Students were the first to use the OCE tool with a go live in
     September 2009.


3.2 Non Visiting Students
     The DACS student records will be migrated into Euclid in July 2010 and
     this will enable continuing and new students to be enrolled by their DoS
     using Euclid OCE for the first time in July 2010.




                                                                   Page 14 of 47
4   GENERATING A DEGREE PROGRAMME TABLE FROM A BUSINESS
    PROCESS PESPECTIVE



4.1 DPT rules
     When meeting with their DoS to pick their optional courses, a student will
     be presented with the courses they have to take for that year and will be
     asked to select and enrol on their optional courses.


     In order to ensure that the DoS/student picks a valid combination of
     optional courses, rules are embedded when the Degree Programme Table
     (DPT) is set up. The DPT shows the mandatory courses that are required
     to be undertaken to gain a degree, year by year. In addition, it advises
     the DoS/student that they can take a number of optional courses from
     different schedules or groups of schedules. Since April 2009, named
     individuals in Schools (DPT editors) maintain the DPT in EUCLID. The
     published DPT on http://www.drps.ed.ac.uk/index.php will reflect changes
     on a weekly basis.


     The set up of the DPT informs what the DoS/student is presented with
     when they go into OCE tool. They will not be shown any options that do
     not apply to them and will not be allowed to pick too few or too many
     credits. The Director of Studies or Student Support Officer or equivalent
     role holder will be given authority to manage exceptions to these rules.


     For an in depth explanation for how Degree Programme Tables are formed
     in EUCLID, please see the DPT BRD at the following link:
     K:\Euclid\Portfolios\CurriculumManagement\DPT\05 BRD. This is posted
     on the EUCLID webpage for Colleges and Schools to view.


4.2 Visiting Students ‘Degree Programme Tables’
     As Visiting Students don‟t apply to a degree programme, but take
     individual courses, „dummy‟ DPTs have been set up for system purposes to
     allow the OCE process to work for them. EUCLID Support is currently
     responsible for maintaining the DPTS and course collections using EUCLID
     Client. Visiting Students can Visiting Students can view their courses
     through the Online Visiting Student Prospectus, not from the DPT.

     Visiting Students do not „self-enrol‟ in quite the way that DoS enrol non-
     visiting students.    Once the students themselves have made their
     selections, International Office Admissions staff can review their choices
     and approve or reject them. For all full description of Visiting Student
     Admissions, please see:
     K:\Euclid\Portfolios\Admissions\VisitingStudents\05-BRD.




                                                                     Page 15 of 47
4.3 Setting Up a Degree Programme
     At present, setting up a new degree programme is a manual process.
     For undergraduate courses, once the programme is approved, the
     programme has to be keyed into weblink into UCAS to provide the UCAS
     code. Then EUCLID Support should be contacted and the details will be
     entered on to EUCLID. Communications and Marketing should also be
     contacted to update the UG Prospectus page on the web. The Head of the
     Admissions Office should be contacted and the DPT created/amended
     accordingly.
     In Euclid, for UG and PG, following the creation of a new programme, DPT
     editors are informed to create a new DPT by an in tray message in their
     Euclid school group in tray, with a task „create DPT‟ attach to it. By clicking
     on the task they can start creating the DPT either by using templates or by
     cloning an existing DPT.


4.4 OCE Relationship with CCAM Timetabling (Event) Data

     4.4.1 The original scope for the EUCLID project included the generation of
           „Timetable Events‟ which would be used within OCE to schedule
           students onto a clash-free timetable. The project re-scope in spring
           2009 removed this functionality, and the „View Timetable‟ facility in
           OCE has not been activated.
            Class times, and first class details are maintained via CCAM but are
            for information only – they are not used by the system in any
            schedule processing.       There is a separate satellite project to
            populate the current timetable system (TIMETAB) with a download
            from EUCLID of class information.


     4.4.2 The Euclid system is rules based entry requirements (recommended
           or compulsory pre-requisites, co-requisites and prohibited
           combinations) will now be applied at course enrolment for non-
           Visiting Students. It is imperative that these rules are maintained
           correctly in CCAM otherwise it will wrongly prevent (or wrongly fail
           to prevent) course enrolments.

4.5 Programmes Starting in January or after
     Those programmes will cover 2 academic years. Currently in live all are
     postgraduates. A one year PG taught starting in Jan 2011 will end in Jan
     2012. Implications are:
           In January, students on that PG course will only be able to
            automatically enrol on semester 2 courses, but not on semester 1
            courses since they will be rolled forward at the beginning of
            February. RSM will be used by the DoS to enrol the students on the
            courses.
           For publishing reasons, only one DPT would be wanted.
           There are currently 7 PT LLM Distance Learning programmes set to
            start in January, but no DPT have been set up.

                                                                         Page 16 of 47
   There are also 2 PG courses starting in April, only one DPT created
    for PgCert Educational Leadership and Management (ICL)- 15
    Months, with compulsory courses only. 1st year DPT: 1 Sem2
    course, and 2nd year DPT: 2 flexible courses, available




                                                              Page 17 of 47
5    ONLINE COURSE ENROLMENT ROLE HOLDERS

5.1 Admissions Management Function for Approval/Rejection of VS
    Choices
     For BRD, please see K:\Euclid\Portfolios\Admissions\VisitingStudents\05-
     BRD

5.2 Director of Studies Role
     All academics will have access to this role automatically in EUCLID.
     However, they will only be allowed to view and alter the records of the
     students they direct.
     See „Processes‟ chapter for details on Euclid set up for DoS.

5.3 OCE School Administrator Role
     This role covers all the non-academic work that needs to be done. Again,
     access will be restricted to School. This role will be able to see the
     programme(s) for a selected student, or list all programmes from their
     school, then see the students attached to the selected programme.

5.4 OCE Registry role
    Only Registry will be able to cancel a course enrolment after 6 weeks.




                                                                      Page 18 of 47
6   OVERVIEW OF THE OCE PROCESSES


    Below is an overview of the whole OCE process, from the perspective of
    both the DoS and the School Administrator. The Admissions Management
    Role and Visiting Students role are covered in the Visiting Students‟ BRD
    as mentioned previously.

    Whether the user is a DoS or a School Administrator, they will access
    EUCLID via the MyEd Portal, logging in with EASE.




    Once logged in, click on the Admin tab:




                                                                   Page 19 of 47
      This will take the user through to the page below, where they should click
      the „Launch Euclid‟ button:




This will present the user with a menu page, thus:




                                                                      Page 20 of 47
     The following pages will show an overview map of various processes
     followed by expanded diagrams, screen shots and explanations.
     The first page of the process maps shows the two points of access for the
     School Administrator and Director of Study respectively.

The OCE process:


    School Administrator                                                   Director of Study




   List of programmes        Input student name/ID
                                                                           List my students




   List of programmes            Identify student




                           List of students ordered by        Validated:
                                    programme                 To Page 2

                                    Generate DPT
                            Choose courses validated by DPT
                                    Amend courses             Amend:
                                    View Timetable            To Page 5




                                                              Timetable:
                                                              To Page 5




6.1 List students per programmes
     Taking the example of the School Administrator, the user would access the
     student record via a list of programmes. The School Administrator would
     only see a list of all programmes for his/her school. In client, EUCLID
     looks up the relevant school using the School Administrator‟s PRS record
     (PRS_UDF2 field hold level 6 school‟s code).
     The list of programmes is built from the SPR table which has a field called
     „route‟. „Route‟ has its own table, „ROU‟, which is the programme.




                                                                                      Page 21 of 47
     On pressing „List programmes within my school‟, the School Administrator
     is presented with a list of programmes owned by his school (determined
     by field ROU_UDF9, holds level 6 school code) as shown below. The list is
     sorted by scheme (PGR, PGT, and UG). When the programme name
     hyperlink is selected, a list of students is displayed.
     The list shows all enrolled students on a selected programme year for the
     academic year. The year the student is on the SCE enrolment record (CBK
     field), there can be several SCE for the same year, but only one current
     SCE where end date is null and status is either new entrant, continuing
     student or fully matriculated (MM, ZN or ZZ).

     A validation has been added on the user‟s logging id to ensure he is set up
     for a school (PRS_USF2). If not there would be too many programmes to
     return and the system would time out.




6.2 List students attached to a programme
     After selecting the programme the user will be asked to select the
     programme year:




     On Continue, the list of students enrolled for that year on the programme
     and for the academic year is displayed, sorted by student name. The way
     forward from now on is the same for DoS or School Administrators. From
     the screen below the user can:
      Select the programme name hyperlink to view the published DPT (if it
        exists).
      2nd column: the user can generate the course enrolments if it is
        required (though it will have been done at ATR and Roll over). The
        status of the course enrolment generation is also displayed and could
        be one of those:
            o Generate course enrolment hyperlink: means that the GSD
               needs to be run individually for a student by selecting the link
            o Ready for Course selection: the GSD has been run and user
               needs to select optional courses.


                                                                     Page 22 of 47
            o    Course selection entered: the user has selected and submitted
                 courses but has not confirmed.
              o Course selection confirmed: the user has confirmed his course
                 selection.
              o Warning: Student Course record missing for 2010/1. It means
                 that the Student Course Enrolment (SCE) record is missing.
              o Warning: DPT does not exist for this programme for 2010/1.
              o Warning: student course enrolment is not active for 2010/1. It
                 means that the SCE enrolment status is not active (table STA,
                 check box „Active‟, needs to be checked for GSD to be run).
           rd
        3     column: the user will access the Tribal OCE screen if it is
         hyperlinked. If the GSD needs to be run, the status will be „Generate
         course enrolment first required‟.
        4th column: the user will access the RSM process (always available):
         can add, change and cancel courses. Warnings will be displayed to
         users if there are still optional courses to be selected or unconfirmed
         selection, from OCE screen.
        5th column: user can view the timetable: it lists all unconfirmed classes
         for the courses taken (including first class). DoS can review the
         timetable before confirming courses on OCE.




6.3 List Programmes for a student
    Other option for administrators is to search a student by its id (e.g.
    S0233412) and retrieve the programme(s) he is enrolled for the academic
    year. It re-uses the same screen as above, but for a student only.
    A validation will ensure that if the student programme record (SPR) is not in
    the school of the person logged in, a read only version of the „View and
    Change course‟ (RSM) will be displayed.

6.4 List my Students
    This option is for DoS/Supervisors and Programme Directors only. It returns
    the students enrolled on a programme (i.e. have a current SCE record, for
    the academic year with status either new entrant, continuing student or
    fully matriculated –ZN, ZZ, MM-, and end date not null) for which the
    logged person is currently recorded as DoS/Programme Director/Supervisor
    (RDX table). The list of students is grouped by programme, and sorted by
    programme code, programme year and student name.

                                                                       Page 23 of 47
6.5 Course selection using DPT rules
     This section applies only to Non-visiting Students. Visiting Students will
     have had their approved application selections (SMA) converted directly to
     course enrolment (SMO) records so there is no access to the Select using
     DPT rules. This was a requirement of VS Admissions staff and is also
     required for the correct processing of course entry requirements.

     Taking a student his record      shows that he is ready to select his
     optional courses. This is done by     clicking „Course Selection using DPT
     rules‟.




     The overview of the process looks like this:


     6.5.1        DPT selection process overview




                                                                     Page 24 of 47
          DPT Selection Screen
                                         Small Collections
                                         To Page 3




                                         Submit to
                                         To Page 4




                                                 Results using quick
                                                       search
Search (large collections)




                                                              Results of advanced
                             Advanced search screen                 search




    6.5.2 DPT selection screen
    So, on selecting the DPT Selection Screen




                                                                           Page 25 of 47
Student has four compulsory courses for his MA in Ancient History and
Classical Archaeology already populating his timetable.       His degree
programme table (DPT) requires 40 optional credits to be taken to make
up the 120 credits required for the year from the Schedule A to Q, T level
7 or 8 in any period. Student will be sitting with his DoS following a
discussion of what is the right way forward for him.

6.5.3 DPT optional courses screens
On pressing „Select‟ the following screen is returned:




                                                                Page 26 of 47
Note „Validate Selections‟ has been removed and there is plan for Tribal to
remove the checkbox on the above screen (jira 3512).


Below is the screen when „Advanced Search‟ is pressed, with the search
result:




                                                                Page 27 of 47
If it is known that a collection is not too lengthy, the smaller collections
search can be used. By entering course code with wildcard like ACCN08*

                                                                 Page 28 of 47
      (or without) and clicking the button Quick search, it will return a screen
      like the one following, where user can select courses using the checkbox:




If a student already has a course enrolment record (SMS) for a course, he will be
unable to select that course again during course enrolment.



      6.5.4 Advanced search vs Display list

   If the collection on PDM table (PDM_REGM registration method field) is set to
   „List available module‟ (and not „Input available modules), the user will be
   automatically directed to the above list. It has been agreed the following: all
   single course collection, all ROUTE and SUBJECT collections along with all
   SCHOOL collections with 1 or 2 schedules should be set as a List in OCSS.
   (CMS 869015).




      6.5.5 Course Entry requirements
   If the selected course has entry requirements a warning message (if set as
   recommended) is displayed but the user can continue, while an error
   message (if set as compulsory) will prevent the user from progressing until
   the problem is rectified.
   Entry requirements are either co-requisite, pre-requisite or prohibited
   combination. They are set as either compulsory or recommended. Their
   details can be seen when selecting the course code/name hyperlink. This links
   the user to the published course page, which displays details for the current
   „enrolment year‟ in the DRPS. To access other years delivery details and a

                                                                       Page 29 of 47
complete list of all information related to a course, the user can use the „View
Course‟ option in the „Course Creation, Approval and Maintenance menu in
the EUCLID portal.
On the course details screen, pre-requisites are phrased as „Students….have
passed….‟. The system check is actually not on whether a student has already
passed the course, but whether they are taking and have not failed it. This is
so that pre-enrolment can be carried out for continuing students.
In addition to the „structured‟ entry requirements (e.g. Pre-requisite:
“Student must have passed Course A and Course B”), there is an additional
text field DOS‟s should be aware where extra information and non-UoE entry
requirements can be viewed:




Of course, the system cannot interrogate and apply the rules entered in the
„Other requirements‟ box so DOS‟s should always check the course details
screen to ensure requirements have been met.


Co-requisite and pre-requisite rules provide slightly different messaging is due
to the different stages in the process when the rule checks are made. Co-
requisite rules are checked when all selections are submitted (warning
message displayed as well as „invalid by rule‟ mention), and pre-requisites
and prohibited ones are checked at the point of selecting from a collection
(mysits call 089941).
The prohibited rules should be applied to both courses to work.
Note that the wording and formatting of the warning and error messages is
largely SITS generated.


Example of a warning message:




                                                                      Page 30 of 47
Page 31 of 47
6.5.6 DPT Submit and Confirm

  DPT Selection Screen




   Selections submitted




   Selections confirmed




Once the user has made all their selections, either by the Advanced
Search or by using the Quick Search to view the smaller collections, they
will be returned on the following screen for the user to submit selections.
At this stage, all submitted selections will be validated against the DPT
rules to make sure they have been satisfied. If any fails, a submission
error will be displayed and user will not be able to progress, until error is
rectified. Errors could be due to Course full, failed min/max credit rule,
failed overarching rule, Entry requirements rules.




                                                                  Page 32 of 47
6.5.7 Submit Later
Submit Later is also an option. The Submit Later button enables a
student‟s selections, whether partially or fully completed, to be held
temporarily so that they can go back in and make amendments/complete
the process at a later date (SMS records are retained, i.e. it does not lose
the student‟s part-selections when they resume the task, no SMO created
yet). This temporary selection data is held on the student‟s SDL records.
The SMS records count towards the validation of the MAV target as this
stage.

6.5.8 Courses booked
      Compulsory courses are all booked for the student at ATR or roll
       over (which both run the GSD process)
      Optional courses are booked for the student:
          o When submitting all selections (confirmation is still required,
             SMS created). It updates MAV course instance, field actual
             (MAV_ACTL) is incremented.
          o When submitting later (it creates a SMS, status confirmed,
             and updates MAV record by incrementing actual selections
             field -MAV_ACTM- but not MAV_ACTL field). Confirmation is
             still required.
          o   At RSM, when a course is added.




                                                                 Page 33 of 47
6.5.9 Courses full
      In the event the course quota has been reached, an error message
       will be displayed to the user when he attempts to submit a selected
       optional course.
      This needs to be centrally managed by the School owning the
       course. A DoS wishing to enrol a student on a course, which is full,
       will need to contact the owner's school and request the course
       instance (MAV) quota to be increased (using CCAM amend course
       instance function).

6.5.10Undo changes, un book a course
On Submit selections, there will be an intermediate confirmation screen
with the possibility to Undo Changes. This will free a place. When a course
is removed (undo changes) or cancel course at RSM, the course is un-
booked (it decreases MAV_ACTM field and increments MAV_COUT transfer
out field), SMS record is deleted and the optional record SME is reinstated:




6.5.11 Confirm Selections
On Confirm selections, DoS reaches the final stage, and all course
enrolments records are created in Euclid (compulsory SMS set to
confirmed, SME converted into SMS -SMS_STAT=Confirmed- and SMO).
Confirm Selections button will be disabled if the year of the courses does
not match the year in the system parameter CAM02_01.

The DoS currently cannot undo changes once it has been confirmed.

If there are only compulsory courses on the DPT, the DoS should only
have to confirm the courses (and undo changes is not available).




                                                                 Page 34 of 47
6.6 Timetable


Once the selections have been submitted (before confirmation), the DoS can
check their timetable view, and example of the classes (including First class) for
the courses taken is given below:




It displays all course enrolment records SMSs (withdrawn courses to be
excluded). It is available before confirmation (i.e. after submit). That way a DOS
can validate all the courses on the timetable before confirmation.




                                                                        Page 35 of 47
6.7 OCE Amendments and screen shots


     If a student wants to change, remove or add courses after a selection is
     confirmed (RSM functionality), or if a DoS or Programme owner wants to
     opt out from the rules set by a degree programme, they will use the
     following screens shown accessed by hyperlink „View and change course‟.
     On that screen they will also be able to withdraw a course (depending on
     validation), change the mode of study and view the course delivery
     timetable.
     This is the only method of changing enrolled courses for Visiting Students.
     To test. Visiting Student Section university staff amend student
     enrolments both pre and post arrival in Edinburgh, and have DoS who
     direct visiting students. International Office staff will not be DoSs and
     should not be able to amend course enrolments for either College.




     A warning will also be displayed if there are still optional courses to be
     selected or confirmed on the OCE screen (as per DPT rules): ’Warning:
     there are still some optional courses to be selected against the DPT rules. Select
     Close button to come back to previous step and use the 'Course Selection using
     DPT rules' link for this student.’

     6.7.1 Add course
     Selecting „Add course‟ and enter course code or name, select academic
     year and course status. Note that for July 2010, only courses for 2010/11
     should be selected. The choice of academic year will be possible for pre
     enrolment functionality (not in scope for now). The Status field
     (Compulsory or Optional) reflects the one used in the DPT for consistency.
                                                                              Page 36 of 47
Entry requirements are not checked when adding a course using RSM.




Continue to select the course instance.
For Visiting Students, and where there is a choice of instances – „Available
to all Students‟ and „Available to Visiting Students only‟, the DoS must
ensure that the correct instance is selected. Typically (but not exclusively),
part year Visiting Students should be enrolled on „Visiting Student only‟
Instances, as the assessment will be different. Note that there is no
validation for this.




Error or Confirmation




6.7.2 Cancelling/withdrawing a course
Three possible steps according to course start date and the person starting
the cancel process. Details of the process and validation are in „Process
and Technical changes‟ below.
Validations also exist when course enrolment has already been withdrawn,
and when a grade has already been set.

 6.7.2.1     Cancel within 6 weeks of the course delivery period
             Available to DoS and Registry.




 6.7.2.2     Withdraw after 6 weeks the course delivery period
             Available to DoS and Registry.



                                                                   Page 37 of 47
On Close the course enrolment will be flagged as W on the next screen.

 6.7.2.3    Cancel/withdraw after 6 weeks by Registry only
Registry members can either withdraw or cancel course enrolment.




6.7.3 Change mode of study
Available to DoS and Registry.
User can also change the defaulted mode of study:




                                                               Page 38 of 47
7   PROCESSES AND TECHNICAL CHANGES

7.1 GSD process built in EUCLID Portal



GSD process generates the course enrolment for a student or several students,
using their SCE records. It creates SME and /or SMS & SMO records based upon
the DPTs. It is run when there is no SSN record for that student for a year. Once
run it updates the starts of the course enrolment (2nd column).
Once run it may return errors if the DPT is not found, if the Student Course
Enrolment SCE record is missing or it enrolment status is not active, if some
course instances are missing (MAV record).
If there is an error, the user should report it to Euclid Support by mail using the
hyperlink. Euclid support will enable to make amendments on client server and
rerun the GSD properly.




Note that if some MAVs are missing, an error is prompted, but it does not stop
the creation of the SSN record, and therefore the update of the course enrolment
status to „Ready for course selection‟.
To ensure this does not happen, there should be a regular data check done by
Euclid support to ensure that there is a MAV for all compulsory PDM records.
Chris to speak to Euclid Support

7.2 GSD process in client server
Although GSD will be run at ATR or roll over, there may be times when it needs
to run again on an adhoc basis by Euclid Support. Also when errors have
occurred in the Euclid portal, user will notify Euclid Support by mail. The latter
can then run GSD as a trial mode in order to identify and correct the incorrect
data.


Validations for GSD to run:
    o   A DPT must exist
       The SCE must exist with the same route, course, programme block and
        enrolment as the DPT, and enrolment status must be active (STA table).
       The selected annual DPT at GSD is the one with the radio button set to
        Online
       a MAV for the selected year must exist for creating SME, SMS, SMO
Refer to Euclid doc
file:///I:/STAR_LIVE/vision/manuals/8.3.0/index.htm?=000402
Possible „valid‟ errors at GSD due to some checks:


                                                                          Page 39 of 47
-MAV target exceeded (CAM_XXSM_03 set to Y)
-SMR completed and passed: error at GSD and new SMS not created for the
same course existing on the next year DPT (CAM02_17).
Euclid support check before running GSD:
If the previous year DPT is still active and flagged as „on line‟ (and the rolled
forward DPT has not been made active), when running GSD the student will be
enrolled on last year DPT, rather than the current. It is therefore important to
monitor the rolled forward DPT and ensure that all previous year DPT are set to
inactive and flagged as „manual‟.


7.3 Course enrolment on client server
   o   SMEU form can be used to reset all course enrolment records and re run
       the diet (GSD)
   o   GSD can be run as a Trial mode. It is useful to identify and correct the
       potential errors, displayed in the message buffer.

7.4 RSM process

       7.4.1 RSM process enables the user to add, cancel, and change courses,
             out with the rules set in the DPT.
       RSM add creates SMO and SMS records. SMR (and SAS) records will be
       created after via an update run as a batch (TUP SMR_CREATE).
       RSM cancel will delete SMO, SMS, SMR, SAS records in Euclid, but we will
       also set an audit trace on the first SSN record, Note field.

       7.4.2 RSM Validations:
      Grade set: if a grade has been set on SAS records (actual grade field),
       deletion of SMS, SMO, SMR, SAS enrolment records cannot be done.
       (SRA records are only ever created after certain grades have been set on
       SAS records - SRAs will never exist when an RSM cancel happens so will
       never be deleted by this process)


      There is a check against the MAV target field (SYP CAM_XXSM_03=Y).
       CAM02_23 is set to check SMS, SMO, SMA (approved/transferred). If on
       add course, the MAV target<= (SMS+SMA) then an error message is
       returned: “course quota has been reached”. Note that for most MAV
       records the target is set to 999.
      There is another check before adding the course: whether the SMS exists
       already for the student.
      Check whether the course has already been withdrawn.




                                                                        Page 40 of 47
7.5 Cancellation/withdrawal process

     7.5.1 Validation

     If a grade already exists, cancellation/withdrawal cannot be done.

     7.5.2 Cancel within 6 weeks of the course delivery period
     Cancellation is to be done by DoS on the Euclid portal.
        This would delete all records in Euclid: SMS, SMO, SMR and child SAS.
         CG Do we also want to delete SMA, or is history required? This would
         help where an instance is cancelled because if there are no SMA (or
         SMR, SMO or SMS) records the instance can be deleted.
     This is a change from current practice, where the records are flagged as
     cancelled on Nesi (and viewed by history). Tribal confirmed that we can
     delete all those records and only keep the SMR when a grade has been
     set. Registry (Linda K.) has also confirmed they do not need to keep
     history.
        Delete current SAS currently managed by Sits ok. But not for future
         SAS…MI to check with Neil
        6 week validation to be done using the course delivery period (course
         start date).
        There is a validation that if the SMR has an actual grade already set,
         SMR/SMO/SMS cannot be deleted (unlikely within the 1st 6 weeks).
         Need to set the RSM process parameter „Gen Assessments‟ to
         „Generate SAS‟.
        Agreed to have an audit, see Jira 3519. Proposal is to store it on first
         SSN, note field.

     7.5.3 Withdraw after 6 weeks
     This will appear on the student transcript as WD.
     Withdrawal is to be done by DoS on through the EUCLID Portal.
     Euclid process:
        For withdrawing a course, this would set a result as WD on SMR with
         other fields updated:
         Actual & agreed grade fields set to WD, SMR_PROC=COM, SMR_CRED,
         SMR_AGRM, SMR_ACTM=0, SMR_PRCS, SMR_RSLT=F & SMR_SASS=A
        Need to run a TUP to update SAS too. Same available fields as for SMR
         (SAS_ACTG=WD·;SAS_AGRG=WD·;SAS_ACTM=0·;SAS_AGRM=0·;SAS
         _SASS=A·;SAS_PRCS=A)
         At the moment, when a student withdraws from a programme, student
         admin automation updates any SMR records which don‟t hold a mark.
         There is a requirement for the SAS records (and SRAs, if these exist)
         also to be updated on programme withdrawal, see Jira EUC01-3827
        Update SMO_RSTA to W since the records are displayed, as well as
         SMS_UDF2=W (Sits does not allow to add new status on SMS_STAT).

                                                                        Page 41 of 47
        To be consistent with the out of the box Tribal process, increment
         MAV_COUT (field only used for reporting/statistics purposes).

     7.5.4 Allow Cancellation after 6 weeks, managed by Registry
     Euclid process:
        For Registry staff only, any courses after the 6 week period can be
         either cancelled or withdrawn. There is a validation that if the SMR has
         an actual grade already set, SMR cannot be deleted.
        Cancelling would delete all records in Euclid: SMS, SMO, and possibly
         SMR/SAS if no grade set.

7.6 Change mode of study

     7.6.1 Validation

     If a grade already exists, course mode study code cannot be updated on
     SMR, SMO and SMS.

     7.6.2 Process
     The default course mode of study is populated from the course record and
     stored on:
         - SMS: via new TUP when SMS is created, stored on SMS_UDF1
         - SMO: via new TUP, when SMO is created, stored on SMO_UDF1
         - SMR: via existing TUP, when SMR created, stored on SMR_UDF3
         - SAS: there is no UDF, and there would be only one record per SMR.
            So the default course mode of study for a SAS could always be
            found from its parent SMR
     SRA: If re-sit record SRA created later, value may be different from its
     parent record SMR, so will need to be stored on SRA_UDF1. SRA records
     are created if the system calculates results as „Defer‟ on SMR (SMR
     calculation happens automatically after results are input by Registry on
     client server). jira EUC01-3836 closed: Linda estimates that only 1 or 2
     students per year might have different course mode of study at
     reassessment from initial reassessment - Linda agrees that there is no
     need to store a separate value on SRA
         -
         -    Jira EUC01-3837 -
             2 BOXI reports are required to help to prevent errors in OCE due to
             incorrect assessment data:
             1. Report to return MAVs with no MAPs or MABs
             2. Report to return SMO's with no corresponding SMR's



7.7 Batch job
SMR and SAS records will be created at the back of SMO records. A TUP
SMR_CREATE has been set to create the records and to be run as a batch
(weekly or daily?). Validation: MAV must have an Assessment Pattern.
BPC runs programme code MEN_XTUP_1 & BPR: 10=Cams, 12=SMR_CREATE




                                                                       Page 42 of 47
For testing: create a BTU record, enter SMR_CREATE in Table update code field,
select 1, and enter date/time (in future), then select run later. This will create a
new BPC record with the date/time you have entered.
Implementation release: BPC to have a generic user code.

7.8 RDX to store DoS/Programme Director/Supervisor
Because there could be more than 2 Supervisors for Research programmes with
the need to store whether they are lead or not, the supervisors/DOS/Programme
directors will now be stored in the table DRX (and not SPR, fields tutor 1 and 2,
as it was thought and developed at first) as part of student admin:




The RDX field „Expected end‟ date must be blank. If the date is populated, it
means that the Examiner is no longer one, and must be disregarded. A
postgraduate research student can have more than one supervisor with expected
end date null (e.g. main and assistant supervisor)
To store a RDX record, use table RDS, enter the SCJ code (i.e. the SPR code, 1
to 1 relationship), select menu Other/Examiner. RDX Examiner type should be
UTADOS (DOS) for UG, PTDIR (Programme Director) for PGT and the others for
PGR.

7.9 Role groups

      7.9.1 CON OCSS: On Line Course Selection & change course for DOS
      Managed by role group RGD OCSS_STU_LS. PRC record has the same
      name and DOS/Programme Dir/Supervisors need to be added as PCE
      record.




                                                                         Page 43 of 47
        7.9.2 CON OCSS2: Online course selection and change course for
              administrators
        Managed by role group RGD OCSS_PRG_LS. PRC record has the same
        name and administrators need to be added as PCE record.

        7.9.3 Registry role
        There is not a separate role for registry users. The validation is done on
        the value of PRS_DPTC. If set to D429, they bypass the cancellation
        validation on RSM.

7.10 MMR entry requirement
For entry requirements to work, MMR level and scheme must be equal to the SPR
level and scheme.
MMR messages are stored in REX table.

7.11 HTS file

        7.11.1 HTS file SIW_SPR1A_FMC, OCE search criteria, has been amended
              to:
        o    Display the search criteria above the results
        o    To display the level 6 school codes only in the School list-box. It is
             hard-coded for now. That means some maintenance is needed if
             required.

        7.11.2HTS SIW_SME_MAV

        It has been amended to hide button 'entry requirements' and add text as
        per jira 3758

7.12 Boiler plate text
 Boiler plate text changed on
           SIW_SPR1A (search criteria OCE screen)
           SIW_SME (2nd OCE screen: List of courses or quick/advanced search)
            have both been amended to new texts, new help icon, linked to help text
            on intranet.
            FB: address to be changed once Gareth let us know. Same thing:
            reference made to an on line user guide in task OCSS_A and B: address
            to be added as hyperlink.

7.13 System Parameters
The full list of system parameters are on syp_live_OCE.xls in
K:\Euclid\Portfolios\CurriculumManagement\OCSS\6 SDS

        7.13.1 CAM_CMD_004

        Indicates whether the GSD process generates SMO records in addition to
        SMS. To be set to Y.

        7.13.2 Current year CAM02_01 & SIW_MRG_SRC
        CAM02_01 is the current year and most appropriate for RSM.
                                                                         Page 44 of 47
       CAM02_01 to be changed every April to the next academic year.
       SIW_MRG_AYR is now redundant and managed by SIW_MRG_SRC=Y

       7.13.3 CAM_XXSM_03
       MAV target check when creating SMS- Set to Y.

       7.13.4 CAM02_08
       Determine whether to use events when scheduling students. Set to N.

7.14 Performance issues
      There is a document put forward for Tribal highlighting performance issues
       & testing between environments, located in
       K:\Euclid\Portfolios\CurriculumManagement\OCSS\6 SDS
       Closed and fixed via a hot fix in Sept 09


      Other performance issue I looked at:
       Currently the COP is calling tasks OCSS_A and OCSS_B. I changed them
       to call SRL prs.ocss_prg and prs.ocss_stu, but there was no major
       performance improvement,
       -OCSS_A: task and SRL both took between 6 and 10 sec in Dev
       -OCSS_B: task took 55s, SRL took 45s

7.15 Tribal fix to be done
They are detailed in following jiras
      3515/3512/3509: PPL 015208. Removing/hiding the checkbox field when
       the SIW_SME screen is used for a diet with a Registration Method of Input
       or Input Available.
       To be fixed for 8.4.0 sometimes around Nov 2010, back ported to 8.3.0

      3236: PPL 014202. Some DPTs using overarching rules are not being
       displayed properly in OCE. Issue relates to sequence numbers used in the
       DPT. Data fix done.
       Planned for 8.3.1 (May 2010) to be back ported to 8.3.0.
      3797: Undo last changes not working.
       Fix due mid April 2010



7.16 Outstanding
      Tidy up SME table required?
      VS: batch process (SST scheduling) will run to have all selections set to
       courses taken and confirmed (need to converts SMS into SMO). o/s jira
       3579
      SMR_CREATE has been set to create the records and to be run as a batch
       (weekly or daily?)



                                                                       Page 45 of 47
Appendix I

I (i)        Reasons for the existing Cancel and Withdraw processes
   The main reasons this was implemented:
   (1) If a student is deemed to have commenced a course, we should be
   'claiming' this. Whilst external funding (cash) is not yet on the basis of course
   (as opposed to programme) enrolments in the main (a few are e.g.
   unstructured part-time), the focus of most analysis is now on course
   enrolments. Internal teaching load (in DACS) is based on course enrolments.
   So if cancelled, not included; if withdrawn is included
   (2) There was a belief that if a student undertook a course (but did not sit the
   assessment) then should have this recorded and appear on a transcript.
   (3) There was concern (SUGSC) that students were being 'counselled' off
   courses who had been on them for some time - which then did not show up
   in completion rates etc.
   The last two could arguably not be deemed as critical. Certainly Registry
   could decide on the second one i.e. that they don't believe these courses
   should appear on transcripts (but then complicated - do you have to sit an
   exam or just an assessment to get on a transcript???).
   (4) There was also concern and frustration that staff were not maintaining
   course enrolment data i.e. students had changed courses that weren't
   recorded etc - the switch from cancellation to withdrawal was perceived to act
   as an incentive to get it updated by end week 6, and we alerted staff to the
   implications etc.
   It worked to some degree. Impossible to quantify though' and, of course,
   times may have moved on.

I (ii)       Numbers of withdrawals and cancellations
   In 08/09 there was 2613 WD.
   There is an automated process to withdraw courses for students who
   withdraw from the programme (run at certain times in year etc) - as opposed
   to DoSs etc withdrawing them post the 6 weeks - of course some DoSs will
   WD them from courses because they have WD from the Uni - but then there's
   also the ones who have genuinely WD from the course but are still here/doing
   something else.
   In 08/09 there were over 38,000 cancellations of courses.

I (iii)      Managing course mode of study at enrolment
          There is a need to change the default course of study to Class Only or
          Exam Only for a student for the following reasons:
           Students on Class Only are not reported to Hesa and the University are
             therefore not getting funding.
           This is required for examination timetabling,
           As well as Ebis for identifying the number of people on a class for room
             booking.
           Smart system requires identifying Exam Only students.
           Exam Only used for registering students on synoptic courses and those
             carrying courses from last year.


                                                                          Page 46 of 47
Appendix II

II (i)        Submit later creates ‘confirmed’ SMS

          Taken from mysits 090243- It explains why, in system term, Submit Later creates
          Confirmed SMS.

          The SMS Status field is only set to Provisional in instances where a process needs to
          create an SMS record but does not wish that record to be included in any MAV Target
          checking. Currently the only process that will do this is the Timetable Compatibility
          Tool (Timetab) which needs to create the records for display in the timetable but does
          not wish to prevent other students from selecting the module.

          The CREATE_SMS option, as part of Submit Later functionality, was added to
          provide an institution with the option of allowing students to create SMS records part
          way through the process to "reserve" a place on the course which would still be there
          when they come back in to complete the process later on. Due to this requirement, the
          Status field on the SMS record cannot be set to Provisional or it would be excluded
          from any MAV Target processing.

          If you do not wish for the SMS records to be included in any Target checking until the
          student actually submits their final selections then we would recommend displaying
          the CREATE_SMS functionality. Alternatively you might wish to consider logging a
          PMR request so that the Status to use within this functionality can be defined.

II (ii)       Submit Later: event of order
          Issue:
          I select an optional course, submit this selection and submit later. It
          creates a SMS.
          - If I hit Clear button or Clear all selections: the SMS is not deleted in
          client server as I would have expected (though it is not displayed on the
          registration screen).
          - I then click Select, choose a new option and submit this new selection: it
          is only then that the previous SMS is deleted on client server.
          It could have implication for users when they check their timetable and
          see courses they have cleared.
          System works as follows:
          It is designed to only remove the SMS record when it absolutely has to
          and this means that the SMS will be removed by validation (as it might
          affect the processing of entry requirement rules and checks for previously
          selected courses) and during submission (to ensure that only the selected
          records are then held in SMS). The Clear button does not touch either SDL
          or SMS records as there is no need for it to do so at that point. This does
          mean that the SMS record will remain after the Clear option has been
          used.




                                                                                     Page 47 of 47

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:35
posted:6/26/2011
language:English
pages:47