Understanding the HRMS System

There are three PeopleSoft information systems in use at JMU: Finance, Student Administration (SA) and Human Resources (HRMS).

This documentation references the HRMS system and the reporting tools made available to users: specifically PeopleSoft query and BI publisher reports. Reporting tools are used to extract data from the HRMS system in ad hoc yet predefined ways.

While several offices have access to write queries, the Manager of Reporting creates and maintains hundreds of reporting objects for various offices. Use this document as the primary source for these reporting objects. For additional information related to extracting data out of your HRMS system, contact:

Pete DeSmit

phone: 8-3605
Table of Contents

Logging into the HRMS System to run reports

Tips/rules which apply to all query objects

Introduction to reporting in your HRMS System

Electronic Personnel Acquisition Request (ePar)

JMU Applications

Facilities Management

Working with scheduled queries

Running a BI PUBLISHER report with bursting the first time

Level 1 create query access

Level 2 create query access

Reporting Guidelines when a member of IS performs research/work.

Troubleshooting queries

Advanced query techniques

Logging into the HRMS System to run reports

  • Log into the HRMS system by following this URL:
  • Log in using your userid and password. Navigate as follows to begin using the queries: Reporting Tools, Query Viewer.
  • Navigate as follows to begin using BI publisher reports: Reporting Tools, BI publisher. BI publisher reports can be viewed or scheduled, follow the appropriate path.

Tips/rules which apply to all query objects

  • To search for a prompted value (if there is a magnifying glass icon to the right of a field), place your cursor in the field and press ALT-5 TWICE. This will allow you to search by various values.
  • If prompted for the institution, always use a value of JMDSN.
  • Once you’ve entered prompted values, press the View Results button. When the results appear, you can send the results to an Excel spreadsheet, or CSV text file by following the appropriate hyperlink. Once your results are in Excel, you may sort, subtotal, save the results using various formats etc.
  • If a query has fewer prompts than you need (for example, you need to obtain data for 7 departments and the query only allows four) you may run the query multiple times and combine the results in Excel using cut/paste. If this activity is performed on a regular basis, contact the manager of reporting to request a customized query.
  • Dates can be entered in several formats; all of the following are acceptable formats for November 7, 2014: 11/07/2014 OR 11072014 OR 110714
  • If prompts include the word OR in their description, unless otherwise noted, it means you should enter data into one or the other prompt, but not both.
  • Queries have the results sorted in a specific order, which varies by query. If you desire results in a different order, send the results to Excel and use the sorting features available within Excel.
  • Queries contain data which need to be handled in accordance with university policies and procedures, including (but not limited to) FERPA.
  • The Family Educational Rights and Privacy Act of 1974, as amended (also sometimes referred to as the Buckley Amendment), is a federal law regarding the privacy of student records and the obligations of the institution, primarily regarding the release of information from the records and the access provided to these records. Generally the law provides that, with some exceptions, no information, applications, forms, letters, records, transcripts, etc. may be released, whether orally or in writing, without prior written consent, dated and signed by the student, specifying the records to be released, the reasons for release and the person to whom the records are to be released.
  • As a JMU employee, you are bound by various policies and procedures, one of which is data stewardship. The University's policy on data stewardship can be found here:
  • If a query is described as returning aggregate (aka summary) results, it means there will be no employee identifiable data returned. Aggregate query results are usually defined by a range of dates, actions, departments or other fields which will be presented as prompt values when the query is run.
  • As of date prompt. One of the primary records in your HRMS system is named JOB. It contains a key field known as an effective date. An effective dated record allows the system (and users running reports) to “turn the calendar” either forward or backwards. Doing so will allow the data returned by the report to be “as of” the date entered by the user at run time. When a report includes such a prompted field, entering the as of date is required. You may choose any valid date, and the results will be returned as of the date you entered. Want to know which employees were in your department as of 1/1/2000? Run the appropriate query, enter the date 1/1/2000 in the as of date prompt, and the results will be returned. Although used less frequently, you may also enter a future date. Payroll, for example, future dates PAR data for employees. Adjunct faculty have their termination date entered by payroll at the same time as their hire date. The termination row is future dated, and such, will not become effective until that future date arrives. Returning future dated results does not differ from using any other valid date. Simply key in the future date, and the report results will reflect this value.

Introduction to reporting in your HRMS System

One could describe your HRMS system as robust, meaning it has a lot of features. One of the side affects of such a robust system is the challenge to get meaningful/useful data out in an easy (very relative term, like user friendly) fashion. Two of the general purpose tools which come bundled in all PeopleSoft applications are the PeopleSoft Query and BI publisher reporting tools. All of the data in the HRMS system is stored in objects referred to as “records”, which can be thought of as a filing cabinet with lots of folders of information. In your HRMS system, there are literally thousands (75,687 as of the last count) of these records where data is stored in fields 687,275 of them). Using the query and BI publisher reporting tools, we’ve predefined some of the more common questions asked of the data and stored them in query and BI publisherdefinitions.

