ADMJ3910 - Batch CHESSN Allocation Results

Purpose This function enables the request for and processing of results from a batch CHESSN Allocation Request
Subsystem Admissions
Normally Run By Administration Specialist
Anticipated Frequency As required
Structure Block CHESSN Allocation Report
Tab Parameters
Button Find Person (ADMF1211)

 

Specifically, this function will:

  • Identify outstanding results

    Before sending a results request to HEIMS, all requests with outstanding results must be identified. This includes:

    • Successful Requests where results have not been requested
    • Successful Requests where results have been requested but were not ready but now could be
    • Failed Batch CHESSN Allocation Results processes
      If a Batch CHESSN Allocation Results job aborts, no CHESSNs will be committed. Therefore when a new Batch CHESSN Allocation Results process is triggered a check must be done for previous failures or aborts of this job.
      The check will be against the Results Request Job Run ID in the HEIMS Request entity, for requests with a status of Process. If the identified job’s job scheduler status is ABORT or FAILED, the CHESSN Allocation Request must be included in the new Batch CHESSN Allocation Results process.
Callista Request Status HEIMS Request Status HEIMS Result Status Included Comments
Pending NA NA No  
Failed NA NA No  
Process NULL NA No  
Process Archive NA No  
Process Success Null Yes  
Process Success Process Conditional

Included If the Results Request Job Run ID relates to a failed job. For example, Cancelled, Abort, or Failed.

Excluded If the Results Request Job Run ID relates to a currently processing job. For example, Running, Scheduled.

Complete NA NA No


  • Request Results From HEIMS

    A request is sent to HEIMS containing the Request ID of the batch CHESSN allocation request. The request consists of a RequestControlTable only. The function will select and process one Request ID per results request transfer. From the list of outstanding Request ID, the lowest will be processed first.

    The process will request results for any outstanding HEIMS requests, based on the status of the request (i.e. where the status of the request is Process).

    When a results request is performed, the request’s Results Request Job Run ID will be populated with the Job Run ID for the job processing the results request.

    When sending a request for results for another Request ID, the password must be rechecked.

  • Receive Results From HEIMS

    The batch CHESSN allocation request will be identified within HEIMS from the Request ID within the RequestControlTable.
    Dependant on the processing status of the batch request, HEIMS will respond with an AllocateChessnBatchResponse including either:
    o A ResponseControlTable identifying the processed batch and its status, and a set of AllocateChessnOut records containing the CHESSN allocation results, or:

    • A Response Control Table only identifying the status of the request.

    Statuses in the ResponseControlTable include:

    • FAILURE: The Request ID given does not match an existing request – Message Code = 7
    • FAILURE: Invalid ClientOrganisationCode provided – Message Code = 12
    • FAILURE: Access to send or view results for the ClientOrganisationCode provided is denied – Message Code = 11
    • FAILURE: An existing Request ID was provided, but the Request ID was not for a batch AllocateStudentChessn method – Message Code = 10
    • PROCESS: Processing for this request has not finished – Message Code = 1 – 6 (The Results Request Job Run ID should be set to Null if the results being requested are still processing.)
    • ARCHIVE: The results for this request have been archived – Message Code = 9 (CHESSN allocation request results will only be kept for 30 days within HEIMS. After this they will be archived and any call to retrieve the results will return no results.) If Archived is returned a new request for the same transaction records should be initiated.
    • SUCCESS: Processing has completed and results returned – Message Code = None. When the results are returned the HEIMS Request Status must be updated to Success.

    When the ResponseControlTable is returned by HEIMS, the HEIMS Request record must be updated to reflect the latest HEIMS Results Status (i.e. Failure, Success, Process). The ResponseControlTable returned, after a results request, will contain a set of messages. These messages must be saved in the HEIMS Request Messages entity for the corresponding Request.

    When a Batch Request fails to process within HEIMS in a reasonable time HEIMS will fail the request. The Request Status returned to the HEP will be Failure when a Batch Results request is sent. The job will then be failed and no CHESSNs updated.

  • Validates the Results obtained from HEIMS

    Once the results have been received from HEIMS they will need to be validated. Validations include:

    • The CHESSN must be 10 characters in length.
    • The CHESSN must have no leading zeros.
    • The CHESSN must meet the HEIMS check digit algorithm.
    • The CHESSN must be numeric only, no alpha characters.
    • The person’s citizenship code must be 1, 2, 3, or 8.
  • Note: If one of the first five validations fail, an error must be reported and the CHESSN not updated. The process will then stop processing the CHESSN.

    • Does a Transaction Record exist for the returned CHESSN?

    If not, ignore returned CHESSN.

    • Does the person have an Active CHESSN recorded?

    If the person has an Active CHESSN recorded and the returned CHESSN does not match the recorded CHESSN; do not replace the CHESSN and report an error only.

    • Does the person have a Provisional CHESSN with a HEIMS validation date recorded?

    If the person has a provisional CHESSN with a HEIMS validation date recorded and the returned CHESSN does not match the recorded CHESSN; do not replace the CHESSN and report an error only.

    • Does the person have a Provisional CHESSN without a HEIMS validation date recorded?

    If the person has a provisional CHESSN without a HEIMS validation date recorded and the returned CHESSN does not match the recorded CHESSN, the Provisional CHESSN should be set to Invalid and the returned CHESSN loaded against the person. A comment should be recorded on the Invalidated CHESSN ‘Superseded by CHESSN <new CHESSN> in request <request id>’. This must be reported.

    • Is the CHESSN identical to any Active or Provisional (with a HEIMS validation date) CHESSN in Callista against a different person ID?

    If it is, do not insert the CHESSN or replace the existing CHESSN, report an error only. The error must identify the holder of the duplicate CHESSN. Manual client intervention is then required.

    • Is the CHESSN identical to any Provisional (without a HEIMS validation date) CHESSNs in Callista against a different person ID?

    If it is, set the matched CHESSN to Invalid, with a reason of ‘Superseded by a CHESSN for <person ID> in request <request id>’. The returned CHESSN should then be loaded against the correct person. For the person with the matched CHESSN record, a NOT-APPLIC CHESSN record must be created. This enables a new CHESSN to be obtained. This must be reported.

    • Does the person have an Inactive CHESSN that matches the returned CHESSN?

    If the person has an inactive CHESSN recorded and the returned CHESSN matches the recorded CHESSN; Set the inactive CHESSN to Active and report a warning.

    • Is a CHESSN returned for each person included in the request?

    If not, the CHESSN record for each person without a CHESSN returned must remain as is. The person can then be included in later CHESSN transaction requests. This must be reported along with a message ‘No CHESSN was returned by HEIMS’. The HEIMS reason for not returning a CHESSN must also be reported.

    • For each transaction record, HEIMS business rule validation messages must be validated and reported. Messages include:
