VoS Responses to internal requests are created to include learners with additional enrolments. The system uses a default value of 51 weeks after the Study Start Date, in which to include such learners in the VoS Response.

The parameter SL_No_Weeks in the WEB_CONFIG table defaults to 51 on first installation. The minimum value that you can set this parameter to is 51 (maximum value is 999).

The SL_No_Weeks default value ensures that any new academic year enrolments are excluded that might overlap with the 52nd week, counted from the earliest reported course or qualification start date.

The following sections demonstrate how this functionality works:

• When dates are reported from a course:

  • The system retrieves the list of qualifications if they have at least a valid course where:

    Course Start Date >= Study Start Date, and Course Start Date is between Earliest Start Date (from previous Latest response with the same Study Start Date) and Earliest Start Date + SL_No_Weeks

  • The system then retrieves the list of child courses for these qualifications that are after the Study Start Date, and Course Start Date is between Earliest Start Date (from previous Latest response with the Study Start Date) and Earliest Start Date + SL_No_Weeks

• When dates are reported from a qualification:

  • The system retrieves the list of qualifications where the Qual Enrolment has a Qual Enrolment Start >= Study Start Date, and Qual Enrolment Start is between Earliest Start Date from previous response and Earliest Start Date + SL_No_Weeks
  • For every qualification determined as above, the list of child courses is retrieved. Dates on courses are not checked in this instance because the courses dates are within the qualification dates. If the qualification passes the dates restriction, the course also passes.

The VoS Response process prioritises Youth Guarantee (YG) concurrent programmes over non-YG programmes in order to convert the existing TEC Qual Codes on enrolments to YG codes.

The VoS Response process also prioritises Youth Guarantee programmes with the highest number of matching criteria to allow for multiple mappings of TEC codes to YG codes.

For each concurrent programme (CP), the priority of use is:

1. CP has a YG funding source specified

   and

   the learner is enrolled on all the courses with Qual Codes of that CP

   and

   the enrolments have a funding source that matches the CP

   and

   the learner’s age at course start date falls between the age range of the CP

2. CP has a YG funding source specified

   and

   the learner is enrolled on all the courses with Qual Codes of that CP

3. The learner is enrolled on all the courses with Qual codes of the CP

You can specify the length of time (in weeks) between study periods that the system considers a study break.

This allows you to adjust the study break time criteria at any time, in accordance with statutory requirements.

To report study breaks in the VoS Response, you must have the 'Study Break Time Period (weeks)' institution setting set up (on the StudyLinks screen).

In the VoS Response file, study breaks are reported for learners where the length of time between periods of study, exceeds the above specified value.

You can specify that study segments are reported in the VoS Response file, to ensure that education providers can correctly report study for learners who are studying in a flexible manner (some full-time and some part-time study).

To report study segments in the VoS Response, you must have set up the following StudyLink institution settings:

• Segment the VOS Response File - if you set this to Y, the system will determine the breaks in study that are greater than the number of weeks specified in the VOS Segment Time Period setting
• VOS Segment Time Period (weeks)

The system will determine the first, second and third breaks in study. For each study segment detected by the VoS response process, the system totals the EFTS (Equivalent Full-time Student) factors of the courses and reports the EFTS values proportionately (for example: three equal study segments with an EFTS of 0.3, will report 0.1 for each segment. Two study segments with EFTS of 0.4 and 0.2 respectively will also report 0.3 for each segment).

If the system detects four or more segments, it reports the first three as normal. The remaining segments are compressed into a single segment.

The start and end dates of this segment are the start date of the fourth detected segment and the end date of the last detected segment respectively.

You can send VoS Responses to update StudyLink about changes to the previous year's qualifications without picking up information about the current year's qualifications.

When an internal VoS Request is created, it must have an appropriate Study Start Date in order to pick up the relevant qualifications when a Response is made. This is achieved by doing the following:

• When a change is made that triggers an internal request (for example: fee update), the parent qualification for the updated UIO will be identified
• The start date (the People Units Special Start Date, or Unit Instance Occurrences start date if there is no People Unit special record) for this qualification will be used in the next steps
• The system will look for the latest STUDY_START_DATE External VoS Request for this learner on or before the previously found start date (but after the StudyLink current year start date)
• If no request is found by the preceding step, as a fall-back, the earliest request for this learner after this date will be identified
• The new Internal request is created with the same study start date as the previously identified external request

When an internal request is created as a result of an underpayment, the system will consider the latest external request with a response for the study start date, as there is no course context.

In the first two cases when an internal request is raised as a result of a fee change or an enrolment link, the system will also check the ‘include_fees_in_studylink’ flag against the parent and will only raise an internal request if the flag is ticked.

When reporting from courses, the system will use the actual enrolment whose fees are changed start date to identify the correct request. As the system reports from courses, it looks at the course which is changing the fees for start date.

When a response is created for an internal request, the data returned will be limited to a date range that is consistent with the original request. This is achieved by doing the following:

• Identifying the original external request for the learner by looking for the first external request for which the study start date matches that of the internal request
• Identifying the learner study start and end date from the response that was sent for the original request
• If reporting at qualification level, restricting the reported qualifications that are considered for the response to those that have a start date that falls within this date range

• If reporting at course level:

  • Identifying the parent qualifications for component courses that have a start date that falls within this date range
  • Identifying the date range for the set of qualifications
  • Restricting the component courses that are considered for the response to those that have a start date that falls within this new qualification date range

For example:

If the original response contained course A (1st Jan – 1st Feb) that belonged to Qual X (1st Jan – 1st Aug), the date ranges reported to StudyLink would have been 1st Jan - 1st Feb (from the course).

If another course B (1st Mar – 1st Apr) is added to Qual X, then an internal request/response cycle considers this new course. The logic would use the original reported date range (1st Jan – 1st Feb) to identify course A.

The parent qualification would be found, giving a qual date range of 1st Jan – 1st Aug. This new date range would then be used to find the relevant courses - which would include both Course A and B.

Appropriate values for the Total EFTS, the Total Fees, and Fees requested are consistent with the Qualifications that are being reported in the response as in the previous 2 steps.

When considering Concurrent Groups, for internal requests only, the Created Date of the original Response record will be used to determine the groups in effect, rather than the system date.