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.

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.

This figure shows the components of a data access set.
A data access set has an access set type and an access level.

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.

This figure shows an example of a data access set
with two levels of access.
Note: In financial reporting, the list of ledgers isn't secured by data access sets when viewing a report in Preview mode. Users can view the names of ledgers they don't have privileges to view. However, the data from a secured ledger doesn't appear on the report.

For more information about security assignments and managing data access for users, see the Oracle ERP Cloud Securing ERP guide.

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.

Note: You can enforce segment value security for inquiries and reporting based on any hierarchy, even hierarchies that aren't published to the reporting cube.

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.

This figure shows the steps to define and implement
segment value security.

To define segment value security roles:

  1. Create segment value security roles.

  2. Enable security on the value set.

    Note: You can enable security only on value sets with a type of Independent.
  3. Create conditions for the rule.

  4. Create policies to associate the conditions with the role.

  5. Deploy the accounting flexfield.

  6. Publish the account hierarchies.

  7. 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

  • Provides access to a specific detail or child value.

  • Don't use to provide access to a parent value.

Not equal to

  • Provides access to all detail and child values, except the one that you specify.

  • Don't use to provide access to a parent value.

Between

  • Provides access to detail and parent values within the specified range. For parent values, this access applies only to the parent value itself, and doesn't automatically include that parent's descendants unless those account values are also part of the specified range.

Is descendant of

  • Provides access to the parent value itself and all of its descendants including middle level parents and detail values.

Is last descendant of

  • Provides access to the last descendants for example, the detail values of a parent value.

Tip: For the operators Is descendant of and 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.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

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?

  • Child values 110 to 120

  • Child value 310

  • Parent value 400 and all its children

  • All cost centers

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.

  1. Define roles for segment value security rules.

  2. Enable segment value security for the value set.

  3. Define the conditions.

  4. Define the policies.

  5. Deploy the accounting flexfield.

  6. Publish the account hierarchies.

  7. 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.
  1. In the Tools work area, open the Security Console.

  2. Perform the following steps four times to create four roles.

  3. Click Create Role.

  4. On the Create Role page, complete the fields as shown in this table, and then click Next, Next, Next, Next, Next, Save and Close.

  5. 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.

    This figure shows the Create Role page.

Enabling Segment Value Security for the Value Set
  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Segment Value Security Rules

  2. In the Value Set Code field, enter Cost Center Main and click Search.

  3. In the Search Results section, click Edit to open the Edit Value Set page.

  4. Select the Security enabled option.

  5. In the Data Security Resource Name field, enter Secure_Main_Cost_Center_Values.

  6. 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.

    This figure shows the Edit Value Set page.

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.

  1. Click Edit Data Security to open the Edit Data Security page.

  2. On the Condition tab, click Create to open the Create Database Resource Condition window.

  3. Enter CC 110 - 120 in the Name field.

  4. Enter Cost Centers 110 to 120 in the Display Name field.

  5. 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.

  6. Click Add in the Conditions section.

  7. Select VALUE for the Column Name field.

  8. 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.

  9. 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.

    This figure shows the Create Database Resource
Condition page.

  10. Click Save.

  11. To create the next database resource condition for segment value 310, click Create on the Condition tab.

  12. Enter CC 310 in the Name field.

  13. Enter Cost Center 310 in the Display Name field.

  14. Click Add in the Conditions section.

  15. Select VALUE for the Column Name field.

  16. Select Equal to for the Operator field.

  17. 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.

    This figure shows the Create Database Resource
Condition page.

  18. Click Save.

  19. To create the next database resource condition for parent value 400, click Create on the Condition tab.

  20. Enter CC 400 in the Name field.

  21. Enter Parent Cost Center 400 in the Display Name field.

  22. In the Condition section, click Add.

  23. Select VALUE for the Column Name field.

  24. Select the Tree Operators option.

  25. 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.

  26. 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.

    This figure shows the Select Tree Node window.

  27. 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.

  28. In the Tree field, select All Corporate Cost Centers.

  29. In the Active Tree Version field, select V5.

  30. In the Tree Node field, select the Select from hierarchy button. The Tree Node section opens.

  31. 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.

    This figure shows the Select Tree Node window.

  32. 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.

    This figure shows the Create Database Resource
Condition page.

  33. Click Save.

Defining the Policies

Create policies to assign conditions to segment value security roles.
  1. On the Edit Data Security page, click the Policy tab.

  2. Click Create to open the Create Policy window.

  3. On the General Information tab, enter Policy for 110-120 in the Name field.

  4. Accept the default value of General Ledger in the Module field.

  5. 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.

    This figure shows the General Information tab on
the Create Policy page.

  6. Select the Role tab and click Add to open the Select and Add window.

  7. Enter 110 in the Role Name field.

  8. Select hcm in the Application field.

    Roles with the Default category are created in the hcm application.

  9. 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.

    This figure shows the Select and Add Roles window.

  10. 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.

    This figure shows the Role tab on the Create Policy
page.

  11. Select the Rule tab.

  12. 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.

  13. Click Search on the Condition field.

  14. 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.

    This figure shows the Rule tab on the Create Policy
