Title
HESA New Indvidualised Staff Return.

Purpose
The purpose of this report is to create a file to be sent to the HigherEducation Statistics Agency (HESA) for the New Individualised StaffReturn.

Integration
Data for this report is taken from HR Master Data, specifically infotypeHESA Master Data (0614) and HE Contract Data (0615).
Academic qualification data is taken from infotype AcademicQualification (0618).
Infotype Clinical Details (0617) is required for staff working onmedical duty.
Other infotypes used are Personal Data (0002), Basic Pay(0008) and Additional Personal Data (0077). Infotypes Actions
(0000) and Org.Assignment (0001) are used to determineemployee status and groupings.
Infotype HESA Submitted Data (0616), used for IndividualisedSatff Return is obsolete.

Prerequisites
Customising for the HESA return (see IMG) hasto be carried out. All references to tables, feature etc. are mentionedhere for reference only; all customising objects are in IMG.
Data for the employees has to be set up.
If you used SAP HESA ISR, ASR or NASR prior to HESA return year2003/2004 you should perform data migration to new HESA formats andcodes (for more information see documentation of the reportsRPUHESA01, RPUHESA02 andRPUHESA03).
If you choose to fill the new field 'Appointment ID' on infotype 'HEContract Data' atomatically, you should run the reportRPUHESA04. Otherwise, this field should be filledmanually to generate correct 'Contract Identifier' in the field CONTIDof the Contract table.

Mapping of fields

• Record type indicator (RECID) Generated in program; dependent on
year (yy - two last digits from year field): yy025 - NISR Person tablestandard record, yy026 - NISR contract table standard record and yy126 -NISR contract table minimum record for atypical staff.

• Institution identifier (INSTID) Taken from customising there is
only one ID per installation possible; check table T5GPBSH_INS holds thehigher education institutions' HESA codes; the table also holdsinformation where the institution is located (Scotland, Wales, other)

• Staff identifier (STAFFID) HESA Master infotype, including
checking of number; new numbers generated from number range HR_GB_HEID,using the fiscal year as the HESA year; old USR staff Ids are acceptedby the system; the format of USR is 0000xxxxxxxxx with x being a digit

Person Table


• Date of birth (BIRTHDTE) Field Date of birth (GBDAT) from
infotype Personal Data (0002), in format YYYYMMDD

• Gender (GENDER) field gender (GESCH) on infotype Personal Data
(0002), with a hard-coded mapping of 1, 2 -> M, F

• Nationality (NATION) Fields P0002-NATIO, NATI2, NATI3 are used
with mapping table T5GPBSH_NAT

• Ethnicity (ETHNIC) Field P0077-RACKY is mapped to the HESA code
using table T5GPBSH_ETH; HESA ethnicity codes are held in tableT5GPBSH_ETC

• Disabled (DISABLED) P0077-DISAB and infotype Challenge (0004)
field challenge group are considered, challenge group can be marked asto be returned as disabled in mapping table T5GPBSH_CHA; only values 1and 2 are returned, i.e. registration is not taken into account

• Date first appointed at current HEI (DATEFHEI) The last begin
date of continuous service derived from infotype Actions (0000) informat YYYYMMDD is returned. This field is filled for atypical staff.

• Previous employment (PREVEMP) HESA Master infotype; check table
for HESA code is T5GPBSH_PRV2. Default code used for atypical staff is'99' (Not known).

• Previous HEI (PREVHEI) HESA Master infotype; check table
T5GPBSH_INS holds the higher education institutions' HESA codes

• Highest qualification held (HQHELD) From Academic Qualifications
infotype (0618): checked against new level of qualifications tableT5GPBSH_QUD2;

• Academic discipline (ACCDIS1, ACCDIS2) From Academic
Qualifications infotype (0618). The Joint Academic Coding System (JACS)coding frame introduced in 2002/03 is used and provides for all subjectsto be coded according to a common, four-character subject code; thecheck table with HESA codes is T5GPBSH_ACD2

• Regulatory body (REGBODY) Clinical details infotype, field
'Registraiton type' is used with mapping table T5GPBSC_RTB; the checktable with HESA codes is T6GPBSC_RBD. Value '00' (Not currentlyregistered) is returned by the report for the staff who are classifiedas 'Clinical' but do not have a record of infotype 'Clinical details'(0617) valid on the return period.

• Ability to teach through the medium of Welsh (ABLWELSH) HESA
Master infotype (needed in Wales only) (field ABLWE)

• Date left HEI (DATELEFT) Derived from 'Actions' infotype in
format YYYYMMDD. This field is filled for atypical staff.

• Destination on leaving (LEDEST) HE Contract infotype, the last
valid contract (see field 32) will be used; codes are held in a newtable T5GPBSH_DES2. Default code used for atypical staff is '99' (Notknown).

• Active in 2001 Research Assessment Exercise (RESACT) HESA Master
infotype (field RESAC)

