Top of ADM

Index

Table of Contents

Feedback

Admissions for the Subsystem Specialist

This section of the user manual provides specialist users (such as system administrators and subsystem specialists) with the information required to set up and maintain the reference data used by the Admissions subsystem, and to perform the specialist functions available in this subsystem.

An introduction to, and an overview of, the day-to-day operation of the Admissions subsystem is provided in Understanding Admissions.
Information regarding the use of a specific form is obtained by selecting a link to that form in the text below or selecting from the Subsystem table of contents.

Topics covered here include:

• Admissions in ADMW1000, ADMW1100 and ADMF3000
• Setting Up the Admissions Subsystem
• Setting Up Admissions Reference Data
• Setting Up Admission Process Categories and Their Steps
• Setting Up Security Role Access to Admission Steps
• Linking Course Offering Options to Admission Categories
• Configuring Admission Calendars
• Admission Calendar Rollover
• Changing Admission Dates
• Admissions Subsystem Processes
• TAC Admission Processes
  • TISC
  • UAC
  • QTAC
  • VTAC
• TAC Admissions
• TAC Academic Results Requisition
• Discontinuation Date Logic
• Treatment of RPL units
• TAC Request for Enrolment Statistics
• Other Admission Processes
• Producing Admission Enquiry Packages
• Defining Admission Correspondence
• Letter Phrases
• Letter Parameters
• Letter Rules
• System Letters
• Admission Letter Templates
• Linking System Letters to Admission Process Categories
• Production of Acknowledgment Letters
• Production of an Outcome Letter
• Producing Admission Letters Via a Batch Process.
• Student Intake Targets
• Derivation of Expected Completion Period/Year

Admissions in ADMW1000, ADMW1100 and ADMF3000

Admission Applications can be viewed and processed via ADMF3000 (webforms) or ADMW1000 (Callista ADF).
The reference data, processes, validations, etc. utilised in each location are the same, however ADMW1000 introduces Admission Application Assessor and Administrative users. For more information about these users refer to ADMW1000-Assessor View and ADMW1000 - Administrative View. Assessors from outside the institution may be given access to the Admission Assessor page (ADMW1100) which gives the assessor access to Admission Applications assigned to them for which they can make comments, attach documents or update the Assessment Status to approve or reject the application.

Setting Up the Admissions Subsystem

The typical activities required to set up the Admissions subsystem are:

• Create the required reference data for the functionality being implemented.
• Having defined the required Admission Categories and mapped appropriate Enrolment, Fee and Correspondence Categories to them, create Admission Process Categories and their steps.
• Where required, refine Security Role Access to Admission Steps.
• Link the Course Offering Options to the category or categories to which they are available.
• Configure Admission Calendars (This may have been done as part of the system-wide calendar set-up.)

Setting Up Admissions Reference Data

In order for the Admissions subsystem to function effectively, the following reference data must be created and maintained:

The documentation for each of the reference data forms above details any functions or rules specific to those forms.

Setting Up Admission Process Categories and their Steps

Admission Process Categories represent the various Admission Processes of the institution, established to cater for groupings of applicants or Course Types with like Admission requirements. Callista can be configured to accommodate these Admission Processes.

At the commencement of a Callista Admissions session, an Admission Process Category is specified. This Admission Process Category is then associated with all new Admission Applications processed within that session. When an existing application is modified within the same session, the Admission Process Category already associated with the application is used rather than that set in the session details.

Admission Process Categories define a particular Admission procedure by specifying the steps involved in the procedure.

Recorded in the System is the set of all steps identified as belonging to any type of Admission Process. These steps are grouped according to the type of Admissions information involved. When an Admission Process Category is created, the steps for that procedure are allocated to it from the set of all System defined steps. The procedure can be further refined by adjusting the order in which the steps are displayed to System users.

Each step equates to either a form, a T-list item or a database process (such as a validation to be performed) within the Admissions subsystem. Including a step means that the corresponding screen, T-list item or database process is displayed and/or can be used. For example, by specifying the step ALIASES for an Admission Process Category, when that Admission Process Category is used for a session, the 'Aliases' button is displayed in ADMF3000 and the Maintain Person Aliases form (ENRF3020) can be accessed for the recording of the applicant's alternative names.