HEIMS Result Status Message Code HEIMS Message Callista Message
Success 10201 All data fields identified as Mandatory must not contain a null value All data fields identified as Mandatory must not contain a null value
Success 10203 Invalid BirthDate The birth date provided is invalid
Success 10205 Invalid CitizenshipStatusCode The citizenship code is invalid
Success 10207 If AttendedYear12Code is equal to 'AttendedYear12’, then Year12State must not be empty The Year 12 State is blank
Success 10208 Year12State must be a valid Australian state The Year 12 state is not a valid Australian state or territory
Success 10209 If AttendedYear12Code is equal to ’AttendedYear12’, then Year12Year must not be empty The Attended Year 12 year is blank
Success 10210 If AttendedYear12Code is equal to ’AttendedYear12’, then Year12Number or Year12SchoolName must not be blank The Year 12 Student Number and School Name are blank
Success 10214 If AttendedPreviousHepCode is equal to ’AttendedPreviousHep’, then HepName and HepNumber both must not be blank (i.e. at least one of these 2 data elements must contain a value) The Previous HEP Name and Previous HEP Student Number cannot both be blank
Success 10215 If AttendedPreviousHepCode is equal to ’AttendedPreviousHep’, then HepYear must not be blank The Last Year of Enrolment for the previous HEP is blank
Success 10216 PostalCountryCode must be a valid code The country code is not a valid government country code
Success 10218 If PostalCountryCode is equal to ‘1100’ (code for Australia), then PostalPostCode must not be empty The post code must not be blank for addresses in Australia
Success 10221 The supplied CHESSN does not match an existing CHESSN in HEIMS The supplied CHESSN does not match an existing CHESSN in HEIMS. (Note: Only used for Get Entitlement processes)
Success 10222 FamilyName and BirthDate do not match those of the student the CHESSN is associated with FamilyName and BirthDate do not match those of the student the CHESSN is associated with (Note: Only used for Get Entitlement processes)
Success 10223 Invalid CHESSN The supplied CHESSN is Invalid (Note: Only used for Get Entitlement processes)
Success 10224 Year12Details must be present Year 12 Details must be present when the AttendedYear12Code is equal to ’AttendedYear12’
Success 10225 Invalid year for Year12Year Invalid year for Year12Year
Success 10226 If value of AttendedPreviousHepCode is equal to ’AttendedPreviousHep’, then PreviousHepDetails must be present Previous HEP details must be complete when the AttendedPreviousHepCode is equal to ’AttendedPreviousHep’
Success 10227 If value of AttendedPreviousHepCode is equal to ’AttendedPreviousHep’, then HepCode must be present Previous HEP Code must be provided when the AttendedPreviousHepCode is equal to ’AttendedPreviousHep’
Success 10228 If value of AttendedPreviousHepCode is equal to ’AttendedPreviousHep’, then HepCode must be valid according to the Government controlled list Previous HEP Code is not a valid Government HEP code
Success 10229 Invalid year for Hepyear Invalid year for HEP year
Success 10230 PostCode must be in the range of ‘0001’ to ‘9999’ Invalid Australian PostCode

    Failed validations will be stored in the HEIMS Transaction Messages entity for later reporting.

  • Load the Results into person CHESSN table

    When HEIMS processing has completed, results have been returned and Callista has validated the results, each Transaction record will be updated appropriately.

    Once CHESSN results have been successfully validated either:

    • NOT-APPLIC CHESSN records will be updated
    • PROVISIONL CHESSN records will be updated.

    If the results do not include a CHESSN for the person the CHESSN record should remain as is (i.e. NOT-APPLIC or PROVISONL and no validation Date). This ensures the records are included in another batch CHESSN transaction.

    Updated NOT-APPLIC records will include:

    • The CHESSN: Returned by HEIMS
    • Date CHESSN recorded: Sysdate
    • System CHESSN Creation Method: HEIMS
    • Status: Provisional
    • HEIMS Validation Date: Sysdate (Saved as a variable at the start of processing as the processing could be performed over more than one day.)

    Updated PROVISIONAL records will have:

    • HEIMS Validation date: Set to sysdate
    • Status: Set to Invalid only if the CHESSN is being superseded by the CHESSN returned by HEIMS.

    Where a Provisional CHESSN has been superseded by returned data, the pre-existing CHESSN should be set to an appropriate status (Invalid) rather than removed from the system. The superseded CHESSN would then require removal by the HEP after the HEIMS defined period.
    All records will only be committed at the end of processing.

  • Record Errors

    Any errors encountered will be logged for exception reporting. Errors will be logged to:

    • The HEIMS Transaction Messages and HEIMS Request Messages entities for any request or transaction data errors from HEIMS
    • The Job run log for any processing errors.

    Once the load has completed an exception report will be produced