• Unit of Assessment (UOA) HESA Master Data infotype


• Total monies paid during this reporting year (TOTSAL) Calculation
of the current salary is based on infotypes 8, 14 and 15 only; onlycertain wage types are used; customising is as for the annual salarycalculation on infotype Basic Pay (0008); currency is British Pound

Contract table


• Campus identifier (CAMPID) Derived from new feature 08HCI (In:
Org.assignment, out: ID), displayed on HE Contract infotype (ifnecessary this field can be on the infotype and if filled will be usedinstead of the value from the feature; but at this stage it is expectedthat the campus identifier is in some direct way related to theorg.assignment)

• Contract identifier (CONTID) Constructed by concatenating
Personnel number and 'Appointment ID' assigned to the record of HEContract infotype at the start date of the contract.

• Terms of employment (TERMS) Derived from field contract type on
infotype HESA Contract-infotype; atypical contracts are returned with'3'.

• Mode of employment (MOEMP) Derived from infotype basic pay
(0008); part time: Capacity utilisation level < 100; if staff isatypical in field 'Terms of employment ', staff is also consideredatypical in this field. field contract type on infotype HESAContract-infotype is used to determine 'term-time' contracts.

• Academic employment function (ACEMPFUN) HE Contract infotype


• FTE during reporting year (CONFTE) Derived from infotype Basic
pay (0008), field Cap.utility level , pro-rated across the period ofactive employment within the year; if there is no infotype 0008 foratypical staff, salary is divided by a notional amount (determined fromcustomising).

• Teaching through the medium of Welsh (TCHWLH) HESA Master
infotype (needed in Wales only) (field TCHWL)

• Grade structure (GRADE) Derived from infotype Basic Pay (0008)
and mapped to the HESA code using feature 08HGR (payscalegrp/lvl/type/area-> code); HESA code is held in table T5GPBSH_GRA

• Senior management post holder (SMPH) HESA Master infotype (field
SENPH)

• Source of basic salary (SOBS) HE Contract infotype


• Proportion of basic salary charged against general income (PSCAG)
HE Contract infotype

• Secondary source of basic salary (SSOBS) HE Contract infotype


• Salary point (SALPOINT) Derived from infotype 0008: there is
feature 08HSP mapping payscale (level = TRFST) to salary point

• Basic salary at reference date (SALREF) Calculation of the
current salary is based on infotypes 8, 14 and 15 only; only certainwage types are used; customising is as for the annual salary calculationon infotype Basic Pay (0008); currency is British Pound

• NHS contracts (NHSCON) From infotype Clinical Details; fields
'A+B appointment', 'NHS Joint' and 'Honorary NHS type'. Value '0' (NotNHS contract) is returned by the report for the staff who areclassified as 'Clinical' but do not have a record of infotype 'Clinicaldetails' (0617) valid on the contract period.

• NHS contract grade (NHSCONGR) field 'Honorary NHS type' is used
with mapping table T5GPBSC_NHS. Value 'XX' (Not applicable) is returnedby the report for the staff who are classified as 'Clinical' but do nothave a record of infotype 'Clinical details' (0617) valid on thecontract period.

• Healthcare professional speciality (HSPEC) Clinical Details
infotype, field 'Clinical specialty'. Value 'XX' (Not applicable) isreturned by the report for the staff who are classified as 'Clinical'but do not have a record of infotype 'Clinical details' (0617) valid onthe contract period.

• HEI joint contracts (HEIJOINT) HESA Contract details infotype


• Primary cost centre (CCENTRE) Derived from Org.assignment:
infotype External Key (1038) subtype HEFC holds the HEFCE cost centre;if this is not filled, the HE Contract infotype is used;

• Activity codes (ACT1, ACT2, ACT3) HESA Contract details infotype


• Cost centres (CCENTRE1, CCENTRE2, CCENTRE3) HESA Contract
details infotype

• Proportions in cost centres (CCPROP1, CCPROP2, CCPROP3) HESA
Contract details infotype

Selection
Inclusion of an individual in the record will depend on the existence ofone or more contracts of employment between the institution and anindividual and/or the liability of the institution to pay Class 1National Insurance contributions for that individual.
However the range of data required about an individual and thecontract(s) that they hold will depend on the nature of those contractsand also the classification of the activity for which the contractexists.
The report will perform the following three processing steps:


• Generation


• Delete archive records


• Maintenance


• Extraction