When a particular Admission Process Category is used in an Admissions session, users are presented with only those buttons, (and hence screens) and T-list items, required to perform the steps associated with the Admission Process Category. The Admission Process Category definition also determines whether certain activities can be performed, such as whether late applications are allowed and whether deferment is permitted.

Setting up an Admission Process Category and its steps is done in ADMF2M30 and involves:

• Selecting the Admission Category for which the procedure is being defined
• Assigning a System Admission Process type to the category, creating an Admission Process Category (System Admission Process types are detailed in Understanding Admissions)
• Assigning the steps for that procedure to the Admission Process Category

Detailed explanations are provided for the Maintain Admission Process Category Detail form (ADMF2M30). A list of all Admission Steps and information about each is also provided.

Setting Up Security Role Access to Admission Steps

Earlier paragraphs describe how the Direct Admissions (ADMF3000) and Maintain Admission Course Application (ADMF3240) forms are dynamically configured to display only the buttons and T-list items specified for the Admission Process Category in use at the time, with each button and T-list item representing a step in the process. The ability of individual users to access the forms, screens and T-list items invoked by these buttons is controlled by the security roles and person privileges granted to the individuals.

An additional layer of security is applied to T-list items. Users with access to a T-list item by way of a security role or person grant are initially only able to view the T-list item data. The ability to update T-list item data is granted via the Maintain System Admission Step Access form (ADMF02O0). The form is used to grant update access for T-list Admission Steps, to security roles. Only those users with a security role with the appropriate form grants and step access grants can update T-list items.

Callista provides 'intelligent' display of T-list items so that T-list items are only displayed when they are required. For example, the Conditional Offer T-list tab is only displayed when a conditional offer has been made. This is determined by the application having a 'system Admission outcome status' of COND-OFFER. A list of the conditions under which T-list items are displayed is provided.

Linking Course Offering Options to Admission Categories

The Course Offering Options potentially able to be offered (see Configuring Admission Calendars, below, regarding restrictions imposed on potential offerings) in an Admission Period are determined by the Admission Categories associated with the Admission Period and the Course Offering Options linked to those Admission Categories. This linking is performed in CRSF1320.

Configuring Admission Calendars

The Admissions subsystem relies on pre-defined Admission Periods and key dates for its operation. It is recommended that Admission Calendars be established for an academic year and then the Calendar Rollover process be used to create framework Admission Calendars for future Academic Periods. These can then be modified as required.

Typical steps in the setting up of Admission Calendars are:

• Use CALF0220 to set up calendar instances representing Admission Periods (calendar category = ADMISSION). Each Admission Period within an Academic Period should have a unique name (Calendar Type). It is recommended that each Admission Period's Start and End Dates roughly correspond to the enrolment period to which it applies. This may not always be achievable where more than one Admission Period (for different cohorts of students) relate to a single enrolment period.
• Use the Calendar Relationships button to navigate to CALF0330.
• In CALF0330, link each Admission Period to both its superior academic and teaching periods. This linking is used in ADMF3250 to determine teaching periods and hence unit offerings relevant to a particular commencement period. For example, a mid year Admission Period is relevant to units offered in semester 2 but not to units offered in semester 1 or year long. Link each Admission Period to its subordinate enrolment period. This linking is used by the pre-enrolment process to determine the enrolment period in which applications belonging to a particular Admission Period should be enrolled. This means that an Admission Period can have only one subordinate enrolment period.
• In CALF0420, create institution defined Date Aliases to represent the critical dates listed in ADMF02R0 - one only for each critical date. (use a Date Alias category of ADMISSIONS or similar and a Calendar Category of ADMISSION).
• Record the names of the Admission Date Aliases created in the previous step against the critical dates in ADMF02R0. (Each date critical to the operation of the subsystem is listed here.)
• Return to CALF0220, locate the previously created Admission Periods and use the Date Alias Instances button to navigate to CALF0512.
• Using CALF0512, create the required instances of each of the Admission Date Aliases for each Admission Period.
• Configuration of particular Admission Periods is continued using the Maintain Admission Period Calendars form (ADMF2M61) as described immediately below.