This job is to be run in batch mode, taking into consideration the offline periods for HEIMS.

The following represents the requests for which results will be requested:

Only one instance of this job can be run at any given time. Job conflicts will be created to enforce this.

This job will also perform calculations to determine each student's remaining entitlement and identify any warnings based on Entitlement Position configuration (see ADMF0300). It will also record and update the person entitlement position table.
The job’s report will include all the identified entitlement positions with system outcome type of WARNING or CRITICAL. These will be grouped to allow the administrator to focus on the different outcome types. Critical outcomes will be clearly identified.

The following details are reported:

  • Person ID
  • Person Name
  • Outcome Text
  • Outcome Type
  • Entitlement Balance/Expected Balance

For each Entitlement/Outcome Type/Context combination, records with the same Entitlement Status are grouped together.

See ADMJ3900 for details of request and transaction statuses and meanings.

This job is accessed from the main menu.

 

The CHESSN Allocation Report contains:

Parameters Tab

  • Process Results check box
  • Request ID
  • Person ID
  • Transaction Status

    Button

Rules/Notes:

Validations include:

  • CHESSN returned from HEIMS does not confirm to HEIMS Algorithm
  • Cannot update person chessn with Government Citizenship Code other than 1,2,3 or 8
  • Does the returned CHESSN exist for any other person in Callista as Provisional with no HEIMS Validation Date?
  • Does the returned CHESSN exist for the current person in Callista as Provisional with no HEIMS Validation Date?
  • Does the returned CHESSN exist for any other person as Active or Provisional with a HEIMS Validation Date within Callista?
  • Does the returned CHESSN exist for any current person as Active or Provisional with a HEIMS Validation Date within Callista?
  • Does the returned CHESSN exist for current person as INACTIVE?
  • Does the returned CHESSN exist for current person as INVALID?
  • When the entitlement status cannot be derived, e.g. configuration is not correctly recorded  then an error is logged in the exception report.
  • If the course total EFTSL is not defined or is zero then a message is displayed in the exception report.
 

