Segregation of duties (SoD) is an administrative control used by organizations when more than one person is required to complete a task in a business process. The aim of SoD is to prevent fraud, sabotage, theft, misuse of information, and other security aspects. You separate Procure to Pay activities such as creating suppliers, processing invoices, and payments, through SoD.

 In addition, you determine how to restrict data access to selected lines of business transactions for certain P2P users. The separation of key processes and data access security helps you mitigate risk of fraud and errors. 

In Oracle Cloud ERP, the data access to Procure to Pay (P2P) transactions is defined through user privileges and a security context. 

Data Access Requirements 

You assign a user one or more privileges through a custom role. The privileges roll up to duty roles, and you can create custom roles to ensure only the privileges and duty roles a user needs are assigned.  

An example of a privilege is Submit Payables Invoice Register.

A duty role represents a logical collection of privileges that grant access to tasks that a person performs as part of their job. For example, Payables Invoice Processing. Only duty roles hold explicit entitlement to the data such as work areas, task flows, application pages, dashboards, reports, and menu items.

Security context controls the data access. You can assign one or more business units for a person to access and process P2P data.

A business unit is an Oracle Cloud enterprise structure that administers and secures subledger transactions such as invoices and payments. Business units can contain one or more business functions such as Requisitioning, Payables Invoicing, and Payables Payments. Business units should reflect stable real-world departments and not short-lived entities such as projects. 

When you secure data access for a person to certain business units, it could be due to a number of reasons:

  • Regulatory needs
    • For example, the US government dictates that only US citizens can access information about government projects.
  • Ease of use
    • For example, only transactions in a certain geographic region relevant to Payables Shared Services personnel are presented to them. 
  • Minimum disclosure
    • For example, exposing only those transactions that an employee needs for their job and no more.

Carefully review and design your enterprise structure including business units early on in your project. Gain insight into Oracle Cloud ERP Enterprise Structures via My Oracle Support article Cloud ERP Enterprise Structures White Paper (Doc ID 2415848.1).

Assign Users with Appropriate Privileges

To address your SoD needs and minimize Oracle subscription impact, our recommendation is that you:

  • analyze P2P data access security requirements of your P2P users in your enterprise 
  • identify the predefined duty roles and privileges in Oracle Fusion Applications that best address your data access requirements
  • create custom roles and assign only relevant duty roles and privileges as appropriate to your different types of P2P users
  • copy a predefined role and remove unwanted privileges, then save as a custom role
  • de-provision a role when it is no longer needed
  • check the release readiness documents for your product area to know if there are any updates to access requirements. If you find changes that are relevant, incorporate the same changes for the relevant privileges. This will remain an ongoing maintenance activity.

 
Illustration of Data Access Configuration

The diagram below illustrates an example of an employee assigned a custom Accounts Payable Specialist job role where some privileges relating to budgetary control were removed. The custom job role includes only privileges for the user to view supplier profiles and create supplier invoices. The user can, in this example, only create invoices for two business units. You configure the security context in the Manage Data Access for Users setup UI in Oracle Cloud ERP.
 

Image shows four columns: User: John Smith Job / Abstract Role: Accounts Payable Specialist, Employee Duty Role: Payables Invoice Creation, Supplier Invoice Profile Privileges: Create Payables Invoice, Import Payables Invoice, View Supplier Below the four columns and linked to User and Privileges is a box named Data Access through Security Context Two lines from that box extends out to two boxes for two business units: US Retail Business Unit and US Distribution Business Unit.
Figure 1 Illustration of Data Access Configuration

 

 

 

 

 

 

 

 

Business unit access privileges are aggregated across roles 

If a user is granted access to a business unit by virtue of one role, the user has access to it across all applications and features.
For example, a user is assigned: 

  • Custom role for an Accounts Payable Specialist with access to  business unit A to create invoices

and 

  • Custom role for Accounts Payables Manager with access to business unit B to process payments

Warning signThe user will have access not only to create invoices but also payments for both business units. Such role assignments to create both invoices and payments would typically be deemed a SoD issue for most enterprises and is not recommended.

You need to ensure that your P2P staff can access and process P2P data only for the business units and business functions to which they’re entitled. 

 

Business functions in the P2P flow are illustrated in the table below.

Product Family

Business Function

Functional Area

Dependencies

Procurement

Requisitioning

Process purchase requisitions.

Receiving manages the receipt of goods (and services). Receiving is always executed in the same business unit as the requisition.

Procurement

Procurement
  • Manage supplier negotiations.
  • Create supplier sites and maintenance.
  • Process purchase orders.

 

Financials

Payables Invoicing

Process and approve supplier invoices.

Project Accounting manages project accounting and billing. Project accounting is always executed in the same business unit as Payables Invoicing.

 

Financials

Payables Payments

Process payment of supplier invoices and customer refunds.

 

 

A business unit may perform one or more business functions. Moreover, depending on the features of the applications, transactions may flow from one business unit to another.

Business unit security is central to all Procure to Pay transaction processes. The table below illustrates the data access default behavior as well as other alternative data access options by transaction type.

Transaction Type

Data Access Default Behavior

Other Data Access Alternatives