The modification of Admission Calendars following use of the Calendar Rollover process uses the same process and forms.

The kinds of Admissions which are valid in particular Admission Periods are controlled (restricted) by the configurations recorded in the Maintain Admission Period Calendars form (ADMF2M61). In this form:

• The categories of Admission Applications which are allowed in an Admission Period are recorded.
• The Process Types available to each 'Admission Period-Admission Category are recorded'.
• For each 'Admission Period-Admission Category-Process Type' combination, the course offering patterns on offer can be restricted to offerings at particular Locations and/or particular Attendance Modes and/or Attendance Types. An example is where a mid year intake of students is restricted to offerings of a course at a particular campus. (Note: The Course Offering Options potentially available to an 'Admission Period-Admission Category-Process Type' combination are those linked to the Admission Category in CRSF1320.)

Admission Applications for invalid course offering patterns can still be processed, however, these applications will result in Correspondence being generated advising the applicant that the offering pattern is unavailable.

Admission Calendar Rollover

Admission Calendars are rolled over using the Calendar Rollover process. This process does not roll over the Admission Period Category/Process/Course offering restriction details attached to Admission Periods (in ADMF2M61). To rollover Admission Period details:

• The Calendar Rollover process must first have been performed in order that the new Admission Period instances exist, also enabling the System to identify the source instances when performing the Admission Calendar Rollover process. The usual situation would be to roll forward the academic year calendar and all its associated calendars and Date Alias instances, which includes Admission Calendars. The dates defining each calendar instance are checked in the Rollover Calendar report (CALR0320) and adjusted where necessary, as are related Date Alias instances.
• The Course Structure Rollover process must first have been performed in order that rolled over 'Admission Period Course Offering Option restrictions' can be created to the new Course Offering Options.
• A query is executed in ADMF2M61 to locate each new Admission Period.
• As a relevant Admission Period is displayed, the Admission Period Rollover button is selected. The System recognises which Admission Period the displayed period was rolled from and rolls Admission Category, process type and Course Offering Option restriction information from the source period to the new period. Where all Admission Periods for an Academic Period are to be rolled over, the Admission Period Rollover (Batch) process (ADMJ2M63) should be used. This process rolls over all Admission Periods for an Academic Period.
• Check the Admission Calendar Rollover Report (ADMR1060) if any warnings were encountered during the Admissions Rollover process.
• Any required amendments to the rolled over data are made in ADMF2M61.

Note: Calendars can be rolled as far into the future as required i.e. the 2002 calendar structure must be rolled into 2003 to be able to rollover the 2002 Admission Period details. However it could also be rolled into 2004 and 2005 and so on if the institution carries out its planning well in advance. To operate effectively, the Admission Deferment process requires that calendars be rolled far enough into the future to enable the recording of the Admission Period, Admission Category and Admission Process Type which will apply to the deferred course application, when the deferment period ends. Otherwise the user will not have an Admission Period to defer the applicant to. Another solution is to limit deferment to periods of 12 months, renewable.

Changing Admission Dates

This function allows the dates set up for an Admission Period Category to be adjusted without 'losing' the original dates. A typical use is the extension of an Admission Application closing date where the extension only applies to particular Locations, Attendance Modes or Attendance Types. This date variation function is carried out using the Maintain Admission Period Date Overrides form (ADMF2M62).

The ability to vary a date only applies to the System Date Aliases (see ADMF02R0):

• Due Date Alias
• Final Date Alias
• Offer Response Date Alias

For example:

• The Calendar Rollover process has created a new Admission Period with a 'course application closing date' of 1 October 2004. The institution determines that whilst this date is correct for most courses, on this occasion 'off-campus' applications for a particular Admission Category should close later than other courses, on 20 October. The new closing date is recorded for off-campus mode only in ADMF2M62.
• When recording an application for Admission in ADMF3240, the Direct Admission Process checks the options entered for each course application. When the System encounters an application for on-campus study, it checks for any on-campus override matches. None exist, so the application closing date is 1 October. When the System encounters an application for off-campus study and checks for off-campus override matches, it finds a match (provided that no other attributes which would exclude this application were defined for the override record) and the closing date for that application is 20 October.

