The COINS Payroll and Human Resources Modules offer various levels of security beyond functional security set up during implementation. Security is defined within payroll and HR and can

Employee Security in OA uses Patterns, Can-Do Lists and Comma-Separated lists to specify the values included or excluded from view.

The fields in Payroll Employee Security allow you to enter a list of values that will be used to determine if a user has access to an employee. This list is called a Can-Do list. To use Employee Security, you must first understand how to create a Can-Do List.

A Can-Do list can be comprised of wildcards, multiple values (called a comma-separated list), and exceptions. Below is a list of characters that can be used to build a CAN-DO list anywhere in OA.

Figure 1 – Allowable Values for Can-Do lists in OA

Employee Security prevents users accessing the records in the employee file, from seeing an employee or employees in reports as well as other areas of payroll. Employee Security must be setup and maintained by Payroll Company.

A user has access to all employees and related data unless security is in use.

Employee Security contains a Can-Do list of values that is applied to a user or user group to determine which groups or types of employees a user will have access to. Employee Security is maintained in Payroll > Company Setup > Security and can be based upon Employee Department, Employee Location, or a field within one of the four available analysis fields used in Employee maintenance. The security basis for Employee Security is determined by setting Global Payroll parameter ‘SECURITY’.

Employee Security basis, by default, is Employee Department. If you change the value of the parameter, you must run Regenerate Employee Security from the Payroll > Company Setup > Security Menu for the changes to take effect.

Figure 2 – Global Parameter – SECURITY - Base Security on Department

Employee Security is the ability to access or view employee data in Employee Maintenance and on reports and inquiries. The Security List and Code fields in Payroll > Company Setup > Security are used to configure security by user or user group.

Figure 3 – Employee Security – Using Security List and Code fields

The Security List field is populated with a Can-Do statement, as described above. The contents in the list corresponds to the field defined in the PR/SECURITY parameter and found in the Employee File. In all cases, the first character in a Security List is always Pay Frequency. If Security is based on Department (See Figure 2), then the Can-Do list you enter will apply to the Pay Frequency Value followed by the Department.

Pay Frequency values are 0-Weekly, 1-Monthly, 2-Two-Weekly, 3-Four-Weekly, 4-Twice-Monthly.

The Code in Employee Security can contain a list of Employee Numbers that a person has access to (or does not have access to) in addition to those allowed by the Security List.

Example 1 - Access to Weekly Employees Only

Figure 4 is an example of a security list for user CARLUC. In this example, CARLUC has access to ALL employees whose pay frequency is WEEKLY (0*) for any Department. If employees are on file for any other frequency, this user will not be able to see their records.

Figure 4 – Employee Security Example 1

Example 2 - Access to all Weekly Employee EXCEPT for one other Employee

Figure 5 below, expands upon Example 1. User CARLUC has access to ALL weekly employees except employee with Employee Number LUCOLI.

Figure 5 - Employee Security Example 2

Example 3 - Restrict Access based on Employee Pay Frequency and Department

In this example, PR/SECURITY is configured to use the Employee Department (See Figure 2 for Global Parameter SECURITY). Therefore, the department codes are in the security query for users and/or user groups. Figure 6 is a list of employee departments.

Figure 6 – Department List

Figure 7 below, depicts a security list that will limit a user’s access to only Weekly Employees in the Mechanical Department, which is any department code that begins with number 3.

“0” in the Security List is presented as the first character and represents the pay frequency. In this case, “WEEKLY employees only” are included. The remaining characters in the string “3*”, which follows the employee pay frequency, represents “Any Department that begins with 3”.

Figure 7 – Security List for Weekly Employees in Mechanical Department except LUCOLI

Example 4 - Access to all Frequencies for Mechanical Department

Figure 8 is a security list where the ‘.’ represents ALL pay frequencies and is followed by ‘3*’ which represents “Any Department that begins with 3”. The can-do statement “.3*” means any employee in Departments that begin with 3 for all pay frequencies.

Figure 8 - Security List for any employees in Mechanical Department except LUCOLI.

Example 5 - Access to All Employees except those in Department 100 and LUCOLI