Requisitions through indirect procurement
  • Indirect procurement, could, for example, entail catering services for local events.
  • An employee or contingent worker creates requisitions in the business unit of their primary employee assignment.
  • Employees with Procurement Requester role can only create and view requisitions for themselves
  • You can explicitly assign to an employee or contingent worker the ability to create requisitions in other business units.

Requisitions through direct procurement
  • Direct procurement could, for example, entail purchasing paper for a book publisher, or sand for a glass manufacturer. 
  • Grant Procurement Agents access to one or more Procurement business units for requisition processing.

• A Procurement Preparer can view and create requisitions for other workers.

Purchase Orders
  • Grant Procurement Agents access to one or more Procurement business units for purchase order processing.
  • Procurement Agents can perform a wide range of actions on Purchase Orders, Purchase Agreements, Negotiations, etc.
  • Procurement Agents access documents they own (e.g., Purchase Orders they have created).

• Procurement Agents may also be granted access to view, modify, or perform any action on other Agents’ documents (in their Procurement business units).

Supplier Invoices and Payments
  • You explicitly assign access for a user to one or more business units through the security context in the Manage Data Access for Users page.

 
  • If the Payables Invoicing and Payables Payments business functions are assigned to different business units, a user with Payables Payments business function who submits a payment request must have access to both business units.

Disbursement Bank Accounts
  • Assign disbursement bank accounts to business units and thus apply business unit security.
  • You can further limit access to bank accounts to specific users and roles.
  • You can also secure bank account setup by legal entity. Cash managers can add, review, or modify only bank accounts associated with legal entities to which they have access.

Cross Business Unit P2P Processing 

In almost all companies with a centralized global or regional procurement function for strategic purchases, many purchases are also managed locally. 

A business unit with the Procurement business function is responsible for supplier negotiations, supplier site maintenance and purchase order processing. A Procurement business unit could, for example, represent a global shared service center (SSC) that administers purchase agreements with strategic suppliers. 

In Figure 2 the global procurement business unit is standalone. It has not been assigned any other business functions and has not been linked to a primary ledger.

  • In this example, the global centralized shared service center is the service provider. The SSC manages supplier negotiations to control costs. It manages supplier site maintenance, and purchase order processing. 
  • At a global or regional level direct procurement is usually centralized. For example, purchasing paper for a book publisher or sand for a glass manufacturer. Professional SSC members of the procurement department most commonly raise direct procurement requisitions.
  • However, at a local level at least some indirect procurement is managed, such as catering services for local events. Self-service non-professional users usually raise indirect procurement requisitions. 
  • Procurement business unit (BU) is linked via the supplier site assignment.
  • A regional SSC processes Payables invoices on behalf of two BUs within the same ledger in the US. 
Figure 3 shows a diagram with Future Corp Global Procurement BU at top of diagram Below are 3 companies: -Future Corp Spain with one Primary Ledger, and one Business Unit Future Corp US primary ledger with two business units All three business units have requisition functions linked via service provider relationship to global procurement BU. At the same time they all also have local procurement capabilities. Future Corp Spain BU with its own requisitioning flowing to global procurement BU, along with local procurement BU and local AP Invoicing (Bill to BU) Future Corp Inc BU in US
Figure 2 Example of Global Procurement BU along with Local Procurement BUs

 

 

 

 

 

 

 

For more information on flexible procurement models, refer to this blog post https://blogs.oracle.com/erp-ace/post/shared-service-centers-drive-for-quality-productivity-gains-and-cost-control and this Oracle Cloud Customer Connect webcast https://community.oracle.com/customerconnect/events/542598-erp-procure-to-pay-enterprise-structures-best-implementation-practices

Control Access to Chart of Account (COA) values with Segment Value Security (SVS)

A blog post here explains how to secure access to data in General Ledger (GL), including Segment Value Security (SVS). However, it’s important to note that SVS applies to any Oracle Cloud applications that utilize the Chart of Accounts. 

  • SVS policies restrict access to COA segment values for data entry, inquiry, and reporting (i.e., full “read and write”). 
  • Super users define access control to detail- and parent segment values of the COA with SVS. 
  • SVS, once activated for a value set,  prevents access to all values. That is, unless you are positively granted access via a custom job role.
  • You assign SVS rules to roles that are, in turn, assigned to your users.
  • SVS aggregates access privileges across roles. 

Conclusion

checklist

Consider your segregation of duties (SoD) requirements carefully. Plan access requirements for all your Procure to Pay staff to mitigate any SoD conflicts. This way you ensure your data access and security needs are addressed for your enterprise. 

 

Useful Documentation 

Topics in the security guides:

Guidance for Assigning Predefined Roles
Advisory Note on Subscription Impact
Predefined Roles with Subscription Impact spreadsheet
Oracle Fusion ERP, Securing ERP: https://docs.oracle.com/en/cloud/saas/applications-common/23b/faser/securing-erp.pdf
Overview of Security for Oracle Procurement Cloud: https://www.oracle.com/pls/topic/lookup?ctx=cloud&id=s20057112 
My Oracle Support article on Fusion Applications Security – Security Console FAQ (Doc ID 2145402.1)
My Oracle Support article on Payables Invoice Inquiry (Read-Only custom role) (Doc ID 2360565.1)