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

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

We often refer to the pre-check process as ‘running a 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.


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.

You can opt to select a Payroll if you only want the expense claims relating to staff in that payroll to only be included in the file.  By leaving the Payroll field blank, all staff with the period type selected will be extracted.

The Authorisation Cutoff Date field enables you to exclude expense claims that were fully approved 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.

When producing a test interface file, you must ensure that the boxes next to the ‘Mark as submitted to ESR’ and ‘FTP file to ESR’ fields do not contain a tick.

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.