page.

  15. Click Save and Close.

  16. Click OK to confirm.

  17. 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

  18. Click Done.

Deploying the Accounting Flexfield

You must deploy the accounting flexfield for the segment value security changes to take effect.
  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Manage Chart of Accounts Structures

  2. In the Module field, select General Ledger and click Search.

  3. 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.

    This figure shows the Manage Chart of Accounts
Structures page.

  4. Click OK.

Publishing the Account Hierarchies

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Financial Reporting Structures

    • Task: Publish Account Hierarchies

  2. In the Hierarchy field, select All Corporate Cost Centers.

  3. In the Hierarchy Version field, select V5.

  4. Click Search.

  5. In the Search Results section, expand the hierarchy row.

  6. Select the row for the hierarchy version V5.

  7. Click Publish.

  8. Click OK.

Assigning Segment Value Security Roles to Users

  1. In the Tools work area, open the Security Console.

  2. Enter Cost Center 110-120 SVS Role in the Search field and click Search.

  3. 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.

    This figure shows the Roles page and the Edit Role
menu option for the selected role.

  4. Click Next four times to navigate to the Edit Role: Users page.

  5. Click Add User.

  6. Enter Casey in the Search field and click Search.

  7. Click Add User to Role to add Casey Brown to the role.

  8. 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.

    This figure shows the Users section on the Edit
Role page.

  9. 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 are not 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.

Note: Balances cube security grants access to all values of the balancing segment value set for a data access set defined as either of the following:
  • 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 are 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.

Note: If you change an account hierarchy that's already published, you must republish to reflect the updated hierarchy in the balances cube. Use the Publish Account Hierarchy task to republish the tree version. Republishing the account hierarchy also ensures proper enforcement of security policies that are based on parent values included in the changed hierarchy.

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

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

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:

  1. Select the appropriate use for the application.

  2. Grant access to one or more business units.

Note: You can only assign access to the business units that use the same ledger as the bank accounts owning the legal entity,

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

You can implement application security options on the Manage System Security Options page as part of a complete security policy that's specific to your organization. Security options can be set for encryption and tokenization of credit cards and bank accounts, as well as for payment instrument masking. Security options are used for both funds capture and disbursement processes.

Note: Credit card services are currently not available in Oracle Financials Cloud implementations.
Note: Before you can import credit cards into Expenses, you must enable encryption or tokenization of credit cards in Payments.

To secure your sensitive data, consider the following security questions:

  • Which security practices do you want to employ?

  • Do you want to tokenize your credit card data?

  • Do you want to encrypt your bank account data?

  • Do you want to encrypt your credit card data?

  • How frequently do you want to rotate the master encryption key and the subkeys?

  • Do you want to mask credit card and bank account numbers, and if so, how?

In the Setup and Maintenance work area, use the following to set up application security options:

  • Offering: Financials

  • Functional Area: Payments

  • Task: Manage System Security Options

Best Security Practices

The following 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 that is 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. The master encryption key exists on the file system of Oracle Platform Security Services (OPSS). OPSS 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 is created and stored in the proper location and with all necessary permissions.

Credit Card Tokenization

If you tokenize your credit card data, you are 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.

You can set up your tokenization payment system by clicking Edit Tokenization Payment System on the Manage System Security Options page. Then, to activate tokenization for credit card data, click Tokenize in the Credit Card Data section.

Credit Card Data Encryption

You can encrypt your credit card data to assist with your compliance of cardholder data protection requirements with the following:

  • Payment Card Industry (PCI) Data Security Standard

  • Visa's PCI-based Cardholder Information Security Program (CISP)

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.

Note: If you bring card numbers into Payments through import, it's advisable to run the Encrypt Credit Card Data program immediately afterward.

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 Oracle Cash Management. They are used as disbursement bank accounts in Oracle 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.

Note: If you bring bank account numbers into Payments through import, it's advisable to run the Encrypt Bank Account Data program immediately afterward.

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 allows easier rotation of the master encryption key.

The master encryption key is stored on OPSS. OPSS 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, you can automatically generate a new one by clicking Rotate.

Note: To secure your payment instrument data, you're advised to annually rotate the master encryption key or rotate it according to your company's security policy.

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.

Note: To secure your payment instrument data, you are advised to schedule regular rotation of the subkeys.

The security architecture for credit card data and bank account data encryption is composed of the following components:

  • OPSS

  • Payments master encryption key

  • Payments subkeys

  • Sensitive data encryption and storage

The following figure illustrates the security architecture of the OPSS repository, the master encryption key, and the subkeys.

This figure illustrates the security architecture
of Oracle Platform Security Services, 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. Payments stores all of the customer and supplier payment information and their payment instruments, such as credit cards and bank accounts. Payments provides data security by allowing you to mask bank account numbers.

On the Manage System Security Options page, you can mask credit card numbers and external bank account numbers. To do it, 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.

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.

Note: Before you can import credit cards into Expenses, you must enable encryption or tokenization of credit cards in Payments. If you are using credit card data anywhere other than Expenses, you must enable tokenization in Payments.

