Table of Contents
- Introduction
- Version
- The Payroll Cycle
- Opening/Closing Periods
- Producing the Inbound Interface File
- Interfaces Rollback
Introduction
This document sets out the processes related to the submission of expense claims to ESR. It includes the following topics:
- Opening and closing of periods
- Producing the Inbound Interface File
- Rollback of transactions
Version
This article has been updated with the changes contained in version 11.95 of the EASY software.
The Payroll Cycle
The following diagram shows the payroll cycle related to the processing of staff expenses, and we will look at each of these stages in more detail. This cycle does not prevent staff and managers from entering, submitting and authorising expense claims.
Opening/Closing Periods
The EASY Expenses System has been designed to allow expense claims to be submitted and approved up until the point that the Payroll Department initiates the production of the inbound interface file. The opening and closing of periods within the system is used to tag expense claims with the pay period in which they were submitted to ESR for payment.
Adding a Period
To add a period, you will need to log into the EASY System as a system administrator and then select Period link within the Admin menu. This is actually a shortcut method of accessing the periods that are within the ESR section of the Admin functions.
This will take you to the Periods page that will list the periods that have been created within the system.
To view the list of periods, you can click on the see all results link, or you can use the search field to find a specific period. The following shows the result for pay period in the tear 2016 .
To open the Period > Add screen, you click on the Add period button.
The following table explains the function of the fields on this screen in more detail.
| Field | Description |
|---|---|
Authority/Trust | The EASY System may contain multiple VPDs, and you will need to select the VPD that the period relates to. |
Period Type | This is period type used by ESR, e.g. Weekly, Calendar Monthly etc. Select the period type from the list. |
Tax Period | Enter the tax period applicable. Where the period is a single figure, this should be prefixed with a zero, e.g. 05. Once you have selected the period type, the system will check for any tax periods of this type that have been entered previously, and will prefill this field with the value of what is believed to be the next tax period. |
Fiscal Year | Enter the start year of the fiscal year. For example, for the tax year 2014/15 you would enter 2014. Normally the system will prefill this field once you have selected the period type. |
Period End Date | Enter the last day of the period. For example, you would enter 30th June 2014 for calendar monthly tax period 03 of fiscal year 2014/15. The system will normally prefill this field once you have selected the period type. |
ESR Cutoff | This field is not used and currently it is not required. |
Input End Date | While this field is not used directly by the Expenses System, the field is referenced when extracting expense claims to ESR and need to be supplied. For a period type of calendar month, you should enter the period end date of the preceding month, e.g. 31st May 2014 where the current month’s period end date is 30th June 2014. Again this field will be prefilled by the system. |
Pay Date | This field is not required by the Expenses System, and should be left blank. |
Financial Period | This field is not required by the Expenses System, and should be left blank. |
Close Input on Previous Period | By putting a tick in the box, the system will mark the previous period as having been closed and it will no longer be available in the list of period when producing the inbound interface file. |
After you have completed the screen, click on the Initialise button to save the details.
When you look at the list of periods you will see that the new period has been added and the previous period is no longer open.
Producing the Inbound Interface File
Before running the inbound interface process, you may wish to produce a test inbound interface file to do a pre-check to ensure that there are no errors that will prevent the interface file being produced and submitted to ESR.
Test Inbound Interface File
This stage is entirely optional, and you can skip this step if you prefer; particularly if you have a large volume of claims.
This procedure largely follows the same process as producing the live inbound interface file. The only difference is that the expense claims included in the file don’t get marked as having been extracted and the file does not get sent to ESR.
As the EASY System produces different interfaces for other areas of the system you will need to select the Expenses export from the Support > Interfaces > Export menu.
This will open the Expenses Interfaces screen where you set the criteria to be used by the expenses interface process.
Claim Date Cut Off
The following table explains the function of the fields on this screen in more detail.
| Field | Description |
|---|---|
| Period | Selecting the Period determines which employees’ expense claims that are included in the inbound interface file. For example, where you have weekly as well as monthly paid staff, by selecting a monthly period the expenses for monthly paid staff only will be included in the file. The period is also linked to a VPD, so be sure to select the correct VPD and period where there is more than one VPD sharing your EASY database. |
| Payroll | We recommend that you leave the Payroll field blank, as this will include all staff with the period type selected. You would only select a Payroll if you only want the expense claims relating to staff in that particular payroll to only be included in the file. |
| Limit by | This option operates in conjunction with the Limit to field below, and is used in exceptional circumstances by the Giltbyte Helpdesk Team. |
| Limit to | This option operates in conjunction with the Limit by field above, and is used in exceptional circumstances by the Giltbyte Helpdesk Team. |
| Claim Date Cut Off | The Claim Date Cut Off field allows you to exclude expense claims with a claim date after the date entered in this field. By leaving this field blank all expense claims that have been fully approved at the time the inbound interface file is initiated will be included in the file. |
| Authorisation Cutoff Date | The Authorisation Cutoff Date field enables you to exclude expense claims that were authorised after the date entered in this field. By leaving this field blank all expense claims that have been authorised at the time the inbound interface file is initiated will be included in the file. Please note that this only applies to organisations that use the two stage approval facility in EASY. |
| Data Acceptance Cutoff Date | The Data Acceptance Cutoff Date field enables you to exclude expense claims that were accepted (fully approved) after the date entered in this field. By leaving this field blank all expense claims that have been accepted (fully approved) at the time the inbound interface file is initiated will be included in the file. |
| Mark As Submitted to ESR | When producing a test interface file, you must ensure that the ‘Mark as submitted to ESR’ field does not contain a tick. For producing the live file it is essential that this field is ticked as this ensures that the transactions included in the file are tagged as having been sent to ESR, or extracted. |
| FTP File to ESR | When producing a test interface file, you must ensure that the ‘FTP File to ESR’ field does not contain a tick. For producing the live file it is essential that this field is ticked as this will ensure that EASY sends the file to ESR for processing and payment. |
Click on the Run Expenses Interface button to produce the test interface file. A dialogue window similar to the one below will pop up so you can tell the system when to run the job.
By clicking on the Confirm button the job will be queued to run as soon as possible.
When the job has been run the colour of the banner will change. The banner will be green if the job has run successfully, or red if it has encountered an error.
By clicking on the green banner, you will be taken to the Task Results page.
You can then click on the file link to view the contents of the file. To read the file contents, you will need an understanding of the inbound interface file lay out.
Where the inbound interface file has failed, the system will list the assignments and reason the transaction failed within the Errors section.
You will need to correct the errors before the inbound interface can be submitted to ESR.
Live Inbound Interface File
The steps that you follow to produce the inbound interface file for submission to ESR are the same as for test inbound interface file, except that on Expenses Interfaces screen you must ensure that the boxes next to the ‘Mark as submitted to ESR’ and ‘FTP file to ESR’ fields are ticked.
When you click on the Run Expenses Interface button and queue the task to run, the system will compile the inbound interface file and automatically transfer it to ESR.
ESR Workflow
After the file has been transferred to ESR, you will receive a notification advising that request has been received to run the file.
You will need to log into ESR and navigate to the Run this Request screen.
You will then need to set the parameters.
Once the parameters have been set, you will need to submit the request.
You can then monitor the progress of the request through the Requests screen.
Once ESR has completed the Request you can view the interface report that will show if any records have failed. Within the report the error message gives an indication why the transactions have failed. In the example below, the first line shows that the “element name is invalid and cannot be translated”. As a result of this all subsequent transactions for this employee were rejected with the error message “Record rejected because another record for this employee failed validation or import”.
Now we need to resolve the problem within EASY, in this case correct the element name, rollback the affected transactions so that another inbound interface file can be submitted to ESR.
Interfaces Rollback
Within EASY there is a facility to roll back transactions so that they may be corrected and resubmitted to ESR. In the worst case scenario, the whole inbound interface file may be rolled back.
The rollback facility can be access by clicking on the Rollback link within the Management > Interfaces > Export menu.
The Interfaces > Rollback page shows a list of the most recent files that imported from/exported to ESR.
To roll back the whole file, you would click on the Rollback All button. The rolling back of a whole file should be considered as a measure of last resort.
To roll back the transactions for a particular assignment, click on the Find Assignment button. Search for the assignment whose transactions are to be rolled back and click on the assignment link.
The claim items that were submitted to ESR in the inbound interface file will be displayed. Where all transactions for the assignment are to be rolled back, click on the tick box in the header to select all the rows and then select the Rollback Selected button. Otherwise, only select the claim items that are to be rolled back.
When rolling back an assignment’s expenses transactions you should bear in mind that the expense types selected in EASY are resolved into an ESR element, and ESR will be failing the transactions that consolidated to make up that element. So, it likely that the transactions that make up that element involves one or more expense types, and you need to ensure that claim items relating to those expense types are rolled back.
The other point to note is that where there are several entries for an assignment in an inbound interface file, ESR will also fail the entries that follow the offending entry for the assignment with the error message “Record rejected because another record for this employee failed validation or import”. So, it is possible that ESR will have processed the earlier entries for the assignment before encountering the record that failed. Do not automatically assume that all records submitted in the inbound interface file have failed.