To access the data collection system you will need to register for the Student collection (C11051) on the HESA submit website. For assistance with registration please view the Registering for the system help page.
Stages of data submission:
The diagram below demonstrates the data submission process.
Browse your computer to locate the file you wish to submit, and upload the file to the data collection system. Click on the 'submission status' link to navigate back to the transaction history page to view the outcome of submission.
Insert-stage validation checks will now run.
Further details on the checks included in INSERT-stage validation can be found within the field details of the record descriptions.
In addition to schema and business rule checks, an Entry Profile (EP) check will also be carried out as part of INSERT-stage validation. This report lists any incoming instances submitted without Entry Profile data that do not link to instances returned in previous collections. If errors are found with the submitted entry profile data the file will fail validation. Click on this icon to review the errors triggered by the file. Make any necessary amendments to the data and resubmit the file to the system.
To pass insert-stage validation the file must not trigger any validation errors.
If the file fails validation the system will show the below status and reports. You should review errors (and warnings if any). Make any necessary corrections to the data and resubmit.
*Note: Corrections cannot be made online to the file submitted to the data collection system and instead must be made to the file held locally, and the file then resubmitted.
If the file passes INSERT-stage validation the system will show the status and reports below. You should review any validations warnings relating to the file to ensure that the submitted data is genuine or correcting and resubmitting the file where necessary.
You can also run insert-stage validation checks through the validation kit before submitting data to the submit site. The kit enables institutions to test their data locally against the INSERT-stage validation ahead of the main collection opening in the summer. Institutions are strongly encouraged to use the validation kit as part of their data preparations.
that you need to process and pass the INSERT-stage validation in order to meet
the requirements of the return deadline of 15 September 2011.
To proceed to commit-level validation a valid file needs to have been submitted and passed INSERT-stage validation checks. The data will then be classed as committable and the option to process TEST_COMMIT and COMMIT transactions will be made available in the ‘What can I do now?' box.
Click on ‘TEST_COMMIT this submission' in the ‘What can I do now?' section. The HESA data collection system assumes that all the submitted files that have passed validation represent the institution as a whole and as such, stacks up all files that have passed INSERT-stage validation and runs COMMIT level checks.
Check through the frequency counts displayed before clicking 'OK' to ensure that the data to be committed contains all expected records.
If the file fails TEST_COMMIT level checks the system will show the status and reports below. You should review the error report produced, make any necessary corrections to the file and resubmit it.
You will encounter this icon following COMMIT-stage validation. Click on this icon to review the errors triggered by the file. Make any necessary amendments to the data and resubmit the file to the system. To assist institutions with their amendments the exception report features the option to download the totality of records failing exception checks. Exception reports are retained for all commit transactions enabling you to assess variations in levels of exception errors and warnings between transactions.
If the file passes TEST_COMMIT it will generate the suite of commit reports (See Student report key for details). These reports should be reviewed to ensure that the submitted data is an accurate reflection of the institution's profile. Help on how to analyse the check documentation can be found in the C11051 Check Documentation Guide.
What is the difference between TEST_COMMIT and COMMIT? In terms of the validation processes run by the system there is no difference between these transactions. The only difference between the two transactions is that the reports generated from the TEST_COMMIT transaction are for institutional use only. The facility enables institutions to view the commit reports and assess submitted data for anomalies before processing a full COMMIT transaction to be scrutinised by HESA.
Following a successful TEST_COMMIT transaction institutions do not have to contact HESA to 'DECOMMIT' the return; changes can be made to the submission by inserting and/or deleting files in the normal way.
Where you need to make amendments to data you will need to delete the older version of the file. If files that previously passed validation and are subsequently replaced are not deleted they will be combined within the COMMIT transaction and cause the file to fail due to duplicate records. To delete a file select the 'delete' option in the 'What can I do now?' box. This will display a listing of all live passed files submitted to the system in chronological order. Select the file you wish to delete.
Why can't failed files be deleted?
Where a file fails INSERT-stage validation the records contained within it are not uploaded to the HESA database and so will not be counted as part of the return.
Once your file has passed TEST_COMMIT and you are content with the data contained within, you should process a COMMIT transaction. This transaction will then send a copy of the submission to the HESA Data Quality Assurance team for HESA to undertake analysis of the return in parallel with the institution conducting their own analysis.
The data collection system will provide a second version of the check documentation for every re-commit/test-commit processed by an institution. This version of the check documentation presents a colour shaded version of the Excel spreadsheet with variances being highlighted.
A passed commit transaction will lock the system to prevent the data from being amended, in order to allow the HESA Data Quality Assurance team to undertake analysis of the submission. To unlock the system you will need to request a DECOMMIT transaction from HESA. This will reverse the current commit and allow you to delete, resend and recommit data.
I need to amend my data, how do I get it decommitted?
You will need to contact Institutional Liaison either by emailing email@example.com or calling on 01242 211144 to request a decommit transaction.
Remember that you need to process and pass a COMMIT transaction in order to meet the requirements of the commit deadline of 22 September 2011. A passed test-commit will not satisfy the requirements of this deadline.
Once HESA has undertaken their analysis of the committed return data quality queries will be posted onto the Minerva DQ database. Record contacts, and any others users signed up to Minerva, will be notified by email when these queries are available to view. The Minerva user guide provides help on using the database.
A link to the sign-off form will automatically be emailed to the Head of the institution when data is set to CREDIBLE. The form should be completed and signed by the Head or Acting Head of the reporting institution and posted to HESA. This verification offers both the institutions and HESA assurances regarding onward use of the data. Sign-off completes the data collection process.