I am always eager to find/develop new ways to make JMU employees lives easier as it relates to the HRMS data. Before embarking on a labor intensive task related to HRMS data, why not drop me an email () or give me a call (8-3605) as I might just be able to make your data analysis chore a lot easier!

Electronic Personnel Acquisition Request (ePar)

Queries whose name begins with jepar. Primary contact is Jason McClain . These queries were developed for users with access to the Gideon Taylor developed Electronic Personnel Acquisition Request system (epar). All of the aggregate queries contain a date range labeled “From EPAR origin date” and “To EPAR origin date”. Both are required fields and refer to the date of the origin of the epar form. Of special note; the jepar01-08 queries, unless otherwise specified, return data for ALL departments and account codes, NOT just the epar forms for the departments for which the individual user running the query has been granted access. For the queries which return employee identifiable data, the data returned is based upon the 6 digit department id numbers to which you have been granted access. IF an employee is missing from the results, it may be because you have not been granted access to the underlying 6 digit deptid. You may run the query named jepar11a to determine which departments you have access to. Contact the Information Systems security team at to determine your current access. Section last updated 10/3/2016.

  1. Jepar01: Epar counts by status. Returns aggregate data based upon a prompted for epar origin date range. In this context, status is defined as the epar form status values.
  1. Jepar02: Epar counts by div/status. Returns aggregate data based upon a prompted for epar origin date range. In this context, status is defined as the epar form status values as well as the division to which the underlying 6 digit department id belongs as defined within the HRMS system. The “other” column includes all epar form data for divisions other than AA (Academic Affairs), SA (Student Affairs), UA (University Advancement), Presidents (the office of the President) and A&F (Administration and Finance).
  1. Jepar03: Epar counts by deptid/status. Returns aggregate data based upon a prompted for epar origin date range. Data is returned for all divisions and 6 digit department id’s (which are also the default sort order). You may send the results to excel and ignore the rows of data not applicable to your division/departments.
  1. Jepar04: Epar counts by deptid/condition. Returns aggregate data based upon a prompted for epar origin date range. Data is returned for all divisions and 6 digit department id’s (which are also the default sort order). You may send the results to excel and ignore the rows of data not applicable to your division/departments. In this context, the “condition” field refers to the type of form used. Values such as student, graduate student, non-student, etc.
  1. Jepar05: epar avg open to close days. Returns aggregate data based upon a prompted for epar origin date range. Data is returned for all 6 digit department id’s (which is also the default sort order). In this context, the “Avg days to process P to E” field refers to the number of calendar days it took (on average) for all of the epars for a particular department to reach the fully executed (status=E) from the initiated (status=P) status.
  1. Jepar06: epar avg by division. Similar to jepar05, but aggregated by the division of the underlying child department.
  1. Jepar07: Avg wait times; SWEC, HR Payroll. Returns aggregate data based upon a prompted for epar origin date range. Data is returned based upon the average number of hours each epar was waiting in each of the three primary areas of SWEC, HR and Payroll. These areas were chosen due to the predominate routing of epars thru these three offices across campus.
  1. Jepar08: Avg wait times; by role. Returns aggregate data based upon a prompted for epar origin date range. Data is returned based upon the average number of hours each epar was waiting in each role area.
  1. Jepar08a: Avg wait times; by status. Returns aggregate data based upon a prompted for epar origin date range. Data is returned based upon the average number of hours each epar was waiting in each of the different form action values.
  1. Jepar09: ePAR hire form data. Returns detail data for the employees to which you have been granted access based upon their JOB 6 digit deptid. Prompts for a date range, and three optional (can be left blank which means the value will not be used for selecting the data) prompts. Acct code, deptid and whether or not you desire those employees whose account codes are considered salaried ('112800','112130','112140','112160') included in the results. The query contains 29 employee identifiable fields. An employee is only returned IF they had an epar hire form action of HIR (hire), REH (rehire) or XFR (transfer to/from another department). If you desire additional fields for your employees, contact Jason McClain in the office of the provost of academic affairs. The default sort for the results is by the employee id#, you may send the results to excel to perform additional selection and sorts.
  1. Jepar09a: ePAR hire form data w/ACA hrs. Returns the same 29 fields as jepar09 with three additional fields. Start date, end date and projected hours. These fields are specific to the Affordable Care Act (ACA) data keyed into the par form. The query will only return data for your employees who have had ACA hours keyed into their epar form.
  1. Jepar09b: ePAR hire form: future dates. Contains the exact same prompts as jepar09. As of 5/7/2015, there is an anomaly for a very specific population of employees who are hired. IF the employee is being hired for the first time ever, AND you are keying the epar in the future, that employees data will NOT be returned by the jepar09 or jepar09a query. We are researching a more permanent solution, but have no date at this time if/when it may be fixed. So, IF you run jepar09 and are missing some records which you know you keyed, you are encouraged to run jepar09b using a date range which includes the future dated hire date. ALL of the records returned by jepar09 should also be returned by jepar09b, as well as the first time future dated employees as just described.
  1. Jepar10: ePAR Empl Verify Form. The results of this query are meant to be run as a BIP report. Navigation to that report is as follows: Reporting tools, BI Publisher, Query Report Viewer. You may also run this underlying query which will return the underlying data which is used when the BIP report is run. In addition to the same five prompts as those contained in jepar09, this query/report can be run for a single emplid. Use this method if you desire to print a single employee verification report. Each employee selected by the BIP report will yield a single page in the final results with a page break by the emplid#.
  1. Jepar11: List of employees by dept. Prompts for an as of date and an optional 6 digit deptid. Returns 17 fields (again, contact Jason McClain if you desire additional fields) for all of the employees to which you have been granted access.
  1. Jepar11a: List of deptids you can access. Prompts for an as of date. Returns aggregate data of the number of employees with the listed 6 digit deptid you have been granted access to by IS Security.
  1. Jepar11b: List of account codes. Contains no prompts, returns a list of valid account codes whose values you may need to run other jepar queries.
  1. Jepar11c: Active departments. Contains no prompts, returns a list of active 6 digit department id numbers (aka org codes) whose values you may need to run other jepar queries.
  1. Jepar12: Avg wait; by role your deptids. Is similar to jepar08, but this version only returns data for the epars of those employees who you have been granted access to by means of their 6 digit department id numbers. Returns aggregate data based upon a prompted for epar origin date range.
  1. Jepar13: Avg wait; by sts your deptids. Is similar to jepar08a, but this version only returns data for the epars of those employees who you have been granted access to by means of their 6 digit department id numbers. Returns aggregate data based upon a prompted for epar origin date range.
  1. Jepar14: JOB changes. This query is built over a primary HRMS record named JOB which contains a row of data for each employee and the various actions (and actions reasons) which affect their employment activities. Although each and every ePAR task which you key for any of your employees can be returned by this query, the primary purpose of this query is not necessarily tied to ePAR activity. You must provide a date range related to when the JOB changes took place. The other three prompts are all optional. BE VERY CAREFUL if leaving any/all of the last three prompts blank, as the number of rows of data returned by the query COULD be numbered in the thousands depending upon the number of departments you can access. The third prompt if for a single action code, use the magnifying glass to look up the values if you are unfamiliar with them. Likewise, the last two prompts (emplid and deptid) are optional. ePAR data is keyed into at least three records based upon the actions. If applicable, the corresponding ePAR form ID value is returned with the row of employee data. If there are no values in any of the three ePAR form ID fields, it means the row of data was not keyed into the ePAR system.
  2. Jepar15: Contract end date stdn workers. Contains no prompts. Returns active student wage workers (those whose account code begins with 114) and their future termination row of data (aka contract end date). When you key an epar with a contract end date for a student wage employee, it is keyed into the HRMS system as a future dated termination row of data. The field returned in this query, labeled contract end date, will be one day AFTER the actual contract end date. Use results of this query to determine if you desire to extend a student wage workers contract by entering the appropriate epar form. IF the contract is allowed to expire, you must then submit a brand new epar to rehire that same student.
  3. Jepar16: Position history by deptid. Prompts for a single 6 digit department id and an optional 8 digit position number. Returns data related to everything which has ever occurred on the given position sorted in descending order by the action date. Returns a list of employees who have ever been assigned to the given position number and their CURRENT employee status.

JMU Applications

This section contains a list of reporting objects whose path from the main menu in the HRMS system was originally JMU Applications. Rather than have separate sections, all such reporting and data analysis objects can be found in this section. These reports were originally written using a reporting tool called Crystal reports. Crystal reports are no longer supported in future PeopleTools releases, so the reports were all rewritten using BI Publisher. IF the path to a report includes BI Publisher (BIP), you may also desire to run the PeopleSoft query which is used as the data source to return the raw data to multiple file formats such as MS Excel. All BIP reports (unless otherwise noted) use PeopleSoft query as their data source whose query name is the same as the BIP report name. Section last updated 10/19/2017.