Figure 9 is an example of a security list where we will EXCLUDE certain groups of employees. In this example, an Exclamation Mark is used prior to the first character in the security list and means to EXCLUDE everything that follows up to first comma.

Figure 9 – Security List to include all employees except those in a particular department

2. Go to PR > Company Setup > Company Configuration and click the Employee Analysis Sets tab. Set the 4th analysis set (as defined in PR > Global Setup >Parameters) to SECURITY CONFIGURATION.

A single Analysis Set is used for all pay frequencies when processing US Payroll.

Go to Analysis Sets. Select the Type named Security Level. Click Add (+).

Use the Code field to add codes representing Security Levels and Groups. The Code field is an 8 character field. For the first character, enter the Security Level to be used in COINS US (Levels 1-7). For the remaining 7 characters, enter the Security Type to be used in COINS US.

The analysis codes listed below are only examples demonstrating how they may be structured. You may wish to set up your analysis code structure differently.

Examples:

3. Go to Employee Security to invoke security for a user, such as a Payroll Clerk. You may set the Employee Security as shown below. If there are many field locations (such as hou, FLO, etc.), you may request to be shown all Level 1 Field employees, except for those in Houston, and exclude all Level 4 employees.

Notes on adding a Security List

An additional character is used as a prefix when adding a security list to Employee Security. The prefix is the Pay Interval of the employees of the company. The prefix is defined as follows:

0 = WEEKLY

1 = MONTHLY

2 = 2 WEEKLY

3 = 4 WEEKLY

Below is the pattern '!01FHOU,01F*,!*4*' for user shidun. It is interpreted as follows:

You may want to avoid mixing alpha and numeric values when defining a section within a pattern. In this example, the area (represented as HOU, FLO, SAN, ADM) uses alpha values only, thereby eliminating the possibility that the pattern '!*4*' will match anything other than Level 4 employees.

Payroll Employee Security can be extended to certain Job Status Reports and Inquiries. Payroll Global Parameter JCSECUSER contains the list of users for whom payroll security will extend to Job Status. The default value of this parameter is ‘*’ or all users. If a user cannot see an employee in payroll, then the employee identifier, such as name or employee number, will be replaced with the phrase “Payroll Labor” when employee specific data is displayed.

Figure 10 – Extend Employee to Job Status

While payroll Employee Security prevents a user from seeing an employee anywhere in payroll and in certain areas of job status, Timesheet Security and Timesheet Rate Security is to control access to timecards and to restrict the view of rates on timecards and certain unposted payroll reports.

Timesheet Security will allow a user to enter a timesheet for a person that they do not have access to or prevents timesheet entry to a person they can see. Timesheet Rate Security suppresses rate information for persons that a user can enter time for.

COINS Enhancement document OA_CE-PR027 describes the process for using Timesheet and Timesheet Rate Security.

To begin using Timesheet and Timesheet Rate Security, payroll Parameter TSSECURE must be set to yes as shown in Figure 8.

Figure 8 – TSSECURE Parameter

Users will define the security list or codes that will be used for both Timesheets and Timesheet Rates in Lookup Codes. Use the data selector at the bottom of the page to select Timesheet or Timesheet Rate Security List.

Figure 9 – Lookup Codes for Timesheet Security Types

Figure 10 – Lookup Codes for Timesheet Rate Security

Once PR/TSSECURE parameter is set to yes and Lookup Codes have been defined, you will populate the Employee File with the Timesheet & Timesheet Rate Security codes for each employee.

Figure 11 – Employee Maintenance

In Employee Security, enter the codes that a user does or does not have access to for Timesheet Entry and for Timesheet Rates.

Figure 12 – Employee Security for Timesheet and Timesheet Rate Security

In Figure 11, employee CARSTO was assigned Timesheet Group CORP. In Figure 12, user carluc was restricted from entering payroll for any employees in the Timesheet Group CORP. The user gets a hard stop when attempting to enter or see timecards for the employee.

Figure 13 – Hard Stop due to Timesheet Security.

If an employee has access to enter timesheets for only certain groups (lookup codes) enter the excluded codes and then enter all others. The setup is the same for Timesheet Rate Security.

