3 Managing Segregation of Duties
This chapter contains the following topics:
3.1 Understanding Segregation of Duties
The JD Edwards EnterpriseOne Financial Management and Compliance Console (FMCC) SOD enables executives to ensure organizational compliance for specific financial system settings. SOD helps protect the company against fraud by ensuring that any one user does not have access to applications that can be used to circumvent an approval process.
For example, you might not want the same user or role to have access to both the voucher entry and accounts payable check writing applications. SOD does this by comparing the SOD rules that you set up against the application security settings that you establish by user and role. If someone changes the security setting for a user or role that violates one of the SOD rules, the system sends an alert to the distribution list that is associated with that rule.
You might want to establish rules for duties which include entering and approving transactions. Inadequate SOD can lead to:
-
Misappropriation of assets.
-
Misstated financial reports.
-
Inaccurate financial documentation.
-
Improper use of funds.
-
Undetected modification of data.
SOD in JD Edwards EnterpriseOne FMCC alerts you to any violation of the SOD rules that you define. You define the rules using the FMD - SOD Rules Application program (P80D112).
The system creates an alert for each violation when you run the Process SOD Violations (R80D112) program. Advanced algorithms determine when violations to the rules occur.
To display alerts on the Fin Mgmt & Compliance Console form, you must subscribe to the alert in the Dashboard Management program (P80D301).
3.2 Understanding Application Security for Users and Roles
The system uses the data in the Security Workbench program (P00950) to determine the users and roles that have access to each JD Edwards EnterpriseOne program. You can set up application security for the role, the user, or both. You must consider many factors when you set up the security that is necessary to use SOD. You should ask these questions:
-
Is application security associated with the user, the role, or both?
-
What date is the user associated with the role?
-
Is the environment associated with the user, the role, or both?
-
How is the *PUBLIC record set up?
You can define security *PUBLIC for a super-user and *ALL for a super-application. You set up security for *ALL just as you would for any other application. You can grant or deny access to *ALL to a user, a role, and *PUBLIC. When a user attempts to execute an application, the system looks at security in this order:
| User/Role | Application |
|---|---|
| Specific User | Specific Application |
| Specific User | *ALL |
| Role | Specific Application |
| Role | *ALL |
| *PUBLIC | Specific Application |
| *PUBLIC | *ALL |
SOD uses all of these records in combination with each other to determine whether a rule was violated. If a user is assigned to one or more roles, the system uses application security for those roles in addition to the application security that you set up for the user to determine SOD violations.
3.2.1 SOD Violations
The system searches for three types of violations: user, role, and both.
If you have application security set up for the user and the user has access to one or more programs in each group of the SOD rule, then the system returns a violation for the user.
If application security is not set up by user but is established by role and the role has access to one or more programs in each group of the SOD rule, then the system returns a violation for the role.
If a user is assigned to one or more roles, the system uses the combination of application security to determine whether a violation occurs. For example, if the user has access to one program and is assigned to a role that has access to other programs, then the system considers all programs to which the user has access to determine when a violation occurs.
The system also verifies effective dates for users, roles, and relationships. The effective date for users and roles is the date the records are set up. The user and role relationship is effective on the date that you specify in the record.
3.2.2 Example of SOD Violations
This table shows the groups and objects set up in the APRULE process ID:
| Groups | Objects |
|---|---|
| Payments | P0413M (A/P Manual Payments)
R04570 (Create Payment Control Groups) P04571 (Automatic Payment Groups) |
| Vouchers | P0411 (A/P Standard Voucher Entry)
P0411SV (A/P Speed Voucher Entry) P0411S (Speed Status Change) R048101 (Recycle Recurring Vouchers) |
This table shows the setup for users, roles, and environments:
| User | User Application Security | Role | Role Application Security | Effective Date | User Environment | Role Environment |
|---|---|---|---|---|---|---|
| John | P0411 | APSTAFF | R04570
P0411 |
March 1 | N/A | DV811 |
| Mary | N/A | APMGR | P0411
P0411S R04570 P04571 |
June 1 | DV811 | N/A |
| Bill | P0411
P0413M |
APSUPER | P0411
P0411S R04570 P04571 |
July 1 | DV811 | DEP811 |
| Kevin | P0411
R04570 |
APSUPER | P0411
P0411S R04570 P04571 |
July 1 | N/A | DEP811 |
The APRULE process is active and effective on May 15. If you run the Process SOD Violations program (R80D112) on June 1, the system generates these SOD alerts:
| User | Role | SOD Violation | Explanation |
|---|---|---|---|
| John | APSTAFF | Role
User through role |
The role is in violation.
The user is in violation through the role. |
| Mary | APMGR | User through role | The user is in violation through the role. |
| Bill | APSUPER | User
Role |
Both the user and role are in violation, independent of each other. |
| Kevin | APSUPER | Role | The role is in violation.
The user is not assigned to an environment, and the role relationship is not in effect at the time you run the R80D112 program. |
3.3 Setting Up SOD Rules
This section provides an overview of SOD rules and discusses how to:
-
Review SOD rules.
-
Create and update SOD rules.
-
Create groups.
-
Copy SOD rules.
-
Delete SOD rules.
3.3.1 Understanding SOD Rules
SOD rules enable you to determine the characteristics of an alert, when the system sends an alert, and to whom the alert is sent. SOD rules are completely user-defined. You set up parent and child relationships to associate JD Edwards EnterpriseOne objects with groups and processes.
To create SOD rules, you use the P80D112 program. The P80D112 program uses a hierarchical structure to set up the rules that govern the SOD alerts. This diagram shows the hierarchical relationships:
For example, you can set up an Accounts Payable process that includes these groups:
-
Create vouchers
-
Enter payments
-
Post vouchers
You then attach the AP Standard Voucher Entry (P0411) and the A/P Speed Voucher Entry (P0411SV) programs to the Create Vouchers group.
Violations and risks occur when a user has access to multiple groups within a process. A rules algorithm determines which users cross groups and therefore should be shown as a possible risk. The R80D112 program uses the SOD rules and algorithm to determine when to generate alerts for SOD violations.
3.3.1.1 Copy
You can copy any process regardless of its status. If the process is inactive, the system creates the new copied record with an active status. When you copy a process, the system allows you to assign new values to the Process ID, Process Description, and Effective Date fields. However, you must edit the new process to assign different values in the Distribution List Org and Distribution List Parent fields; otherwise, the new process retains the values of the copied process.
3.3.1.2 Deactivate Versus Delete
You can deactivate a process that is no longer being used or is no longer valid. When you deactivate a process, the R80D112 program skips the rule record. The system identifies the process as inactive in the SOD rules tables, but does not remove any history created by alerts previously generated by the process.
You delete a process when you have entered it in error and do not want to retain an audit record. When you delete a process that has been utilized, the system removes all alerts records associated with the process which includes records in the SOD Rules (F80D112), SOD Process Master (F80D113), SOD Group Master (F80D114), SOD Alert Master (F80D135), SOD Alert Detail (F80D136), Alert Instance (F80D311), Alert Instance Tag (F80D311A), and Alert Instance Status (F80D315) tables. The system also removes the associated values in user-defined code (UDC) 00/AR and the subscription to the alert on the console.
3.3.2 Forms Used to Set Up Segregation of Duties Rules
| Form Name | FormID | Navigation | Usage |
|---|---|---|---|
| Work With Segregation of Duties Rules | W80D112E | Segregation of Duties (G80DSOD), SOD Rules Setup | Review SOD rules. |
| Add Process and Groups | W80D112H | Click Add New on the Work With Segregation of Duties Rules form.
Select a process on the Work With Segregation of Duties Rules form. |
Create and update SOD rules. |
| Add/Delete Objects | W80D112G | Select a group on the Edit Process and Groups form and click Edit. | Create groups. |
| View Groups and Objects | W80D112D | Click the Process ID link on the Work With Segregation of Duties Rules form. | View all the groups and objects related to a Process ID. |
| Copy 'Process' | W80D112I | Select a process on the Work With Segregation of Duties Rules form and click Copy. | Copy SOD rules. |
| Delete 'Process' | W80D112C | Select a process on the Work With Segregation of Duties Rules form and click Delete. | Delete SOD rules. |
3.3.3 Reviewing SOD Rules
Access the Work With Segregation of Duties Rules form.
Figure 3-2 Work With Segregation of Duties Rules form
Description of "Figure 3-2 Work With Segregation of Duties Rules form"
- Add New
-
Click to create new SOD rule processes, groups, and object relationships.
- Edit
-
Click to revise the selected process. You can revise only the description, effective date range, and the groups within the process.
The Edit button is not available for processes for which the system has generated SOD violation alerts.
- Copy
-
Click to copy the selected process.
The system displays the hierarchical structure with the process and associated groups so that you can confirm the copy and update information as necessary.
- Delete
-
Click to delete the selected SOD rule.
Note:
You must confirm the deletion of the process on the Delete Summary form. - Deactivate Process
-
Click this button to deactivate the selected process. When you deactivate a process, the system deactivates all groups and objects within the process.
You cannot reactivate a process after it is deactivated.
3.3.4 Creating and Updating SOD Rules
Access the Add Process and Groups form.
|
Note: You cannot revise processes for which the system has generated SOD violation alerts. |
- Process ID
-
Specify the identifier of the process.
- Process Description
-
Enter a description of the process.
- Effective From Date
-
Enter the starting date on which the process is to become active.
- Effective To Date
-
Enter the ending date on which the process is no longer active. The system does not deactivate the process on the ending date, but it no longer runs the process.
If you leave this field blank, the process is always effective.
- Distribution List Org
-
Enter a value from UDC 01/TS that identifies a type of organizational structure that has its own hierarchy in the JD Edwards EnterpriseOne Address Book system (for example, email).
When you create a parent/child relationship for the JD Edwards EnterpriseOne Accounts Receivable system, the structure type must be blank.
- Distribution List Parent
-
Enter the parent address book number associated with the distribution list that you selected.
Any value that you enter in this field updates the Address Organizational Structure Master table (F0150) for the blank structure type. This address number must exist in the Address Book Master table (F0101) for validation purposes. Examples of address book records that would have a parent number include:
-
Subsidiaries with parent companies.
-
Branches with a home office.
-
Job sites with a general contractor.
-
- Group ID
-
Specify the identifier for the group. The group ID should identify the associated group of objects. For example, Vouchers, Payments, Invoices, Receipts, and so forth.
- Group Description
-
Enter a description of the group.
- Edit
-
Click to revise the objects within the group.
If you click the Save button, the system enables the Edit button so that you can continue to enter objects for each group. After you enter objects for one group, the system returns you to the Edit Process and Groups form so that you can continue entering objects for additional groups.
3.3.5 Creating Groups
Access the Add/Delete Objects form.
|
Note: You can add or delete objects when creating a new group, or revising a group that has not generated any alerts. If the SOD rule has generated an alert, the system disables the Edit button on the Add Process and Groups form. |
- Object ID
-
Specify the JD Edwards EnterpriseOne interactive or batch program number.
3.3.6 Copying SOD Rules
Access the Copy 'Process' form.
- New Process ID
-
Enter the identifier for a new process. You must enter a value in this field.
- New Process Description
-
Enter a description for a new process.
- Effective From Date
-
Enter the starting effective date of the process.
- Effective To Date
-
Enter the ending effective date of the process. The system does not deactivate the process on the ending date, but no longer runs the process.
If you leave this field blank, the process is effective forever.
3.4 Generating SOD Alerts
This section discusses how to:
-
Set processing options for the Process SOD Violations program (R80D112).
-
Run the Process SOD Violations program.
-
Review the SOD report.
3.4.1 Setting Processing Options for the Process SOD Violations Program (R80D112)
Processing options enable you to specify the default processing for the R80D112 program.
3.4.1.1 Defaults
This processing option specifies the As of Date.
- As of Date
-
Specify the date that the system uses to determine SOD violations or risks.
If you leave this field blank, the system uses the current date.
3.4.1.2 Environments
These processing options specify the environments that the system uses to search for SOD violations.
- Environment 1, Environment 2, Environment 3, Environment 4, and Environment 5
-
Specify the environments in which the system retrieves the security setup for SOD violations. You must specify at least one environment for the system to check for violations.
Whether you associate the environments with the user or the role is also a factor in determining violations:
-
If you associate the user with the environment, the system ignores the environments setup for the roles to which you assign the user; the system uses only the user and environment record. The system does use the application security that is set up for the role even if you do not assign the role to an environment.
-
If you do not associate the user with the environment, the system retrieves the environment based on the role to which you assign the user.
A user cannot inherit access to an environment or an application from different roles. Either the user or role must be specifically assigned to one of the specified environments for the system to check for violations.
-
3.4.2 Running the Process SOD Violations Program
Enter BV in the Fast Path field, and then enter R80D112 in the Batch Application field.
The R80D112 program generates the alert messages for segregation of duties violations and displays a notification in the Dashboard program (P80D350), Alerts Instances program (P80D357), and on the report.
The system creates a link on the Fin Mgmt & Compliance Console form to enable you to review all alerts assigned to you. You can also access the Alert Instances program (P80D357) to review and respond to alerts.
The report displays all alerts that the system reviewed and added to the Alert Instance (F80D311), Alert Instance Tag (F80D311A), Alert Instance Status (F80D315), and SOD Alert Detail (F80D136) tables.
When you run the R80D112 program, the system:
-
Populates the F80D311 and F80D311A tables with records to show the data on the console.
Users must be set up in the email distribution list for the SOD rule to view the alert on the console.
-
Populates the F80D315 table with a status record of Open for each user in the email distribution list.
When you close alerts using the P80D357 program, the system creates a status record of Closed in the F80D315 table.
-
Populates the F80D136 table with detail records about the violation.
The R80D112 program uses the SOD rules and algorithm to determine when to generate alerts for SOD violations. The SOD algorithm uses two types of logic to determine whether a SOD violation occurred: group and conflict. Group logic determines that a user or role is a member of a group if they possess any of the permissions for any program within the group. Conflict logic determines that a SOD violation alert is generated if a user or role is a member of each group within a process.
The R80D112 program uses Application Security permissions only to search for SOD violations. You set up the permissions in the Security Workbench table (F00950) by role or user. The system considers access to any form or version of an application as equivalent to access to the entire application. You define the relationships between users and roles and effective dates in the Role/User Relationship table (F95921). The system does not support the nesting of roles within roles.
|
Note: The user running the R80D112 program must be authorized to view all necessary setup data for the SOD violations results to be accurate and valid. |
3.4.3 Reviewing the SOD Report
The SOD report displays violations by process ID and environment, and by user, role, or by user through assignment of the role. The system uses this information to create the report:
-
If a violation occurs for the role, the system does not display the user on the same line.
-
If a violation occurs for the user, the system does not display the role on the same line.
-
If two violations occur, one for the user and one for the role, the system displays the violations on two lines of the report.
-
If a violation occurs for the user through the role, the system displays the user and the role on the same line of the report.