It is possible to exclude or include these override dates in the Admission Calendar Rollover process (CALF0320), although inclusion is not recommended.

Admission Subsystem Processes

TAC Admission Processes

In the past, Callista had developed a number of processes to upload and extract Tertiary Admission Centre (TAC) files for different state formats. These different TAC processes are currently developed and maintained in isolation. This is duplicating effort and therefore cost.

Callista now has added client institutions (including the University of Western Australia (UWA) and The University of New England (UNE)), to delivery TAC functionality. Callista continues to develop functionality for the loading of Tertiary Admission Centre (TAC) offer data and the extraction of return data.

Callista provides an upload solution for TAC files and Callista SMS, with the following TAC interfaces supported as a minimum:

• TISC – Western Australia
• UAC – New South Wales
• VTAC – Victoria
• QTAC – Queensland

Current processes include:

UAC

UAC supply Institutions with access to a data warehouse of applicant data that have been made offers at the Institution. Institutions extract a set of files. The data from these files is uploaded into Callista for the purpose of generating applicant offers.

Institutions are required to update the return file provided by UAC for offers made. The information provided includes enrolment code (enrolled, deferred, or not enrolled), student number, attendance type and attendance mode.

For online documentation on UAC Offer Files, see ADMJ4500. For UAC Return Files, see ADMJ4550.

VTAC

VTAC supply Institutions with an Undergraduate and Postgraduate offer file. The data from these files is uploaded into Callista for the purpose of generating applicant offers.

VTAC supply Institutions with a Return file consisting of applicants who have been made an offer at that Institution. Institutions then update the Return file with details of applicants who have accepted an offer at the Institution and return the details to VTAC.

For online documentation on VTAC Offer Files, see ADMJ4200. For VTAC Return Files, see ADMJ4300.

QTAC

QTAC supply Institutions with an Undergraduate and Postgraduate offer file. The data from these files is uploaded into Callista for the purpose of generating applicant offers.

QTAC supply Institutions with a T-List Return file consisting of applicants who have been made an offer at that Institution. Institutions then update the T-List Return file with details of applicant who have accepted an offer at the Institution and return the details to QTAC.

For online documentation on QTAC Offer Files, see ADMJ4400. For QTAC Return Files, see ADMJ4550.

Callista continues to reduce procedures, while managing the different requirements of TAC in each state, by producing diverse upload processes.

TAC Admissions

The TAC Admissions processing was initially built to specifically handle VTAC processing. VTAC processes are described here, although processes for other state TACs are similar (QTAC/TISC/UAC).

As a general rule, institutions are required to set up their own reference data to enable their individual TAC process to complete successfully. For more information, see the technical information for the latest Release in the Callista Product Centre: wiki.callista.com.au/display/CDC.

A broad outline of the TAC Admission Process is provided in Understanding Admissions.

The TAC provides the institution with a files containing details of applicants who have been offered places at the institution and the courses they have been offered. The process to load this information into Callista is:

• The job ADMJ4200 (ADMJ4210 for Postgraduate Offer File) is run through job scheduler. This process:
• Invokes a parameter form where the location (directory/file path) of the TAC 'offer round' file is recorded.
• 'Gets' the offer round file and either creates a New Person record for each new (to Callista) applicant or locates the record of existing (in Callista) applicants.
• Loads personal (where applicable) and Admission related data for each applicant to the Admissions subsystem. Admissions subsystem functionality is then applied in a similar manner to Direct Admission Processing.

 

TAC Academic Results Requisitions

Current or previously enrolled students may apply for Admission to other tertiary institutions. To complete their Admission Application, the prospective institution requires information on the students' results at their prior institutions. The results requisition process allows for the electronic transfer of these to TAC for distribution to the institutions to which the students are applying. This process includes the requisition of Honours level records as well as Under-graduate records.

Note: While the TAC academic results requisition processing has been built to accommodate VTAC requirements, the core processing is common to all state TACs. For example, QTAC, TISC UAC. The job that initiates this process may require modification to meet local requirements. Your System Administrator should be consulted.

Processing of the TAC academic results requests involves:

• Initial set-up by the System or Database Administrator. A variable , 'TAC', is set up in the Job Control table. It contains the path to the directory in which the TAC data files are located.
• TAC sends an electronic request for academic results which is located by the job in the process below. This is a list of students for whom the results are required.
• TAC may also send a Result Acknowledgement file, which should be placed in the 'TAC' directory. This contains information on the outcome of validations performed on a previously sent result file. If errors are detected in this file by the process (ADMJ4100), then the process will write a message to the job scheduler run log and will not process any more request files until the Result Acknowledgement file is removed. The Result Acknowledgement file will need to be checked manually to see what the errors are and how they are to be resolved.
• The TAC Automated Result Transfer System Extract Process (ADMJ4100) is run through job scheduler. The process looks in the 'TAC' directory for a '.req' file (the request for results). It then:
• Verifies the format of the file and writes problems to error records in the Request Acknowledgement file. If no problems are found then only a header record is written to the Request Acknowledgement file.
• Attempts to match each TAC record against a Callista record.
• Obtains the student results for each match (student course and unit attempt results as well as additional ARTS Notes information on Awards, Enrolment Notes, Encumbrances, Prize Details and Scholarships) and writes them and any unmatched records to a results file.
• The results file is filed in the 'TAC' directory for later access by TAC.

For further details on the result transfer system, refer to the Automated Results Transfer System Users Guide Version 2 produced by the ACTAC.

Discontinuation Date Logic

The job ADMJ4100 includes a Course Attempt record which has a field called the Equivalent Full Time Years Enrolled. When determining the value in this field the SMS function excludes the Student Unit Attempts that have an Administrative Unit Status mapped to a Unit Attempt Status of DISCONTIN that has the Withdrawn Late Without Academic Penalty Indicator set.

This complements the existing logic; the existing load based logic is still used for calculating the value for the Results File Course Attempt Equivalent Full Time Years Enrolled. When a student is withdrawn from a unit, prior to the Census Date, then they have not incurred load and are not included in the calculation.

Example

When a student is withdrawn after the Census Date; the student is withdrawn late.

The process examines the records that have a Discontinuation Date and determine if the EFTSL should be included in the calculation of Equivalent Full Time Years Enrolled, based on the Administrative Unit Status (see 'Discontinue' in T-list of ENRF3000 - Unit Attempt screen) and the value of the Withdrawn without Academic Penalty check box (set in ENRF0110). If it is set, then the student’s unit is not included and if it isn’t, then the student’s unit is included.

Treatment of RPL Units for TAC Academic Results Requisitions

RPL units may be recorded in ADVF4200 or ENRF3000. The derivation of some fields for RPL records differs slightly according to where they are recorded. i.e.

• Year Enrolled - For Advanced Standing RPL Units, the Granted Date is used to determine the Year Enrolled. For RPL Units recorded in ENRF3000, the Student Unit Attempt Teaching Period is used.
• Student Status Code - The Student Status for RPL Units recorded in ENRF3000 will be determined as for other Student Unit Attempts. For RPL units recorded in Advanced Standing, the Student Status is obtained for the Student Course Attempt from the STUDENT_COURSE_HECS_OPTION table.

TAC Request for Enrolment Statistics

The process has been built to handle TAC only at this stage, however, the data extraction process is generic and can be used by institutions in other states. Refer to the Technical documentation in the Callista Product Centre (wiki.callista.com.au/display/CPC). For details of the TAC enrolment statistics return, refer to the relevant TAC handbook.

Processing of TAC enrolment statistics involves:

• Initial set-up by the System or Database Administrator. Two directories, namely TMP and OUTPUT are environment variables which should have been specified in s_job_control. For further information regarding environment variables, refer to the technical information in the Callista Product Centre (wiki.callista.com.au/display/CPC).
• TAC advises the institution that the 'enrolment statistics request file' is available. This file contains records of those applicants offered places by TAC on the institution's behalf.
• The request file is copied to the TMP directory.
• The process ADMJ4300 (for example, VTAC), produces statistics of the applicants offered places by TAC who have subsequently been enrolled by the institution.

The process ADMJ4300 (for example, VTAC), is run through job scheduler. It:

• Displays a parameter form which is used to nominate the Academic Period for which the return is to be prepared and the physical locations of input, output and error files.
• Checks that the TAC applicant is recorded in Callista.
• Creates a file with a record for each applicant indicating whether or not the applicant is enrolled in Callista. This is the file returned to the TAC.

