16Security in Oracle Financials
This chapter contains the following:
Security for Country-Specific Features
For new implementations, you must assign the country-specific duty roles to your enterprise job roles or users to use the features specific to these regions. You must assign country-specific duty roles to FSCM application and OBI application stripe. After assigning these roles, you can view the country-specific reports on the Scheduled Processes page, and open the Parameters page of the selected process.
This table describes the duty roles for each region:
| Region | Duty Role | Role Code |
|---|---|---|
|
Europe, the Middle East, and Africa (EMEA) |
EMEA Financial Reporting |
ORA_JE_EMEA_FINANCIAL_REPORTING_DUTY |
|
Asia Pacific (APAC) |
APAC Financial Reporting |
ORA_JA_APAC_FINANCIAL_REPORTING_DUTY |
|
Asia Pacific (APAC) |
Enterprise Financial Data Export Management for China |
ORA_JA_CN_ENTERPRISE_FINANCIAL_DATA_EXPORT_ONLY_FOR_CHINA_DUTY_OBI |
|
Asia Pacific (APAC) |
Golden Tax Management for China |
ORA_JA_GOLDEN_TAX_MANAGEMENT_FOR_CHINA_DUTY_OBI |
General Ledger
Overview of General Ledger Security
General ledger functions and data are secured through job roles, data access sets, and segment value security rules.
Functional Security
Functional security, which is what you can do, is managed using job roles. The following job roles are predefined for Oracle Fusion General Ledger:
-
General Accounting Manager
-
General Accountant
-
Financial Analyst
Each job role includes direct privilege grants, as well as duty role assignments, to provide access to application functions that correspond to their responsibilities. For example, the General Accounting Manager role grants comprehensive access to all General Ledger functions to the general accounting manager, controller, and chief financial officer in your organization.
Data Security
Data security, which controls what action can be taken against which data, is managed using:
-
Data access sets
-
Segment value security rules
Data access sets can be defined to grant access to a ledger, ledger set, or specific primary balancing segment values associated with a ledger. You decide whether each data access set provides read-only access or read and write access to the ledger, ledger set, or specific primary balancing segment values, which typically represent your legal entities that belong to that ledger. Primary balancing segment values without a specific legal entity association can also be directly assigned to the ledger.
Segment value security rules control access to data that's tagged with the value set values associated with any segment in your chart of accounts.
Security Assignment
Use the Security Console to assign users roles (job roles, as well as roles created for segment value security rules or others). Use the Manage Data Access Set Data Access for Users task to assign users data access sets as the security context paired with their General Ledger job role assignments.
For more information about security assignments and managing data access for users, see the Oracle ERP Cloud Securing ERP guide.
Overview of Data Access Set Security
Data Access Sets secure access to ledgers, ledger sets, and portions of ledgers using primary balancing segment values. If you have primary balancing segment values assigned to a legal entity, then you can use this feature to secure access to specific legal entities.
You can combine ledger and ledger set assignments in single data access sets if the ledgers share a common chart of accounts and calendar. If you have primary balancing segment values assigned to a legal entity within the ledger, then you can use data access sets to secure access to specific legal entities. You can also secure access to primary balancing segments assigned directly to the ledger.
When a ledger or ledger set is created, a data access set for that ledger or ledger set is automatically created, giving full read and write access to those ledgers. You can also manually create data access sets to give read and write access, or read-only access to entire ledgers or portions of the ledger represented as primary balancing segment values.
The following figure shows that a data access set consists of an access set type and an access level. The access set type can be set to full ledger or primary balancing segment value. The access level can be read only or read and write.
The Full Ledger access set type provides access to the entire ledger or ledger set. This could be for read-only access or both read and write access to the entire ledger.
The Primary Balancing Segment Value access set type provides access to one or more primary balancing segment values for that ledger. This access set type security can be specified by parent or detail primary balancing segment values. The parent value must be selected from the tree that's associated with the primary balancing segment of your chart of accounts. The specified parent value and all its descendants, including middle level parents and detail values are secured. You can specify read only, read and write access, or combination of both, for different primary balancing segment values for different ledgers and ledger sets.
For more information about security assignments and managing data access for users, see the Oracle ERP Cloud Securing ERP guide.
Examples of Data Access Set Security
This example shows a data access set that secures access by using primary balancing segment values that correspond to legal entities.
Scenario
The following figure shows a data access set for the US Financial Services Ledger. The access set type is Primary Balancing Segment Value, with each primary balancing segment value representing different legal entities. Read-only access has been assigned to primary balancing segment value 131, which represents the Insurance legal entity. Read and write access has been assigned to primary balancing segment values 101 and 102, which represent the Banks and Capital legal entities.
For this data access set, the user can:
-
View the journals, balances, and reports for primary balancing segment value 131 for the Insurance legal entity.
-
Create journals and update balances, as well as view journals, balances and reports for primary balancing segment value 101 and 102 for legal entities Banks and Capital.
For more information about security assignments and managing data access for users, see the Oracle ERP Cloud Securing ERP guide.
Segment Value Security
Set up segment value security rules on value sets to control access to parent or detail segment values for chart of accounts segments, also called flexfield segments. Segment value security rules restrict data entry, online inquiry, and reporting.
Secured Value Sets
When you enable security on a value set, access to all values for that value set is denied. To control access to value set values, you enable security on the value set, create conditions, and then assign the conditions to roles. The roles should be created solely for the purpose of segment value security. The roles are then assigned to users.
If a value set is secured, every usage of that value set in a chart of accounts structure instance is secured. For example the same security applies if that value set is:
-
Used for two or more segments in the same chart of accounts, such as the primary balancing and intercompany segments
-
Shared across different segments of different charts of accounts
Secured Segment Values
Segment value security applies mainly when data is created or updated, and when account combinations are queried. When you have access to secured account values, you can view and use those secured values across all modules of the applications where there are references to accounting flexfields including:
-
Transaction entry pages
-
Balances and transactions inquiry pages
-
Setup pages
-
Reports
On setup pages, you can still view referenced account combinations with secured account values, even if you haven't been granted access to those secured values. However, if you try to update such references, you can't use those secured values. On reports, you can view balances for secured account values only if you have access to those secured values.
Segment Value Security Implementation
You implement segment value security using the Security Console and these pages: Manage Value Sets, Manage Chart of Accounts Structures, Publish Account Hierarchies.
The following figure shows the steps for defining and implementing security rules for segment values.
To define segment value security roles:
-
Create segment value security roles.
-
Enable security on the value set.
Note: You can enable security only on value sets with a type of Independent. -
Create conditions for the rule.
-
Create policies to associate the conditions with the role.
-
Deploy the accounting flexfield.
-
Publish the account hierarchies.
-
Assign the role to users.
Whenever you assign segment value security roles to a user, the rules from the user's assigned roles can be applied together. All of the segment value security roles assigned to a user pertaining to a given value set are simultaneously applied when the user works with that value set. For example, one rule provides access to cost center 110 and another rule provides access to all cost centers. A user with both of these segment value security rules has access to all cost centers when working in a context where that value set matters.
Segment Value Security Conditions
When you create a condition, you specify an operator. The following table describes the operators that you can use.
| Operator | Usage |
|---|---|
|
Equal to |
|
|
Not equal to |
|
|
Between |
|
|
Is descendant of |
|
|
Is last descendant of |
|
-
Specify an account hierarchy (tree) and a tree version to use these operators.
-
Understand that the security rule applies across all the tree versions of the specified hierarchy, as well as all hierarchies associated with the same value set of the specified hierarchy.
Example of Segment Value Security
You can set up segment value security rules on value sets to control access to parent or detail segment values for chart of accounts segments. Segment value security rules restrict data entry, online inquiry, and reporting.
The following example describes why and how you might want to use segment value security.
Securing Values for the Cost Center and Account Segments
For this scenario, only certain users should have access to the Accounting cost center and the US Revenue account. To create a complete data security policy that restricts segment value access to those users:
-
Plan for the number of roles that represent the unique segment value security profiles for your users. For this scenario, you can create two roles, one for the cost center segment and one for the account segment.
-
Use the Security Console to create the roles. Append the text SVS-role to the role names so it's clear the roles are solely for segment value security. For this scenario, you create roles Accounting Cost Center-SVS Role and US Revenue Account-SVS Role.
-
Use the Manage Segment Value Security Rules task to enable security on the cost center and account value sets associated with the chart of accounts.
-
Create a condition for each value set. For example, the condition for the Accounting cost center is that the cost center is equal to Accounting.
-
Create a policy to associate the conditions to the roles. For example, create a policy to assign the condition for the Accounting cost center to the role Accounting Cost Center-SVS Role.
-
Use the Security Console to assign the appropriate role to the appropriate user. For example, assign the role Accounting Cost Center-SVS Role to the users who should have access to the Accounting cost center.
Enable Security on a Chart of Accounts
This example demonstrates how to enable security on a chart of accounts to control access to specific segment values.
The following table summarizes the key decisions for this scenario.
| Decisions to Consider | In This Example |
|---|---|
|
Which segment in the chart of accounts must be restricted? |
Cost center |
|
Which cost center values have to be granted to different users? |
|
|
What's the name of the value set for the segment with the Cost Center label? |
Cost Center Main |
|
What's the name of the user who can access cost centers 110 to 120? |
Casey Brown |
|
What's the name of the tree for the accounting flexfield? |
All Corporate Cost Centers |
|
What version of the tree hierarchy does the condition apply to? |
V5 |
Summary of the Tasks and Prerequisites
This example includes details of the following tasks you perform when defining and implementing segment value security.
-
Define roles for segment value security rules.
-
Enable segment value security for the value set.
-
Define the conditions.
-
Define the policies.
-
Deploy the accounting flexfield.
-
Publish the account hierarchies.
-
Assign segment value security roles to users.
Perform the following prerequisites before enabling security on a chart of accounts:
-
To work with the Security Console, you need the IT Security Manager role assigned to your user setup.
-
To work with value sets and profile options, you need the Financial Application Administrator role.
-
Set the Enable Data Security Policies and User Membership Edit profile to Yes.
Defining Roles for Segment Value Security Rules
To create a complete data security policy, create the roles first so that they're available for assignment to the segment value security rules.-
In the Tools work area, open the Security Console.
-
Perform the following steps four times to create four roles.
-
Click Create Role.
-
On the Create Role page, complete the fields as shown in this table, and then click Next, Next, Next, Next, Next, Save and Close.
-
Click OK and complete the fields, as shown in this table.
Field Role 1 Role 2 Role 3 Role 4 Role Name
Cost Center 110-120 SVS Role
Cost Center 310 SVS Role
Cost Center 400 SVS Role
Cost Center All SVS Role
Role Code
CC_110_120_SVS_ROLE
CC_310_SVS_ROLE
CC_400_SVS_ROLE
CC_ALL_SVS_ROLE
Role Category
Default
Default
Default
Default
Description
Access to cost centers 110 to 120.
Access to cost center 310.
Access to parent cost center 400 and all its children.
Access to all cost centers.
The following figure shows the Create Role page for the first role, which is Cost Center 110-120 SVS Role. The role code, role category, and description fields are complete.
Enabling Segment Value Security for the Value Set
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Financial Reporting Structures
-
Task: Manage Segment Value Security Rules
-
-
In the Value Set Code field, enter Cost Center Main and click Search.
-
In the Search Results section, click Edit to open the Edit Value Set page.
-
Select the Security enabled option.
-
In the Data Security Resource Name field, enter Secure_Main_Cost_Center_Values.
-
Click Save.
The following figure shows the Edit Value Set page for the Cost Center Main value set. Security is enabled and a data security resource name has been entered.
Defining the Conditions
Use conditions to specify the segment values that require security.Segment value security rules that provide access to all segment values, and segment value security rules that provide access to single nonparent segment values, don't need a condition. Instead, you can define the policy to cover all values, and you can define a policy to cover a single nonparent segment value provided that you know the internal ID for that segment value. If you don't know the internal ID, you can create a condition for that single segment value.
In this scenario, the internal ID for segment value 310 isn't known, so the following steps create all of the conditions, except for the access to all cost centers, which the policy definition can cover.
-
Click Edit Data Security to open the Edit Data Security page.
-
On the Condition tab, click Create to open the Create Database Resource Condition window.
-
Enter CC 110 - 120 in the Name field.
-
Enter Cost Centers 110 to 120 in the Display Name field.
-
Accept the default value of All for the Match field.
Matching to All means that all of the condition rows apply simultaneously and all of them must be met in identifying the values.
Matching to Any means that any of the condition rows could apply. For example, if you create multiple condition rows, each of which on its own is an alternative scenario for identifying the values that apply, you would select Match to Any.
Because this example only has one condition row, the Match selection doesn't matter. If however, you define multiple condition rows for segment value security, you would have to select Match to Any, because a single account value can't satisfy multiple account value-based conditions.
-
Click Add in the Conditions section.
-
Select VALUE for the Column Name field.
-
Select Between for the Operator field.
Note: You can select one of the following operators: Equal to, Not equal to, Between, Is descendant of, Is last descendant of. -
Enter 110 in the first Value field and 120 in the second Value field.
The following figure shows the Create Database Resource Condition page for the condition named CC 110 - 120. The display name is Cost Centers 110 to 120, and one condition is defined. The condition has a column name of VALUE, an operator of Between, and the specified values are 110 and 120.
-
Click Save.
-
To create the next database resource condition for segment value 310, click Create on the Condition tab.
-
Enter CC 310 in the Name field.
-
Enter Cost Center 310 in the Display Name field.
-
Click Add in the Conditions section.
-
Select VALUE for the Column Name field.
-
Select Equal to for the Operator field.
-
In the Value field, enter 310.
The following figure shows the definition of the second condition.
The following figure shows the Create Database Resource Condition page for the condition named CC 310. The display name is Cost Center 310, and one condition is defined. The condition has a column name of VALUE, an operator of Equal to, and the specified value is 310.
-
Click Save.
-
To create the next database resource condition for parent value 400, click Create on the Condition tab.
-
Enter CC 400 in the Name field.
-
Enter Parent Cost Center 400 in the Display Name field.
-
In the Condition section, click Add.
-
Select VALUE for the Column Name field.
-
Select the Tree Operators option.
-
For the Operator field, select Is a last descendant of, which restricts access to the parent cost center 400 and all of its children, including intermediary parents.
Note: For the Tree Operators field, you can only select Is a last descendant of or Is a descendant of. -
In the Value column, click the Select Tree Node icon to open the Select Tree Node window.
The following figure shows the Select Tree Node window. Values are required for the Tree Structure, Tree, and Active Tree Version fields. The window also includes these Tree Node options: Specify primary keys, Select from hierarchy.
-
In the Tree Structure field, select Accounting Flexfield Hierarchy. This signifies that you are choosing among trees that are used as accounting flexfield, or charts of accounts, hierarchies.
-
In the Tree field, select All Corporate Cost Centers.
-
In the Active Tree Version field, select V5.
-
In the Tree Node field, select the Select from hierarchy button. The Tree Node section opens.
-
In the Tree Node section, expand the nodes and select 400.
The following figure shows the Select Tree Node window after completing the fields in steps 27 through 31.
-
Click OK.
The following figure shows the resulting Create Database Resource Condition page for the condition named CC 400. The display name is Parent Cost Center 400 and one condition is defined. The condition has a column name of VALUE, an enabled Tree Operators option, an operator called Is a last descendant of, and a value of 400.
-
Click Save.
Defining the Policies
Create policies to assign conditions to segment value security roles.-
On the Edit Data Security page, click the Policy tab.
-
Click Create to open the Create Policy window.
-
On the General Information tab, enter Policy for 110-120 in the Name field.
-
Accept the default value of General Ledger in the Module field.
-
Enter 9/1/16 in the Start Date field.
The following figure shows the General Information tab on the Create Policy page for the policy named Policy for 110-120. The start date for the policy is 9/1/16.
-
Select the Role tab and click Add to open the Select and Add window.
-
Enter 110 in the Role Name field.
-
Select hcm in the Application field.
Roles with the Default category are created in the hcm application.
-
Click Search.
The following figure shows the Select and Add Roles window with the search results. The role retrieved by the search results is named Cost Center 110-120 SVS Role.
-
Select Cost Center 110-120 SVS Role and click OK.
The following figure shows the Role tab on the Create Policy page with the role that was populated by the search results.
-
Select the Rule tab.
-
Accept the default setting of Multiple Values in the Row Set field.
Note: The Row Set field determines the range of value set values affected by the policy.-
If Multiple Values is selected, a condition must be specified.
-
If All Values is selected, then the policy grants access to all values in the value set and no condition is needed.
-
If Single Value is selected, then the internal Value ID for the segment value must be specified and no condition is needed.
-
-
Click Search on the Condition field.
-
Select Cost Centers 110 to 120 for the Condition field and click OK.
The following figure shows the Rule tab on the Create Policy page. The selected row set is Multiple Values and the condition is Cost Centers 110 to 120.
-
Click Save and Close.
-
Click OK to confirm.
-
Repeat steps 2 through 13 to create the rest of the policies, using the values in the following table.
Field Policy 2 Policy 3 Policy 4 General Information tab, Name
Policy for 310
Policy for 400
Policy for all cost centers
General Information tab, Start Date
9/1/16
9/1/16
9/1/16
Role tab, Role Name
Cost Center 310 SVS Role
Cost Center 400 SVS Role
Cost Center All SVS Role
Rule tab, Row Set
Multiple Values
Multiple Values
All Values
Rule tab, Condition
Cost Center 310
Parent Cost Center 400
Not Applicable
-
Click Done.
Deploying the Accounting Flexfield
You must deploy the accounting flexfield for the segment value security changes to take effect.-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Financial Reporting Structures
-
Task: Manage Chart of Accounts Structures
-
-
In the Module field, select General Ledger and click Search.
-
Select the row for the Accounting Flexfield and click Deploy Flexfield.
The following figure shows the Manage Chart of Accounts Structure page after searching for General Ledger modules. The search results display a row with a key flexfield named Accounting Flexfield.
-
Click OK.
Publishing the Account Hierarchies
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Financial Reporting Structures
-
Task: Publish Account Hierarchies
-
-
In the Hierarchy field, select All Corporate Cost Centers.
-
In the Hierarchy Version field, select V5.
-
Click Search.
-
In the Search Results section, expand the hierarchy row.
-
Select the row for the hierarchy version V5.
-
Click Publish.
-
Click OK.
Assigning Segment Value Security Roles to Users
-
In the Tools work area, open the Security Console.
-
Enter Cost Center 110-120 SVS Role in the Search field and click Search.
-
In the Search Results section, select the down arrow icon and select Edit Role.
The following figure shows the Roles page and the available menu options, including Edit Role, for the role named Cost Center 110-120 SVS Role.
-
Click Next four times to navigate to the Edit Role: Users page.
-
Click Add User.
-
Enter Casey in the Search field and click Search.
-
Click Add User to Role to add Casey Brown to the role.
-
Click OK to confirm.
The following figure shows the Edit Role page for the Cost Center 110-120 SVS Role with the user Casey Brown selected.
-
Repeat steps 2 through 8 to add the other roles to different users as needed.
Data Security Differences in GL Features Based on Balance Cubes
In certain cases, differences in data security can appear depending on whether the GL feature being used is directly or indirectly based on the balances cube. For example, this can occur when a user is assigned multiple data access sets for the same balances cube with different security specifications for ledger or primary balancing segment value access, or when segment value security rule assignments are involved.
General Ledger features based directly on the balances cube are:
-
Inquire on Detail Balances
-
Account Monitor
-
Account Inspector
-
Financial Reporting
-
Smart View
-
Allocations
All other General Ledger features are indirectly based on the balances cube.
When using features indirectly related to the balances cube, you select a specific data access set and you work only with that one data access set at a time. The defined ledger and primary balancing segment value access for the selected data access set are enforced.
When using features directly related to the balances cube, the cumulative effects of your combined data access sets for that balances cube are enforced. From your combined data access sets for that cube, balances cube security separately constructs the access filter for the ledger dimension and primary balancing segment values dimension independently of the other dimensions. This means the specific combination of ledger and primary balancing segment values access as defined in each distinct data access set aren't enforced as such. Instead, you have access simultaneously to all the ledgers and all the primary balancing segment values granted to you through your combined data access sets.
-
Full ledger
-
All Values: Specific Balancing Segment Values Access Type
With segment value security rules assigned to you through your various roles, the security rules are in effect simultaneously whether working directly or indirectly with the balances cube.
Segment value security rules are specified for a particular value set. Therefore, as you're working on anything that references the secured value set, all segment value security rules for that value set that are assigned to you through any of your roles are in effect at the same time, regardless of the specific role the rule was assigned to. In other words, segment value security rules are cumulative, or the union of all the segment value security rules you have assigned to you through your roles. If you have one role assigned to your user that only grants access to cost center 200, and another role that grants access to cost centers 300 through 500, then you have access to cost centers 200 and 300 through 500.
When using features indirectly based on the balances cube, such as journal entry pages, the primary balancing segment values you can access are based on the intersection of:
-
Primary balancing segment values granted to you through your current selected data access set.
-
All of your assigned segment value security rules pertaining to the primary balancing segment value set across all of your assigned segment value security roles.
So, if a balancing segment value is only granted in either of the selected data access set or a segment value security role, that balancing segment value isn't available to you.
In contrast, for features directly based on the balances cube, your access is based on the cumulative union of:
-
Primary balancing segment values granted to you through all your assigned data access sets related to the balances cube that you're working with.
-
Any segment value security rule grants to that primary balancing segment value set across all of your segment value security role assignments.
Example
This setup is used to more clearly and comprehensively illustrate the difference in how security works for features directly and indirectly related to the balances cube with respect to data access sets and segment value security, though this might not generally reflect a real-life example.
In this example, your job role is assigned two different data access sets for the Vision Corporation ledger. The Vision Corporation 01 data access set is assigned primary balancing segment value 01, and the Vision Corporation 02 data access set is assigned primary balancing segment value 02. You are also assigned segment value security roles SVS 01 and SVS 03.
The following table lists the job role, data access set, and primary balancing segment value assignments for this example.
| Job Role | Data Access Set | Primary Balancing Segment Value |
|---|---|---|
|
General Accounting Manager |
Vision Corporation 01 |
01 |
|
General Accounting Manager |
Vision Corporation 02 |
02 |
The following table lists the primary balancing segment values that are assigned to you through the segment value security roles.
| Segment Value Security Role | Primary Balancing Segment Value |
|---|---|
|
SVS 01 |
01 |
|
SVS 03 |
03 |
Select Vision Corporation 01 Data Access Set
For features indirectly based on the balances cube, you can access primary balancing segment value 01. This segment value represents the intersection of the Vision Corporation 01 data access set and the SVS 01 and SVS 03 segment value security roles.
Neither your selected data access set, nor your segment value security roles provide access to Company 02, and your selected data access set Vision Corporation 01 and your cumulative segment value security roles SVS01 and SVS03 only intersect on primary balancing segment value 01, and not on 03.
For features directly based on the balances cube, you can access primary balancing segments 01, 02, and 03. These segment values represent the union of your assigned data access sets and segment value security roles. With the balances cube, all data access sets assigned to you that are related to the balances cube you're working with apply simultaneously, regardless of the data access set you selected to work with in the application.
Select Vision Corporation 02 Data Access Set
For features indirectly based on the balances cube, you can't access any primary balancing segment value because none of the values from the Vision Corporation 02 data access set and SVS 01 and SVS 03 segment value security roles intersect.
For features directly based on the balances cube, you can access primary balancing segments 01, 02, and 03. These values represent the union of your assigned data access sets and segment value security roles.
FAQs for General Ledger
What happens when changes are made to an account hierarchy that's referenced in segment value security rules?
The tree is set from an active to a draft state. The rules referencing the account hierarchy become ineffective.
After making changes to your hierarchy, you can submit the Process Account Hierarchies process to automatically run the required steps for processing account hierarchies updates in one submission, including:
-
Tree audit
-
Tree activation
-
Row flattening
-
Column flattening
-
Maintain value set
-
Maintain account hierarchy
-
Publish hierarchy
With a successful audit process, the hierarchy is set back to an active status. The rules referencing the account hierarchy go back to being effective using the updated hierarchy.
Run the row and column flattening processes for the updated hierarchy as the flexfield component in the application as well as other hierarchy processes rely on the flattened hierarchy data to come up with the list of values available to the user to properly secure the correct account values.
Run the Maintain Value Sets and Maintain Chart of Account Hierarchies processes, particularly for hierarchy changes to the primary balancing segment value set if such values are referenced in your primary balancing segment value based data access sets. These processes update the data that is required to regulate ledger and data access security by storing:
-
Primary balancing segment values assigned to a ledger.
-
Specific child balancing segment values assigned to a data access set through parent value assignments.
When does security take effect on chart of accounts value sets for balances cubes?
To enforce segment value security according to defined security policies, you must enable security on the value set before you publish the affected account hierarchies to the balances cube. Likewise, to stop enforcing segment value security for a previously secured value set, you must disable security on the value set and then republish the account hierarchies.
Once segment value security is enforced, you don't have to republish account hierarchies if you define new security policies or modify existing policies for the secured value set, even if the security definition has hierarchical conditions that use parent values.
How can I secure the data in GL balances cubes?
Use data access set and segment value security to secure dimension values such as ledger and chart of account values. For chart of accounts dimension values, security restricts the display of data associated with the secured values, but not the selection of the values themselves. For example, when submitting a report, you can select company value 100 in your report definition when selecting the Point of View, even if you weren't granted access to that company value. However, you can't see the data associated with company 100 in your report.
Payables
Payables Security
In Oracle Fusion Payables you secure access to invoices and payments by business unit. You can access invoices and payments for viewing or processing only in the business units to which you have permission. The permission must be explicitly granted to each user.
You assign users to the appropriate security context, such as a business unit, for job roles using the Manage Data Access for Users page.
Payables is integrated to the document repository for processing scanned invoices. Edit access to the document repository is granted to the following predefined roles:
-
Accounts Payable Manager
-
Accounts Payable Specialist
-
Accounts Payable Supervisor
-
Accounts Payable Invoice Supervisor
The following predefined roles have view-only access to the document repository:
-
Financial Application Administrator
-
Cost Accountant
-
Project Accountant
Subledger Accounting
Security for Subledger Accounting
Oracle Fusion Subledger Accounting features require both function and data security privileges.
Overview
Security for Subledger Accounting includes:
-
Setup task security
-
Security to configure accounting rules to define accounting treatments for transactions.
-
-
Transaction task security
-
Security to create subledger journal entries (manual subledger journal entries or those generated by the Create Accounting process or Online Accounting).
-
Security to review and generate reports of subledger journal entries and lines.
-
Security to Perform Setup Tasks
Use the Define Subledger Accounting Rules task in the Setup and Maintenance work area to configure subledger accounting rules.
To configure subledger accounting rules, the setup user must be provisioned with a role that includes the Subledger Accounting Administration duty role.
-
In the security reference implementation, the Financial Application Administrator job role hierarchy includes the Subledger Accounting Administration duty role. This role provides the access to configure your accounting rules.
-
For more information about available setup job roles, duty roles and privileges, see the Oracle Financial Security Reference Manual.
Security to Perform Transactional Tasks
To create and view subledger journal entries, you must have the necessary access to perform the tasks in the relevant subledger work areas. Predefined subledger job roles include the entitlement to create and view subledger journal entries for subledger transactions you are authorized to access.
Security for Accounting Transformations in Accounting Hub
Accounting transformations require both function and data security privileges.
Oracle Accounting Hub security for accounting transformations includes:
-
Setup task security
-
Security to register source systems into Accounting Hub.
-
Security to configure accounting rules to define accounting treatments for transactions.
-
-
Transactional task security
-
Security to create subledger journal entries (manual subledger journal entries or those generated by the Create Accounting process).
-
Security to review and generate reports of subledger journal entry headers and lines.
-
Security to Perform Setup Tasks
Use the Define Accounting Transformation Configuration task in the Setup and Maintenance work area to integrate your external source system with the Accounting Hub.
To register your external source system and configure accounting rules, the setup user must be provisioned with a role that includes the following duty roles:
-
Application Implementation Consultant
-
Accounting Hub Integration
-
In the security reference implementation, the Financial Application Administrator job role hierarchy includes the Accounting Hub Administration Duty role. This role provides the access to integrate your external source systems with accounting transformations.
Security to Perform Transactional Tasks
To import transaction data for accounting and posting in general ledger, the user must be provisioned with a job role that is associated with the Accounting Hub Integration duty role.
-
The Import Subledger Accounting Transactions privilege is assigned to the Accounting Hub Integration duty role. This role enables the user to submit the Import Subledger Accounting Transactions process. This process also creates accounting entries and posts them in the general ledger.
To create and view subledger journal entries as an independent task, you must have the access necessary to perform the tasks. These tasks can be opened from the Oracle General Ledger, Journals work area. You must have access to the work area, as well as all of the ledgers (primary, secondary and reporting currency) in which the journal entry is posted.
The following are defined in the security reference implementation:
-
The General Accounting Manager job role hierarchy includes duty roles that provide the entitlement to manage general accounting functions. This entitlement provides access to the general ledger, Journals work area.
The following duty role must be assigned directly to the General Accounting Manager job role to provide access to create and view subledger journal entries:
-
Accounting Hub Integration Duty
Alternatively, you can assign the Subledger Accounting Duty and Subledger Accounting Reporting Duty roles to any of the following general ledger job roles:
-
Chief Financial Officer
-
Controller
-
Financial Analyst
-
General Accountant
For more information about available setup job roles, duty roles, and privileges, see the Oracle Financials Cloud Security Reference guide on the Oracle Help Center.
Cash Management
Considerations When You Create Accounts
Banks, branches and accounts fit together on the premise of the Bank Account model. The Bank Account model enables you to define and keep track of all bank accounts in one place.
The Bank Account Model can explicitly grant account access to multiple business units, functions, and users. Consider the following when you set up bank accounts:
-
Assign a unique general ledger cash account to each account, and use it to record all cash transactions for the account. This facilitates book to bank reconciliation.
-
Grant bank account security. Bank account security consists of bank account use security, bank account access security, and user and role security.
Account Use
Account Use refers to accounts created for:
-
Oracle Fusion Payables
-
Oracle Fusion Receivables
-
Oracle Fusion Payroll
Select the appropriate use or uses when creating an account in one or more of these applications.
Account Access
Payables and Receivables account access is secured by business unit. Before the bank account is ready for use by Payables or Receivables, you must:
-
Select the appropriate use for the application.
-
Grant access to one or more business units.
User and Role Security
You can further secure the bank account so that it can only be used by certain users and roles. The default value for secure bank account by users and roles is No. For Payables and Receivables, you must have the proper business unit assigned to access a bank account even if the secure bank account by users and roles is No. If the secure bank account by users and roles is set to Yes, you must be named or carry a role assigned to the bank account to use it.
-
You must assign the security duty role Cash Management Administration to the Cash Manager job role to provide access for setting up banks, branches, and accounts. You must have the assigned Manage Bank Account Security privilege to modify the User and Role Security.
-
If you want to restrict the access to the Security tab, you must create a customized role and remove the privilege Manage Bank Account Security. For example, you would copy the Cash Management Administration duty role, rename it, and remove the privilege.
GL Cash Account Segments
Consider selecting the option to enable multiple cash account combinations for reconciliation if you want to reconcile journal lines of multiple cash account combinations matching the same natural account and other specified segment values.
For example, if you set up 01-000-1110-0000-000 as your cash account, and select Account and Sub-Account as GL Cash Account Segments, you're able to manually or automatically reconcile journal lines entered on different account code combinations matching the same natural account '1110' and sub-account '0000'.
Assets
Assets Data Security Components
In Oracle Fusion Assets, you can secure access to assets to perform transactions and view their information by asset book. Every asset book created in Assets is automatically secured. You can perform transactions or view asset data only in the books to which you have permission. The permission must be explicitly granted to each user based on his or her duty requirements.
Data Privileges
Each activity is individually secured by a unique data privilege. In other words, when you provide access to a book, you actually provide permission to perform a particular activity in that book. For example, you can allow user X to perform only tasks related to asset additions in book AB CORP and restrict the same user from performing asset retirements in this book.
The data accesses for different asset activities are secured for the book with the following data privileges:
-
Add Fixed Asset Data
-
Change Fixed Asset Data
-
Retire Fixed Asset Data
-
Track Fixed Asset Data
-
Submit Fixed Assets Reports
Asset Book Security Context
After you have completed your Assets setup, you can assign job roles to users using the Security Console and then grant explicit data access for asset books using the Manage Data Access for Users task from the Setup and Maintenance work area.
Default Asset Books
Since the data access is secured by book, you must provide or select the book to perform transactions and view asset details. If you have access to only one book, you can set up this book as the default book. The default book value must be set using the Default Book profile option. You set the value at the site, product, or user level. Usually, the default book is automatically entered in the Book field when you perform transactions and run reports. You can override the default value and enter another value from the list of values.
Payments
Options for System Security
Implement application security options on the Manage System Security Options page. You can set the application security to align with your company's security policy. You can set security options for encryption and tokenization of credit cards and bank accounts, as well as for masking the payment instrument. Both funds capture and disbursement processes use security options.
Ask yourself these security questions to improve the security of your sensitive data:
-
Which security practices do I want to employ?
-
Do I want to tokenize my credit card data?
-
Do I want to encrypt my bank account data?
-
Do I want to encrypt my credit card data?
-
How frequently do I want to rotate the master encryption key and the subkeys?
-
Do I want to mask credit card and bank account numbers? How do I accomplish that?
To set up application security options, go to Financials > Payments > Manage System Security Options in the Setup and Maintenance work area.
Best Security Practices
These actions are considered best security practices for payment processing:
-
Comply with the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is the security standard required for processing most types of credit cards.
-
Comply with all requirements for accepting credit card payments.
-
Minimize the risk of exposing sensitive customer data.
-
-
Create the master encryption key.
-
Rotate the master encryption key periodically.
-
Implementation Process of Master Encryption Key and Encryption
Before you can enable encryption for credit card or bank account data, you must automatically create a master encryption key. Oracle Platform Security Services stores your master encryption key. The application uses your master encryption key to encrypt your sensitive data.
Automatic creation of the master encryption key ensures that it's created and stored in the proper location and with all necessary permissions.
Credit Card Tokenization
If you tokenize your credit card data, you're complying with PCI DSS requirements. PCI DSS requires companies to use payment applications that are PCI DSS compliant.
Tokenization is the process of replacing sensitive data, such as credit card data, with a unique number, or token, that isn't considered sensitive. The process uses a third-party payment system that stores the sensitive information and generates tokens to replace sensitive data in the applications and database fields. Unlike encryption, tokens can't be mathematically reversed to derive the actual credit card number.
Click Edit Tokenization Payment System on the Manage System Security Options page to set up your tokenization payment system. Then, click Tokenize in the Credit Card Data section to activate tokenization for credit card data.
Credit Card Data Encryption
You can encrypt your credit card data to assist with your compliance of cardholder data protection requirements with these initiatives:
-
Payment Card Industry Data Security Standard
-
Visa's Cardholder Information Security Program
Credit card numbers entered in Oracle Receivables and Oracle Collections are automatically encrypted. Encryption is based on the credit card encryption setting you specify on the Manage System Security Options page.
Bank Account Data Encryption
You can encrypt your supplier and customer bank account numbers.
Bank account encryption doesn't affect internal bank account numbers. Internal bank accounts are set up in Cash Management. They are used as disbursement bank accounts in Payables and as remit-to bank accounts in Receivables.
Supplier, customer, and employee bank account numbers entered in Oracle applications are automatically encrypted. Encryption is based on the bank account encryption setting you specify on the Manage System Security Options page.
Master Encryption Key and Subkey Rotation
For payment instrument encryption, Payments uses a chain key approach. The chain key approach is used for data security where A encrypts B and B encrypts C. In Payments, the master encryption key encrypts the subkeys and the subkeys encrypt the payment instrument data. This approach enables easier rotation of the master encryption key.
The master encryption key is stored on Oracle Platform Security Services. Oracle Platform Security Services stores data in an encrypted format. The master encryption key can be rotated, or generated, which also encrypts subkeys, but doesn't result in encrypting the bank account numbers again.
If your installation has an existing master encryption key, click Rotate to automatically generate a new one.
You can also select the frequency with which new subkeys are automatically generated, based on usage or on the maximum number of days. To specify a subkey rotation policy, click Edit Subkey Rotation Policy.
The security architecture for credit card data and bank account data encryption is composed of these components:
-
Oracle Platform Security Services
-
Payments master encryption key
-
Payments subkeys
-
Sensitive data encryption and storage
This figure illustrates the security architecture of the Oracle Platform Security Services repository, the master encryption key, and the subkeys.
Credit Card and Bank Account Number Masking
Payments serves as a payment data repository for customer and supplier information. It stores all of the customer and supplier payment information and their payment instruments, such as credit cards and bank accounts. It provides data security by letting you mask bank account numbers.
On the Manage System Security Options page, you can mask credit card numbers and external bank account numbers. You just have to select the number of digits to mask and display. For example, a bank account number of XXXX8012 displays the last four digits and masks all the rest. These settings specify masking for payment instrument numbers in the user interfaces of multiple applications.
Enable Encryption of Sensitive Payment Information
Financial transactions contain sensitive information, which must be protected by a secure, encrypted mode. To protect your credit card and external bank account information, you can enable encryption. Encryption encodes sensitive data, so it can't be read or copied. To enable encryption, you must create a master encryption key. Oracle Platform Security Services is a repository that stores your master encryption key. The application uses your master encryption key to encrypt your sensitive data.
To secure your credit card or bank account data, complete these steps:
-
In the Setup and Maintenance work area, go to Financials > Payments > Manage System Security Options.
-
On the Manage System Security Options page, click Apply Quick Defaults.
-
Select all the check boxes:
-
Automatically create wallet file and master encryption key
-
Encrypt credit card data
-
Encrypt bank account data
-
-
Click Save and Close.
Business Intelligence
Overview of Financial Reporting Security
Security for financial reporting uses Role Based Access Control, which has the following components:
-
Users with roles.
-
Roles that grant access to functions and data.
-
Functions and data access that is determined by the combination of role.
Data security, which controls what action can be taken against which data, can also be applied to financial reporting. Data security is managed using:
-
Data Access Sets:
-
Are defined to grant access to a ledger, ledger set, or specific primary balancing segment values associated with a ledger.
-
Permit viewing of journals, balances, and reports.
-
-
Segment Value Security Rules:
-
Are set up on value sets to control access to parent or detail segment value for chart of accounts segments.
-
Restrict data entry, online inquiry, and reporting.
-
Oracle Fusion Transactional Business Intelligence Security
Oracle Fusion Transactional Business Intelligence is a real-time, self-service reporting solution. All application users with appropriate roles can use Transactional Business Intelligence to create analyses that support decision making. In addition, business users can perform current-state analysis of their business applications using a variety of tools. These include Oracle Business Intelligence Enterprise Edition as the standard query and reporting tool, Oracle Business Intelligence Answers, and Oracle Business Intelligence Dashboard tools. This topic summarizes how access is secured to Transactional Business Intelligence subject areas, Business Intelligence Catalog folders, and Business Intelligence reports.
Subject Areas
Subject areas are functionally secured using duty roles. The names of duty roles that grant access to subject areas include the words Transaction Analysis Duty (for example, Payables Invoice Transaction Analysis Duty).
The following table identifies the subject areas that predefined Financials job roles can access.
| Financials Job Role | Subject Areas |
|---|---|
|
Accounts Payable Manager |
All Payables |
|
Accounts Payable Specialist |
All Payables |
|
Accounts Payable Supervisor |
Payables Invoices - Installments Real Time, Payables Payments - Disbursements Real Time, Payables Payments - Payment History Real Time |
|
Accounts Receivable Manager |
All Receivables |
|
Accounts Receivable Specialist |
All Receivables |
|
Asset Accountant |
Fixed Assets - Asset Depreciation Real Time, Fixed Assets - Asset Retirements and Reinstatements Real Time, Fixed Assets - Asset Source Lines Real Time, Fixed Assets - Asset Transactions Real Time, Fixed Assets - Asset Transfer Real Time |
|
Asset Accounting Manager |
All Fixed Assets |
|
Budget Manager |
Budgetary Control - Transactions Real Time |
|
Cash Manager |
All Cash Management |
|
Expense Manager |
All Expenses |
|
Financial Analyst |
All Financials |
|
Financial Application Administrator |
All Financials |
|
Financial Integration Specialist |
All Financials |
|
General Accountant |
General Ledger - Journals Real Time, General Ledger - Period Status Real Time |
|
General Accounting Manager |
All General Ledger, All Payables, All Receivables |
|
Intercompany Accountant |
Financials Common Module - Intercompany Transactions Real Time |
|
Tax Accountant |
Payables Invoices - Withholding Real Time, Receivables - Customer Account Site Tax Profile Real Time |
|
Tax Administrator |
Payables Invoices - Withholding Real Time, Receivables - Customer Account Site Tax Profile Real Time |
|
Tax Manager |
Payables Invoices - Withholding Real Time, Receivables - Customer Account Site Tax Profile Real Time, Receivables - Customer Tax Profile Real Time |
|
Tax Specialist |
Payables Invoices - Withholding Real Time, Receivables - Customer Account Site Tax Profile Real Time, Receivables - Customer Tax Profile Real Time |
Analyses fail if the user can't access all subject areas in a report.
Business Intelligence Catalog Folders
Business Intelligence Catalog folders are functionally secured using the same duty roles that secure access to the subject areas.
The following table identifies the folders that predefined Financials job roles can access.
| Financials Job Role | Business Intelligence Catalog Folders |
|---|---|
|
Accounts Payable Manager |
Transactional Business Intelligence Payables |
|
Accounts Payable Specialist |
Transactional Business Intelligence Payables |
|
Accounts Payable Supervisor |
Transactional Business Intelligence Payables |
|
Accounts Receivable Manager |
Transactional Business Intelligence Receivables |
|
Accounts Receivable Specialist |
Transactional Business Intelligence Receivables |
|
Asset Accountant |
Transactional Business Intelligence Fixed Assets |
|
Asset Accounting Manager |
Transactional Business Intelligence Fixed Assets |
|
Budget Manager |
Transactional Business Intelligence Budgetary Control |
|
Cash Manager |
Transactional Business Intelligence Cash Management |
|
Expense Manager |
Transactional Business Intelligence Expenses |
|
Financial Analyst |
Transactional Business Intelligence Financials |
|
General Accountant |
Transactional Business Intelligence General Ledger |
|
General Accounting Manager |
Transactional Business Intelligence General Ledger |
|
Intercompany Accountant |
Transactional Business Intelligence Intercompany Accounting |
|
Tax Accountant |
Transactional Business Intelligence Transaction Tax |
|
Tax Administrator |
Transactional Business Intelligence Transaction Tax |
|
Tax Manager |
Transactional Business Intelligence Transaction Tax |
|
Tax Specialist |
Transactional Business Intelligence Transaction Tax |
Business Intelligence Reports
Analyses are secured based on the folders in which they're stored. If you haven't secured Business Intelligence reports using the report privileges, then they're secured at the folder level by default. You can set permissions against folders and reports for Application Roles, Catalog Groups, or Users.
You can set permissions to:
-
Read, Execute, Write, or Delete
-
Change Permissions
-
Set Ownership
-
Run Publisher Report
-
Schedule Publisher Report
-
View Publisher Output
How Reporting Data Is Secured
The data that's returned in Oracle Transactional Business Intelligence reports is secured in a similar way to the data that's returned in application pages. Data access is granted by roles that are linked to security profiles. This topic describes the part played by Transaction Analysis Duty Roles in securing access to data in Transactional Business Intelligence reports. It also describes how to enable this access in custom job roles.
Transaction Analysis Duty Roles
Each of the Transaction Analysis Duty roles providing access to subject areas and Business Intelligence Catalog folders is granted one or more data security policies. These policies enable access to the data.
Custom Job Roles
If you create a custom job role with access to Transactional Business Intelligence reports, then you must give the role the correct duty roles. Your custom role must have both the OBI and Financials versions of the Transaction Analysis Duty roles. These duty roles ensure that your custom job role has the function and data security for running the reports.
For example, if your role must access the Fixed Asset Transaction Analysis subject areas, then it must inherit the duty roles described in the following table:
| Duty Role | Version |
|---|---|
|
Fixed Asset Transaction Analysis Duty |
OBI |
|
Fixed Asset Transaction Analysis |
Financials |
The Fixed Asset Transaction Analysis Duty role is granted relevant data security policies and inherits Business Intelligence Consumer Role.
Business Intelligence Roles: Explained
Oracle Business Intelligence roles apply to both Oracle Business Intelligence Publisher and Oracle Fusion Transactional Business Intelligence. They grant access to Business Intelligence functionality, such as the ability to run or author reports. These roles are in addition to the roles that grant access to reports, subject areas, Business Intelligence catalog folders, and Financials data. This topic describes the Business Intelligence roles.
This table lists the Business Intelligence roles.
| Business Intelligence Role | Description |
|---|---|
|
Business Intelligence Consumer Role |
Allows reporting from Business Intelligence Applications, Business Intelligence Publisher, Real Time Decisions, Enterprise Performance Management and Business Intelligence Office. This role allow you to run reports from the web catalog but it will not allow a report to be authored from a subject area. |
|
Business Intelligence Authoring |
Allows authoring within Business Intelligence Applications, Business Intelligence Publisher, Real Time Decisions, Enterprise Performance Management and Business Intelligence Office. |
|
Business Intelligence Applications Analysis |
Performs Business Intelligence Applications Analysis generic duty. |
|
Fixed Asset Business Intelligence Management |
Manages access to Fixed Assets OBIA Dashboard. |
|
Business Intelligence Applications Administrator |
Provides access to the BI Applications Configuration Manager and to the BI Data Warehouse Administration Console. |
Delivered Roles for Financials Subject Areas
Access to subject areas in the Oracle Business Intelligence Catalog is secured by OTBI Transactional Analysis Duty roles. The following table lists subject areas and the corresponding job role and OTBI Transactional Analysis duty role that are required for creating user-defined reports using the subject areas. The OTBI Transactional Analysis duty role is inherited by the job role. Use this table to verify that your users have the job roles necessary to create reports using subject areas.
The following table lists subject areas for Financials and the default security roles needed for each one.
| Subject Areas | Job Role | OTBI Transactional Analysis Duty Role |
|---|---|---|
|
Budget Manager |
Budgetary Control Analysis Duty |
|
Cash Manager |
|
|
Expense Manager |
|
|
|
Inter Company Transaction Analysis Duty |
|
Asset Accountant |
|
|
General Accountant |
|
|
|
|
|
|
|
|
|
Subledger Accounting Transaction Analysis Duty |
Reporting Roles and Permissions
Viewing reporting roles and permissions can help you to understand how Oracle Transactional Business Intelligence security works.
This topic explains how to view:
-
The reporting roles that a job role inherits
-
The permissions for sample Oracle Transactional Business Intelligence reports in the Business Intelligence Catalog
Viewing Inherited Reporting Roles on the Security Console
Sign in with the IT Security Manager job role and follow these steps:
-
Select Navigator > Tools > Security Console.
-
On the Security Console, search for and select a job role. For example, search for and select the Accounts Payable Manager job role.
Depending on the enterprise setting, either a graphical or a tabular representation of the role appears. Switch to the tabular view if it doesn't appear by default.
-
Accounts Payable Manager inherits many duty roles, such as Payables Balance Analysis and Payables Invoice Processing. These roles (without the word Duty in their names) are Financials roles. Their role codes start with the characters ORA_. Find these roles in the table.
-
Notice also the many Transaction Analysis Duty roles (with the word Duty in their names) that appear at the console. For example, Accounts Payable Manager inherits the Transactional Analysis Duty. These roles are OBI roles. Their role codes start with the characters FBI_. Find these roles in the table.
-
Notice that the Payables Invoice Transaction Analysis Duty role inherits BI Consumer Role. Most of the OBI duty roles inherit BI Consumer Role.
Viewing Permissions in the Business Intelligence Catalog
To view these permissions, you must have a role that inherits BI Administrator Role. None of the predefined Financials job roles inherits BI Administrator Role.
-
Select Navigator > Tools > Reports and Analytics to open the Reports and Analytics work area.
-
In the Contents pane, click the Browse Catalog icon. The Business Intelligence Catalog page opens.
-
In the Folders pane, expand Shared Folders.
Expand the Financials folder and then the Bill Management folder.
-
Click the Customers Export Report folder.
A list of reports appears on the BI Catalog page.
-
Click Costing Reports > More > Permissions.
The Permissions dialog box opens. Scroll if necessary to see the complete list of permissions, which includes the role BI Administrator Role.
-
Click the Oracle Applications tab to return to the home page.
Configure Security for Oracle Transactional Business Intelligence
Oracle Transactional Business Intelligence secures reporting objects and data through a set of delivered Transaction Analysis Duty roles. You can't configure the Transaction Analysis Duty roles provided with Oracle Financials Cloud, or the associated security privileges. However, you can configure reporting security according to your security requirements as described in this topic.
Oracle Transactional Business Intelligence secures reporting objects and data through the following types of roles:
-
Reporting objects and data are secured through the predefined OTBI Transactional Analysis Duty roles. The Transaction Analysis Duty roles control which subject areas and analyses a user can access and what data a user can see.
-
Business Intelligence roles, for example, BI Consumer Role, or BI Author Role. These roles grant access to Business Intelligence functionality, such as the ability to run or author reports. Users need one or more of these roles in addition to the roles that grant access to reports and subject areas to create and run reports and view analytics.
You can't copy or modify the Business Intelligence roles or the Transaction Analysis Duty roles provided with Oracle Financials, or the associated security privileges. In addition, any role with a role code prefix of OBIA, for example, Business Intelligence Applications Analysis Duty (OBIA_ANALYSIS_GENERIC_DUTY), can also not be copied. However, you can configure reporting security according to your security requirements as described in this topic.
Modifying Transaction Analysis Duty Role Assignments
To configure the subject areas that users have access to create a custom job role and provide the role with the Oracle Transactional Business Intelligence duty roles that provide the required access.
For example, you can create a role that provides access to both general ledger and fixed assets subject areas by assigning both the General Ledger Transaction Analysis Duty and the Fixed Asset Transaction Analysis Duty to the role.
Modifying Business Intelligence Role Assignments
The Business Intelligence roles enable users to perform tasks within Business Intelligence tools such as Oracle Business Intelligence Publisher. The default Business Intelligence roles used in Oracle Financials Cloud are BI Consumer and BI Author.
The delivered Transaction Analysis Duty roles inherit the BI Consumer Role, which provides view-only access to analyses and reports. You assign the BI Author Role at the job role level, giving you flexibility in granting the BI Author privilege to only those job roles that you want to have access to create and edit analyses and reports.
All predefined Financials Cloud job roles that inherit a Transaction Analysis Duty role are also assigned the BI Author Role by default. You can optionally create copies of the predefined job roles and add or remove the BI Author Role from the roles as required.
Business Intelligence Publisher Secured List Views
Oracle Business Intelligence Publisher is a set of tools for creating formatted reports based on data models. You can access Business Intelligence Publisher from Business Intelligence Composer or the Business Intelligence Catalog by clicking New > Report. This topic describes how you can use secured list views to secure access to data in Business Intelligence reports.
Some reporting tools combine the data model, layout, and translation in one report file. With that approach, business-intelligence administrators must maintain multiple copies of the same report to support minor changes. By contrast, Business Intelligence Publisher separates the data model, layout, and translation. Therefore, reports can be:
-
Generated and consumed in many output formats, such as PDF and spreadsheet
-
Scheduled for delivery to e-mail, printers, and so on
-
Printed in multiple languages by adding translation files
-
Scheduled for delivery to multiple recipients
Business Intelligence Publisher Data Security and Secured List Views
When you create a Business Intelligence Publisher data model with physical SQL, you have two options.
You can:
-
Select data directly from a database table, in which case the data you return isn't subject to data-security restrictions. Because you can create data models on unsecured data, you're recommended to minimize the number of users who can create data models.
-
Join to a secured list view in your select statements. The data returned is determined by the security profiles that are assigned to the roles of the user who's running the report.