To secure your credit card or bank account data, complete these steps:

  1. In the Setup and Maintenance work area, go to the following:

    • Offering: Financials

    • Functional Area: Payments

    • Task: Manage System Security Options

  2. On the Manage System Security Options page, click Apply Quick Defaults.

  3. Select all the check boxes:

    • Automatically create wallet file and master encryption key

    • Encrypt credit card data

    • Encrypt bank account data

  4. 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.

Note: Users can have any number of roles.

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.

Note: For more information about security, see the Securing Oracle ERP Cloud guide.

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.

Note: The Business Intelligence Consumer role allows users to view reports, but not create new ones. All other job roles inherit the Business Intelligence Author role, enabling users with those job roles to create new reports.

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
  • Budgetary Control - Transactions Real Time

Budget Manager

Budgetary Control Analysis Duty

  • Cash Management - Bank Statement Balances Real Time

  • Cash Management - Bank Statement Line Charges Real Time

  • Cash Management - Bank Statements Real Time

  • Cash Management - External Cash Transactions Real Time

Cash Manager

  • Cash Management Transaction Analysis Duty

  • Expenses - Employee Expense Overview Real Time

  • Expenses - Expense Transactions Real Time

Expense Manager

  • Expenses Summary Transaction Analysis Duty

  • Expense Transactions Transaction Analysis Duty

  • Financials Common Module - Intercompany Transactions Real Time

  • Intercompany Accountant

  • General Accountant

Inter Company Transaction Analysis Duty

  • Fixed Assets - Asset Assignments Real Time

  • Fixed Assets - Asset Balances Real Time

  • Fixed Assets - Asset Depreciation Real Time

  • Fixed Assets - Asset Financial Information 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 Accountant

  • Fixed Asset Transaction Analysis Duty

  • Fixed Asset Details Transaction Analysis Duty

  • Fixed Depreciation Transaction Analysis Duty

  • Fixed Asset Details Transaction Analysis Duty

  • General Ledger - Balances Real Time

  • General Ledger - Journals Real Time

  • General Ledger - Period Status Real Time

  • General Ledger - Transactional Balances Real Time

General Accountant

  • General Ledger Transaction Analysis Duty

  • Payables to Ledger Reconciliation Transaction Analysis Duty

  • Receivables to Ledger Reconciliation Transaction Analysis Duty

  • Payables Invoices - Installments Real Time

  • Payables Invoices - Prepayment Applications Real Time

  • Payables Invoices - Transactions Real Time

  • Payables Invoices - Trial Balance Real Time

  • Payables Invoices - Withholding Real Time

  • Payables Payments - Disbursements Real Time

  • Payables Payments - Payment History Real Time

  • Accounts Payable Manager

  • Accounts Payable Specialist

  • General Accountant

  • Payables to Ledger Reconciliation Transaction Analysis Duty

  • Payables Invoice Transaction Analysis Duty

  • Payables Payment Transaction Analysis Duty

  • Receivables - Adjustments Real Time

  • Receivables - Bills Receivable Real Time

  • Receivables - Credit Memo Applications Real Time

  • Receivables - Credit Memo Requests Real Time

  • Receivables - Customer Account Site Tax Profile Real Time

  • Receivables - Customer Real Time

  • Receivables - Customer Tax Profile Real Time

  • Receivables - Miscellaneous Receipts Real Time

  • Receivables - Payment Schedules Real Time

  • Receivables - Receipt Conversion Rate Adjustments Real Time

  • Receivables - Receipts Details Real Time

  • Receivables - Revenue Adjustments Real Time

  • Receivables - Standard Receipts Application Details Real Time

  • Receivables - Transactions Real Time

  • Accounts Receivable Manager

  • Accounts Receivable Specialist

  • General Accountant

  • Receivables to Ledger Reconciliation Transaction Analysis Duty

  • Receivables Customer Transaction Analysis Duty

  • Receivables Transaction Analysis Duty

  • Receivables Receipts Transaction Analysis Duty

  • Subledger Accounting - Journals Real Time

  • Subledger Accounting - Payables Summary Reconciliation Real Time

  • Subledger Accounting - Receivables Summary Reconciliation Real Time

  • Subledger Accounting - Supporting References Real Time

  • Cash Manager

  • Accounts Payable Manager

  • Accounts Receivable Manager

  • Asset 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:

  1. Select Navigator > Tools > Security Console.

  2. 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.

  3. 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.

  4. 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.

  5. Notice that the Payables Invoice Transaction Analysis Duty role inherits BI Consumer Role. Most of the OBI duty roles inherit BI Consumer Role.

Tip: You can export the role hierarchy to a spreadsheet for offline review.

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.

  1. Select Navigator > Tools > Reports and Analytics to open the Reports and Analytics work area.

  2. In the Contents pane, click the Browse Catalog icon. The Business Intelligence Catalog page opens.

  3. In the Folders pane, expand Shared Folders.

    Expand the Financials folder and then the Bill Management folder.

  4. Click the Customers Export Report folder.

    A list of reports appears on the BI Catalog page.

  5. 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.

  6. 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:

  1. 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.

  2. 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.