In a prior blog on How to Secure Data Access to Procure to Pay Transactions in Oracle Cloud ERP,  we highlighted the importance of Segregation of duties (SoD).

SoD is an administrative control used by organizations when more than one person is required to complete tasks in a business process. The aim of SoD is to prevent fraud, sabotage, theft, misuse of information, and other security violations. 

This blog post focuses on the Order to Cash process. You separate Order to Cash (O2C) activities such as creating customers, processing invoices, and receipts, through SoD. 

In addition, you determine how to restrict data access to selected lines of business transactions for certain O2C users. If you separate key processes and apply data access security, you mitigate risk of fraud and errors. 

In Oracle Cloud ERP, the data access to O2C 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 Generate Customer Statement.

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, Bills Receivable Management. 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 O2C 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 Billing and Revenue Management, Project Accounting, Customer Payments, and Collections Management. Business units should reflect stable real-world departments and not short-lived entities such as projects. 

You can secure data access for a person to certain business units for 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 Receivables 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 O2C data access security requirements of your O2C 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 O2C 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 for any updates to access definitions. 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 shows an example of an employee assigned a custom Billing Specialist job role. For illustration simplicity, the user has Create Receivables Transaction and Generate Customer Statements privileges only. 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: Maria Jones Job / Abstract Role: Billing Specialist, Employee Duty Role: Billing Management, Accounts Receivable Monitoring Privileges: Create Receivables Transaction, Generate Customer Statements 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 ConfigurationFigure 1 Illustration of Data Access Configuration

 

 

 

 

 

 

 

 

Business unit access privileges are aggregated across roles 

A user is granted access to a business unit by virtue of a role. If the user has been granted access to multiple roles and business units, the business unit data access applies across all applications and features.
For example, a user is assigned: 

  • Custom role for a Billing Specialist with access to  business unit A to create invoices

and 

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

caution

 

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

 

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

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

Product Family

Business Function

Functional Area

Dependencies

SCM

Order Fulfillment Orchestration

Manage processing of sales orders.

If Order Management is implemented, the Order Fulfillment and Billing & Revenue Management business units must be the same.

Financials

Billing and Revenue Management

 

Manage processing of customer invoices and credit memos in Receivables.

 

Sales Order-, Project Billing-, Subscription data, and AR Invoice data when processed in upstream BUs belonging to same Ledger data can be included in the same revenue contract in a Ledger in RM.

Financials

Customer Payments

 

Manage receipts of payment for customer invoices and customer refunds.

 

Localizations that report on both customer and supplier invoices are likely to assume that these business functions reside in the same business unit.

Refunds (payment of customer credit memos in Payables) generates the payment request in the same business unit as the credit memo.

Financials

Collections Management

 

Manage advanced collections, including strategies to collect balances owed by customers.

The Collections Management business function must be assigned to the same business unit as Billing & Revenue Management.

Financials

Bill Management*

 

External customers can view own bills, create, and manage disputes, and pay bills.

The Bill Management business function must be assigned to the same business unit as Billing & Revenue Management.

Financials

Credit Management*

Establish customer credit score and credit limit

Enable customer credit checks during quote,  order, and collections process to determine credit  limit.

Projects

Project Accounting

Manage project contracts (Enterprise contracts) and billing.

If both Project Accounting and Project Billing are implemented, the Project Accounting and Customer Contract Management business functions must be assigned to a business unit with both Payables Invoicing and Billing & Revenue Management business functions.

* These are not business functions that are assigned as part of the business unit setup but are included for completeness

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 most O2C transaction processes. The exception is Revenue Management. It combines sales cycle and billing data, for all business assigned to a ledger, to create one or more revenue contracts. Therefore, data access security for revenue contracts in Revenue Management applies at the ledger level. 

A diagram showing three horizontal streams for 3 business units (and 3 legal entities) with different sales order and invoice data for the same customer. Receivable journals for all three business units flow into one primary ledger displayed to the right and side of the flow. At the bottom of the flow is Revenue Management that can receive sales order data from all three business units as well as billing data for all three business units to create revenue contracts for a single ledger in Revenue Management. Journals for Revenue, Contract Assets, and Contract Liabilities flow from Revenue Management to the Primary Ledger.
Figure 2 Illustration of business unit data access security of sales orders and invoices but ledger data access security for revenue contracts and GL journals.

 

Cross Business Unit O2C Processing 

If you establish a shared service center (SSC) to process customer collections, you can request that customers transfer funds into the SSC bank account. SSC staff are assigned the appropriate duty roles, privileges, and security context. They can apply a cash receipt registered in the shared service center business unit to customer invoices that reside in another business units. 

You can separate the receivables business function for customer invoices from the business function for bank facing customer payments. You can use the service provider relationship to centralize customer collections across multiple customer invoicing BUs. Thus, model centralized management of the cash resource coupled with de-centralized management of invoice process. Receivables and Subledger Accounting process all intercompany aspects automatically, as explained in related blog here: https://blogs.oracle.com/erp-ace/post/ease-journals-partition-and-reporting-with-correct-legal-entity-design

This is the example reflected in figure 3 below.

This diagram depicts a single primary ledger with two business units and two legal entities. One business unit processes its own sales orders and invoices whilst the other business units processes its own sales orders and invoices but in addition processes payments on behalf of both business units, through the service provider relationship configuration.
Figure 3 Example of cross business unit customer payment process 


 

Caution

 

Be aware that Receivables Business Units cannot span multiple ledgers.

 

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 Order to Cash staff to mitigate any SoD conflicts. This way you ensure your data access and security needs are addressed for your enterprise.