Other Admission Processes

Producing Admission Enquiry Packages

Admission enquiries are processed to allow the creation of Enquiry Information Packages and Address Labels for mailing. The process to create the enquiry information packages is:

• To run the job Process Admission Enquiries (ADMJ1320) through job scheduler. (This process would normally be scheduled as a standing request to run nightly). This process:
  • Updates the status of REGISTERED or ACKNOWLEDGED enquiries or BOTH.
  • Updates the Last Processed date and sets the Mailed date for all items that can be mailed.
  • Creates a Person ID group of all enquiries processed.
• Run the Enquiry Status Report (ADMR1340) which produces a list of items to be mailed to each person in the ID group.
• Run the Person Address Labels report (IDGR2100), which produces an address label for each person in the ID group.

Defining Admission Correspondence

The Admissions subsystem relies on pre-defined Correspondence Types of OUTCOME-LT and ACKNOW-LET for communicating to students about their current applications. It is recommended that at least one outcome and acknowledgment letter is created and assigned to the Admission Process Categories in use by the institution. A typical setup would follow the following process. Refer to the Correspondence Subsystem for further information.

Letter Phrases

Institutions are able to define all common phrases that will be available to the Admissions user. These phrases are generally used to communicate to the student specific details that apply to the application. For example, an institution may wish to communicate to a student the documentation that is required to be presented before an application can be considered. These letter phrases are maintained using the Maintain Letter Phrase Form (CORF2550).

Letter Parameters

Institutions are able to define the data that will appear in an acknowledgement or outcome letter. By mapping Letter Parameter Names to System Letter Parameter Types, institutions can determine what information is to be made available for Admissions Correspondence. These letter parameters are maintained using the Maintain Letter Parameters Form (CORF2510) and rely on Admissions letter parameters, for the system letter parameter type definitions.

Letter Rules

Institutions are able to define text that will appear in an acknowledgement or outcome letter dependent upon a number of statuses passed from Callista to the rules engine. By mapping letter parameters to parameters of type ADM_RUL.htm#, institutions can determine the exact nature of text that will appear and its location within a template. Admission Correspondence rules are maintained using the Maintain Group Rules Form (RULF2001) and rely on Admission Correspondence Rules, for the standard set of rules.

System Letters

Institutions are able to define multiple system letters for the Correspondence Types OUTCOME-LT and ACKNOW-LET. System letters contain the letter parameters and word template filename that will be used to create a letter. System letters for Admission Correspondence must be mapped to Admission Process Categories, to take effect. System letters are maintained using the System Letter Form (CORF2520).

Admission Letter Templates

Admission Letter templates are designed using Microsoft Word, and generally contain all the letter parameters that have been assigned to a system letter. Admission letter templates must be stored in the template directory specified in control.doc. The file 'control.doc' (supplied with Callista) is required to be stored in the c:\tmp directory of each client machine from which letters are produced.

Linking System Letters to Admission Process Categories

System letters, defined for the Correspondence Types OUTCOME-LT and ACKNOW-LET must be mapped to Admission Process Categories. It is advisable to ensure that the Admission Process Category steps include the step type ADDRESS as a mandatory step. Applicants without a valid postal address, will not receive Admissions Correspondence. System letters are mapped to Admission Process Categories using the Admission Process Category System Letters Form (ADMF2M34).

Production of Acknowledgment Letters

Acknowledgment letter entries can be created for an individual application from the Direct Admission Course Form (ADMF3240). Acknowledgment letters will only be created if the appropriate step type has been included for the Admission Process Category.

• Select the Acknowledgment Letter button.
• Select the Letter button. This will navigate to ADMF3900.
• Assign the parameter codes to letter parameters for the Acknowledgment Letter.
• Select the Produce Letter button. This will invoke Microsoft Word and merge the appropriate data into the template. The file is automatically saved in the c:\tmp directory with the Correspondence reference number. To include this letter in a batch process, select the Reject Letter button.

Production of an Outcome Letter