ADMJ3910 procedures are to:

1. Select all the requests for which results need to be processed in the ascending order, by Request ID, and process one at a time

2. For each record found (That is, for each Request ID):

  • Update Results Request Job Run ID of HEIMS_request table with the Request Job Run ID from the Request Job Run table and commit it
  • Reset the Request Object for the Request ID
  • Request the Results for the Request ID
  • Get the HEIMS server current Date and Time, or
  • Get the response of the request sent to HEIMS
  • Validate and loads transactions

3. Get the next Request ID.

4. Continue until no more requests (Request IDs) are found.

5. Any unexpected errors that are encountered during the request processing will be logged and the job aborts.

6. Report any identified student Entitlement positions with system outcome type of WARNING or CRITICAL.

 

The following table shows the student entitlement details returned from HEIMS and the Callista fields in which this data is populated.

Field

Callista Table

Callista Column

Record ID

HEIMS_TRANSACTION/
PERSON_STUDENT_ENTITLEMENT

PERSON_ID

Request ID

HEIMS_TRANSACTION/
PERSON_STUDENT_ENTITLEMENT

REQUEST_ID
CHESSN PERSON_STUDENT_ENTITLEMENT/
HEIMS_TRANSACTION
CHESSN

OrdinarySleUsage

PERSON_STUDENT_ENTITLEMENT

SLE_USAGE

OrdinarySleBalance

PERSON_STUDENT_ENTITLEMENT

SLE_BALANCE

Fee HELP Loan Balance

PERSON_STUDENT_ENTITLEMENT

FEE_HELP_LOAN_BALANCE

Calculation As At Date

PERSON_STUDENT_ENTITLEMENT

CALCULATION_AS_AT_DT

OrdinarySleLimit PERSON_STUDENT_ENTITLEMENT SLE_LIMIT
FeeHelpLoanLimit PERSON_STUDENT_ENTITLEMENT FEE_HELP_LIMIT
FeeHelpLoanUsage PERSON_STUDENT_ENTITLEMENT FEE_HELP_USAGE
CasLimit PERSON_STUDENT_ENTITLEMENT CAS_LIMIT
CasUsage PERSON_STUDENT_ENTITLEMENT CAS_USAGE
CasBalance PERSON_STUDENT_ENTITLEMENT CAS_BALANCE
CecsLimit PERSON_STUDENT_ENTITLEMENT CECS_LIMIT
CecsUsage PERSON_STUDENT_ENTITLEMENT CECS_USAGE
CecsBalance PERSON_STUDENT_ENTITLEMENT CECS_BALANCE
OS-HELP PERSON_STUDENT_ENTITLEMENT OSHELP_LIMIT
OS-HELP Balance PERSON_STUDENT_ENTITLEMENT OSHELP_USAGE
OS-HELP Limit PERSON_STUDENT_ENTITLEMENT OSHELP_BALANCE

For each transaction record that exists, the corresponding field values in the student's PERSON_STUDENT_ENTITLEMENT record are updated and pre-existing values in those fields are written to a history table.
e.g. For a student, the oshelp_usage = 1 in the PERSON_STUDENT_ENTITLEMENT table. If a new OS-HELP Usage value for this student of 2 is included in a transaction record, then that student's oshelp_usage in the PERSON_STUDENT_ENTITLEMENT table will change to 2 and a new record, where oshelp_usage = 1, will be created in the PERSON_STUDENT_ENTITLEMENT_HIST table.

Note: Student Learning Entitlement (SLE) was abolished on 1 January 2012, there is no longer a limit on the amount of study a Commonwealth supported student can undertake.

Last Modified on 15-Feb-2018 4:08 PM

History Information

Release Version Project Change to Document
20.0.0.1 Online Help Improvements Added note about SLE.
12.0 1456 SLE Usage Added information about the retrieval of Entitlement data.
10.1 1340 Compliance 2007 Pt 2 Added new os-help details and updated table.