Top of SSF

Index

Table of Contents

Feedback

Student Unit Attempt Maintenance Application

This section includes:

• Student Unit Attempt Maintenance Application
• Validations Performed During Processing
• Shopping Cart
• Transactions

Student Unit Attempt Maintenance Application

The Student Unit Attempt Maintenance Application (SUA-UPD) is used to maintain the users student unit attempts.
It may also be used to maintain activities for a student's unit attempts. See SSFF1210 - Maintain Shopping Cart configuration.

When a user enters the application for the first time, they may see unconfirmed student unit attempts already listed. These are the units that have been pre-enrolled against the student's course attempt through the batch pre-enrolment process (ENRJ3100).

A user will be able to perform several transactions within this application depending on the status of student unit attempts listed. Selecting radio buttons located next to the unit offering options performs the transactions.

For unconfirmed student unit attempts, user's can either confirm the unit attempt or modify it. Modifying a unit attempt allows the user to select a different unit offering option (if available) by selecting the Modify link. This takes them to the UOO-SELECT web application in context where the available, alternate unit offering options are displayed. The alternative can be selected. When the Confirm button is selected, the new unit offering option is inserted in place of the original and the student unit attempt status is updated to ENROLLED. For further details on selecting unit offering options refer to the UOO-SELECT (unit offering option select) application.

For discontinued student unit attempts, user's have the option of reversing the discontinuation. Reversing the discontinuation changes the student unit attempt status to ENROLLED.

User's can delete or discontinue an ENROLLED unit depending on the unit discontinuation date criteria. Optionally they can modify an enrolled unit attempt. When discontinuing a student needs to enter a reason. Thus two fields, 'Discontinuation Reason' and 'Reason Text' are displayed. The student will not be able to exit from the Shopping cart until one of these two fields has data entered into it.

Where a student unit attempt is INVALID, user's can delete the unit offering option depending on the unit discontinuation date criteria. Invalid units may only be created before the invalid rule cutoff date alias is reached (ENRF01F0),

Next to the radio buttons provided (for example: discontinuation or delete), a reset radio button is provided to cancel the selected choice.

User's also have the option of adding student unit attempt's to their course attempt. Links are provided to allow a user to search for a new unit (UNIT-SRCH application) or to continue adding from a previous search (enters UOO-SELECT in context from the last search).

Validations Performed During Processing

When a user attempts to perform a transaction (for example: confirm a unit or discontinue a unit) several validations are performed to ensure the transaction is valid, these are:

• The system enrolment step type UNITS exists for the user's enrolment period.
• There is no advanced standing recorded for the unit for the user's student course attempt.
• The student unit attempt is in the ADD-UNIT cohort process window, if one exists.
• The student unit discontinuation is in the DROP-UNIT cohort process window, if one exists.
• The SSF Avail check box for the unit offering option is 'checked'.
• The student unit attempt location and/or attendance mode matches the user's student course attempt forced location and/or attendance mode (if it exists) and the CHKFORCED enrolment step is mandatory.
• The unit is not a duplicate unit.
• The unit is not a superior unit in a unit relationship. (Subordinate units must be selected and confirmed before selecting superior units).

 Additionally, there are several validations performed according to the transaction being processed. These are:

• Where a student unit attempt is being added/confirmed or reinstated, the end date of the teaching period of the unit must not be less than the current date.
• Where a student unit attempt is to be confirmed, the student unit attempt must be UNCONFIRM.
• Where a student unit attempt is to be modified, the student unit attempt must be ENROLLED or UNCONFIRM.
• Where a user attempts to reverse the discontinuation of a student unit attempt, the student unit attempt must be DISCONTIN.
• Where a user attempts to delete a student unit attempt, the unit deletion date for the teaching period must not have passed.
• Where a user attempts to discontinue a student unit attempt:
• The unit deletion date for the teaching period must not have passed.
• The enrolment step UDISCONTIN must exist.
• The administrative unit status must be able to be defaulted.

Shopping Cart

This function provides users with the ability to manage their enrolment within the Shopping Cart.

Depending on Unit Rules, Course Rules, System Wide Rules, Cohort Processing Windows and settings in SSFF1210, users have the ability to:

• ADD new units
• CHANGE existing unit offering options (p_action_data = MODIFY)
• CONFIRM pre-enrolled units
• DELETE enrolled units
• DISCONTINUE enrolled units and
• REINSTATE discontinued units
• DELETE unconfirmed units
• SELECT Activity Offerings for Units

The Shopping Cart displays the user’s Student ID, Given and Surname Name, Course Code and Course Title, and Course Status.

The Shopping Cart displays the user’s current and newly added Student Unit Attempts for that Academic Year.