Outcome letter entries are created for an individual application when the outcome status for the application is changed from PENDING to any other status, in the Direct Admission Course Form (ADMF3240). Outcome letters will only be created if the appropriate step type has been included for the Admission Process Category.

• Change an application outcome status from PENDING. Save the record.
• Select the Letter button. This will navigate to ADMF3900.
• Assign the parameter codes to letter parameters for the outcome letter.
• Select the Produce Letter button. This will invoke Microsoft Word and merge the appropriate data into the template. The file is automatically saved in the c:\tmp directory with the Correspondence reference number. To include this letter in a batch process, select the Reject Letter button.

Producing Admission Letters Via a Batch Process

Acknowledgment and Outcome letters that haven't been produced by the Produce Letter button in ADMF3900, and are composed (as indicated in ADMF3900), can be created using two processes. The first process is via the Produce Letters Batch Job (ADMJ5300). This job will create a log file containing the data from Callista to be used in the production of letters. This log file can be used to create all letters of type ACKNOW-LET or OUTCOME-LT, for particular outcome statuses. To produce the letters, the Batch Letter Production form (CORF2540) is used.

Student Intake Targets

Intake targets are used to establish and maintain the enrolment targets required by the institution.

At this time intake targets have no associated functionality. They have been included in Delivery Set 1.4.1 to allow institutions to record targets and extract them for use in third party software.

To record student intake targets:

• Ensure reference data is recorded in the Maintain Student Target Type form (ADMF2M41).
• In the Maintain Submission Intake Targets form (ADMF2M42), record submission period targets. Each year intake targets are reported to the Government for the submission period.
• Intake targets can be further defined in the Maintain Organisational Unit Intake Targets form (ADMF2M44). Intake targets are broken down for Organisational Unit and Funding Sources. Within these combination, targets can be defined for Course Type group, Unit Internal Course level and Attendance Mode.
• Using the Maintain Course Student Targets form (ADMF2M45), allows the intake targets to be further defined for each course and associated unit set as required.

Where an institution does not require the maintenance of targets for an Organisational Unit or course, the targets do not need to be recorded. These forms are only used to record targets the institution does wish to keep track of.

Derivation of Expected Completion Period / Year

When a potential student applies for Admission to a course of study, the system derives an Expected Completion Period and Expected Completion Year. These are displayed on the Direct Admission Course form (ADMF3240) against the T-List item Completion Period.

These derived values can be overridden where required (for example when advanced standing must be considered).

These values (recorded in Admissions as the expected completion period and year) may display in other subsystem forms as the Nominated Completion Period and Year. For example both the Student Course Attempt enrolment form (ENRF3000) and Student Course Attempt inquiry form (INQF1200) contain Nominated Completion Year and Period fields — the values displayed may be those recorded in ADMF3240. (The displayed values may differ from the derived expected completion period and year values where they have been entered as override values in Admissions and/or Enrolments.)

The derivation uses the following values:

• The Course Start Date Alias instance recorded (in CALF0512) for the current Admission Calendar.
• The standard full-time and part-time completion times recorded for a course version (Std FT or Std PT Cmpltn Time recorded in CRSF1210). The Attendance Type recorded for the Admission Application determines which (full or part-time) is used in the calculation.
• All instances of the three 'completion' Date Aliases. The institution-defined Date Aliases to represent Summer Comp Period, Mid Completion Period and End Completion Period are defined in form ADMF02R0 (Maintain Admission Calendar Configuration).

The expected completion period and year is calculated as follows:

• An Expected Completion Date is calculated using the formula:
  = Course Start Date Alias Instance + Std FT/Std PT Cmpltn Time
  
  (The full or part-time completion time value selected is based on the attendance type for this Admission Application. The Expected Completion Date can be displayed on ADMF3240 by setting the Display Derived Completion Date check box.)
• Convert Expected Completion Date to the academic year in which the course starts.
• Find the closest 'Completion' Date Alias instance that is <= Converted Expected Completion Date
• This determines the completion period (SUM, MID, END)
• Calculate the completion year
  = Academic Year of 'Completion' Date Alias + Course Completion Time

Example:

Resulting derived values:

Expected Completion Period = END

Expected Completion Year = 2004

Last Modified on 10-Oct-2014 1:23 PM

History Information