The report will allow Generation and Extraction to be performed in testmode (without DB up-date) and in live mode (with DB update).
The step 'Delete archive records' should be used only if some recordswhere generated in HESA NISR archive tables by mistake (e.g. for anemployee who should not be returned to HESA). If you simply need tore-generate an employee's records, you do not need to delete the archiverecords beforehand. The report will automatically update the archivewith new records in 'Live' mode of Generation step.
In maintenance mode the report will not provide any checks for fieldsmanually modified by cus-tomers.
Extraction in the live mode should be run by the customers only when thedata has been sub-mitted to HESA, validated by HESA and must not bechange any further, as such a run will lock records of NISR (in controltable T5GPBSH_CONTROL) from any further change - manual as well asthrough report generation.
For those individuals with contracts of employment and/or for whom theinstitution is liable to pay Class 1 National Insurance contributionsbut whose relationship for all contracts held with the institutionduring the reporting period would be defined as 'atypical' there is arequirement to return only a minimum data set. The term 'atypical' isused to describe working arrangements that are not permanent, involvecomplex employment relationships and/or involve work away from thesupervision of the normal work provider.
For those individuals whose relationship with the institution, for oneor more of the contracts held during the reporting period, cannot bedefined as 'atypical' there is a requirement to return a wider range ofdata. For many staff, those who have contracts to undertake activitiesclassified in SOC groups 4-9, this additional requirement relates mainlyto grade and salary information and start and end dates of employmentand contracts.
Where individuals have contracts to undertake activities classified inSOC groups 1- 3 there is a requirement for an additional range of datafor example about qualifications and previous employment/destination onleaving information. This information is required for those who havecontracts in administrative and professional posts, for example inplanning, libraries and registraries, whose activities are likely to becoded in SOC groups 1, 2B and 3 - areas that mean that they are likelyto have careers within the HE sector that involve them moving betweeninstitutions. There is also a requirement for institutions to track theuse of staff identifiers when SOC 1, 2B and 3 staff move betweeninstitutions.
For all other staff with contracts where any of the activity code fields(24, 27, 30) are coded 2A, there is a requirement for a furtheradditional range of data. There is also a requirement for institutionsto track the use of staff identifiers when SOC 2A staff move betweeninstitutions.
Amongst the SOC 2A group of staff some information is only needed forHealth and Social Care professions, i.e. where any of the cost centresfields (25, 28, 31) are coded 1 to 9 or 29.
Finally, only in the case of those staff who hold NHS contracts arefield 19, NHS contract grade and field, 20 Healthcare professionalspecialty in the Contract Table additionally required.

Output
In generation mode, the program will generate records of HESA NISR basedon Master Data stored in a customer SAP system and display them in ALV.In live generation mode, the records are displayed in ALV and stored onthe database on personnel number basis for modification, extraction andfor customer use in 2 database tables:


• Person Table (PAPBSGB_HESA_P)


• Contract Table (PAPBSGB_HESA_C).

The data are generated based on categories of staff as specified in HESAspecification. Only information required by HESA for a category of staffis generated by the report for each personnel number, even if moreinformation is available in the system. Aggregation of the informationin Person table will be performed only at the extraction stage.
Validation of single person and contract table records will be performedat generation stage, while validation across different referencepersonnel numbers and across contract and person table will be performedat extraction stage.
In maintenance mode, all fields of the return tables will be availablefor maintenance, except Personnel number, return year and institutionID. There is no checks performed by the report on data manually changedby a user.
In the Extraction mode (and only in this mode), it is possible to selectoutput options either than ALV output, i.e. TemSe output and File Serveroutput. One file is generated for each of the return tables. The ALVoutput allows export to spreadsheet programs like MS Excel.
For submission to HESA you should run the program in extraction modefor all your employees in one run.
After the live extraction of the return for given return year, it willbe no longer possible to modify the Person and Contract table for thisreturn year neither manually, nor by report generation. This restrictionis put in place in order to prevent accidental corruption /overwrite ofthe return once it was submitted to HESA.
Report RPUHERG0 should be used to extract the resultsfrom TemSe file.
There is a comprehensive error log.
Some of the errors come up as warning in test mode. This is to allowother errors of those employees to show up during early testing. Thelong text of the warning/error states whether the problem is handleddifferently during test mode.
During test mode some errors come up as warnings to give an overview ofall problems rather than to stop processing of a personnel number withthe first minor error.
HESA Validation Checks
During "Generation", the HESA validation checks are performed andwarning messages are created for any checks that fail AND therecords have the error field set to 'X'.
These must be corrected in one of three ways.
1) Master Data correction and re-running the generation
2) Maintenance of generated records
3) Reporting the problem/validation code to SAP via an OSS message ifyou believe the validation check is incorrect or if there is no way forthe problem to be corrected manually.
During "Extraction", the HESA validation checks are performed anderror messages are created for any checks that fail AND therecords will not be included in the interface files to be submitted toHESA.

Activities
To submit HESA NISR, proceed in the following sequence of steps:


• 1.,,Test generation of the return.


• 2.,,Record verification, correction of the Master Data if necessary.


• 3.,,Live generation of the return (update of the database tables
PAPBSGB_HESA_P and PAPBSGB_HESA_C).

• 4.,,Maintenance of the generated records, if necessary.


• 5.,,Test extraction of the return for submission to HESA into ALV, TemSe
or application server files.

• 6.,,Live extraction of the return after it was validated by HESA (update
of the database table T5GPBSH_CONTROL).