The Shopping Cart colour codes current, new and invalid units:

• Current SUAs are clearly distinguished by colour
• New UOO are clearly distinguished by colour
• Invalid SUAs are clearly distinguished by colour.

These colours are configurable by the client by means of a Cascading Style Sheet.

The Shopping Cart hosts a Basic Search function.

The Shopping Cart hosts a link for the Advanced Search function.

The Shopping Cart allows the selection of Activities for each unit attempt - if Attend is enabled in SSFF1210.

The Shopping Cart displays a ‘Check Out’ button.

Should a user log out of Callista Connect prior to selecting the ‘Check Out’ button to update their current enrolment with the contents of the Shopping Cart, the contents of the Shopping Cart are saved.

Actions applied to the Shopping Cart, are stored in the SCART_ITEM table(new). When the user applies these actions (Check Out) to their SUA, the SHOP_CART completed date will be set.

The current Shopping Cart for a user is the record with completed date (COMP_DT) set to NULL.

On entry to the Shopping Cart application, the students current enrolment will be displayed (this may or may not have units). Fields displayed by the application, will include;

header information
person_id
surname
preferred given names
course_cd and title
course attempt status
Unit details
teaching period
unit cd
campus
unit_class
unit_attempt_status
enrolled credit points
study load
achieved credit points
exam location

Upon returning from UNIT-SRCH or BASIC-SRCH the REMOVE action is available to newly selected units.

Any processing (for example, call of the update routine) related to the selection of the “Action” checkboxes will be effected anytime that the following steps (buttons, links pressed) are taken;

• 'Proceed to Check Out',
• 'Search' Or
• 'Advanced Unit Search'

Only units that have modifications effected are entered in the SCART_ITEM table. These units are displayed on the printed receipt.

The additional units are sourced from UOO_SESSION_UOOID from the students’ unit selections. Module ssfp_prc_scart_action transfer selected UOO’s to the SCART_ITEM table. The 'Action' of 'REMOVE' deletes the unit from the SCART_ITEM table with no rules checking.

'Proceed to Check Out' navigates the user to;

• The 'Confirm' button applies the changes. This screen will appear when 'Auto Commit' is set to ‘N’
• The 'Breach' button displays the rule breach message for the student
• The 'Cancel' button removes all unit selections at this stage

The user is taken directly to this screen from ‘Screen 2’ when 'Auto Commit' is set to ‘Y’.

'View Current Enrolment' handles within this template (SUA-UPD). A CCONDITIONAL argument is passed when the button is pressed allowing for the distinct display of the current SUA. A 'BACK' button passes a similar argument to return to the main Shopping Cart. Therefore, the appropriate portion of the Shopping Cart template has a CCONDITIONAL to handle the return from the Current Enrolment screen.

To select Activities for Student Unit Attempts, click on the Select Activities button and a screen like the one below will be displayed. Unit Activities or Activity Groups can be selected as in SUAAO-UPD.
See the Online Student Class Activity Allocation page for details about SUAAO-UPD and for more general information about Calista Attend, see the Attend Overview page.

Transactions

It calls a function that checks if the application Log Transaction check box in Maintain Self Serve Applications (SSFF1100) is set, and when it is, log the details of successful transactions.

The application page displays a receipt after each transaction has been successfully run if the Issue Receipt check box (SSFF1100) is set, as well as send an email to the user whose data is being modified if the Issue Email check box is set for the application on the SELF_SERVE_APPLICATION table (SSFF1100).

After the emails and receipt are successfully issued then the transaction log is updated to include that an email and or receipt was issued and the email Address that it was issued to.

An example of a Shopping Cart Receipt:

The fields to log and the sequence to log them in are:

The blue field is specific to HE sector and will not be logged for VET sector.

The orange fields are specific to VET sector and will not be logged for HE sector.

* These fields will be repeated for each Student Unit Attempt that the student is enrolled in.

** These fields are not actual logged values, instead they represent headings for sections of the logging and are there to allow easier identification of different logging sections. They only appear once at the start of each section.

*** These fields will be repeated for each Unit Selection that the student has made in the transaction.

**** These fields are repeated for each Activity Selection that the student is currently allocated to.

^ Denotes fields that need to be retrieved from the database prior to logging.

Note: Logging of the transaction parameters for this function actually logs the parameters with the same old and new value in every case. This is because there are many old values and new values, so to capture the old and new status, we instead log each value on its own line to give a complete context.

These parameters are logged into the SELF_SERVE_TRANSACTION_DETAIL table, however the old value and new value columns always contain the same value. This data is included in the log as contextual reference for administrators reviewing the log.

The complete list of parameters that are logged and the order in which they are logged is:

Last Modified on 14 August, 2008 6:17 PM

History Information