If the user has access to enter payroll for an employee but not see rates, the rates are suppressed in all Timesheet Entry functions, and the Timecard Report only. Other reports, inquiries and functions are NOT included in security. Use functional security to restrict users from other reports and inquiries as needed.

Figure 14 – Timesheet Entry with Timesheet Rate Security in Use.

Figure 15 – Timecard Report with Timesheet Rate Security in Use.

Similar to Timesheet and Timesheet Rate Security, it may be necessary for users to have access to employees, but not see salary related information. This security setting is configured in payroll but shared with both the PR Employee File and the HR Personnel File but not Job Status. You must use PR Employee Security to extend payroll security to job status.

Salary Security is based on the same security parameter as Employee Security. In Figure 16, user carluc does not have access to any employees in Department 100 nor does the user have access to employee LUCOLI; in addition, the user cannot see salary information for employees in any department in any pay frequency with begins with 3. To define salary security, !.3* is included in the Salary Security List.

Figure 16 – Employee Security for Salary Security

Figure 17 – Employee Earnings Category File with Salary Security in use.

Figure 18 – HR Salary History with Salary Security in use.

The ability to run certain Reports will be restricted if salary security is in use.

Figure 19 – Tax Summary Report Selection Criteria

Employee Security in Payroll is NOT shared with Human Resources. Personnel Security must be maintained separately. Users have access to all Personnel Records unless HR Personnel Security is invoked.

Since HR Personnel Workbench is global, you can define HR Personnel Security to automatically recognize company security. HR Parameter COSECURE should be set to Y to restrict a user’s access to Personnel included the user’s list of companies in User Maintenance.

Figure 20 – HR Parameter COSECURE

Personnel Security uses security queries rather than Can-Do Lists. The Security Query may include any field or fields in the personnel table (pp_organisation) and is therefore very flexible. However, you may find it necessary to have consulting assistance when invoking HR Parameter security.

Example

Within this topic, under Employee Security, we described setting Employee Security by Payroll Department. Access was limited for user CARLUC to only employee’s whose Department began with 3 or anyone in the Mechanical Divisions. In addition, user CARLUC will not have access to employee LUCOLI.

Figure 21 – Payroll Departments (repeated from Employee Security in Figure 4).

The Security Query to use in HR Personnel Security would be

Figure 22 – Security Query that mirrors Employee Security

Often, users will be limited to the employees they supervise. In the example below, the common security query could be applied to each user. The query gives users access to themselves and their direct reports. The text within curly braces will be replaced with the unique sequence number of the current user's HR record, so this requires the user to be linked to a personnel record.

The Can-Do statement will look at the Internal Sequence number of each personnel record, its supervisor and its manager to determine if it matches the user's internal sequence number. If there is a match, the user will be able to access the record.

Example where 5 is the internal sequence number of the user: can-do("5",ppo_mgr) or can-do("5",ppo_superid)

Figure 23 – Security Query by manager or supervisor

The personnel table is visible in CRM. Several MK parameters are to restrict user views of personnel data in CRM such as EXCDENTITY and NOPERSEC. Consult with your CRM COINS Team for more details.

Functions included in Employee Security

GENERAL

INPUT/PROCESSING

REPORTS

Employees are omitted from the following reports:

Employees are included in the following reports

Payroll Transactions in Job Status (Refer to OA_CE-PR028 for more details)

Job Status Transactions Key and Composite Description are masked in the following reports and inquiries:

Job Status Transactions are omitted from the following reports:

Functions included in Salary Security (WIP)

(Refer to OA_CE-PR084 for more information)

INPUT/PROCESSING

Salary Masked

Employees Omitted

Restricted from Running Report

Functions included in Timesheet and Timesheet Rate Security

(Refer to OA_CE-PR027 for more information)

INPUT

UNPOSTED REPORTS & INQUIRIES

*If Timesheet Rate Security is in use, then rates are suppressed for all employees included on the report.

Timesheet and Timesheet Rate Security ONLY applies to the functions listed above. It is imperative that Functional Security is carefully reviewed to prevent access to Rate information for those users who are restricted.