Fusion Applications implements the security using the Oracle Identity Management (IDM) stack.
The IDM stack consists of identity store and Policy store .
The Enterprise and Applications roles are implemented y in Identity and Policy stores respectively.
Enterprise Roles/External Roles – Maintained in OIM
Across all Fusion Applications, Abstract, Job and Data roles are mapped to Enterprise roles . These roles are stored in the Identity Store. They are managed through OIM and Identity Administration tools. This tool includes the following capabilities with respect to Enterprise role management:
Create Fusion Applications Implementation Users
Provision Roles to Implementation Users
Manage Abstract, Job and Data roles including the job hierarchy
Applications Roles – Maintained in APM
A “Duty Role” is mapped to Application Roles and is stored in the Policy Store. An application role is supplied by a single application or pillar of applications. The application policies are managed through “Authorization Policy Manager” (APM). APM is a graphical interface that simplifies the creation, configuration, and administration of application policies. Applications Authorization Policy Manager (APM) refers to enterprise roles as external roles.
If you are creating a custom role. then First you create external role in OIM and then create custom Application Role in APM and map external role to the application role in External Role Mapping Tab as shown below
Alternatively you can also map application role to the external role in APM as shown below under application role mapping. You need to first inquire the external role and then map the application role.
The default behavior is available in the cloud… (e.g. overlay natural account segment only on top of the clearing ccid). What we don’t offer is pl/sql based customization as we did in EBS for it. To enable you need to set the DEFAULT lookup code for FA_MASS_ADD_PREPARE_RULES lookup type to enabled.
We have added a few lookup-based rules to meet Ovations requirements as well. The defaults out of the box will do as i stated before, but in addition to that , you can use some of the “ORA_FA_MASSADD_MAP%” lookup types to do minor tweaks such as:
ORA_FA_MASSADD_MAP_EXP_BASE controls whether base ccid is the clearing account of book default account
ORA_FA_MASSADD_MAP_EXP_BSV allows overriding the BSV from clearing (only has an impact if base ccid is the book default account)
ORA_FA_MASSADD_MAP_EXP_CC allows overriding the CC from clearing (only has an impact if base ccid is the book default account)
ORA_FA_MASSADD_MAP_EXP_ACCT allows overriding from category expense account (the default and probably only viable option- the other option is based on Projects Expenditure Organization’s Name and very much customized to Ovations’ setup (where the ORG names match the value set values, etc)
Hierarchies for financial reporting: Must be published to Essbase cubes. Child values in these hierarchies cannot roll up to different parents within a hierarchy as this functionality is not support when publishing such hierarchies to Essbase.
Hierarchies for allocations: Must be published to Essbase cubes. Used with Calculation Manager in creating allocation rules.
Hierarchies for cross validation rules, revaluation, Data Access Set and chart of accounts mapping:
- Created within the same hierarchy and must be associated with a chart of accounts instance.
- You can only associate one hierarchy with a chart of accounts instance, per segment.
Such hierarchies can have the same child to roll up to different parents.
- Do not publish to the Essbase cube since multiple child assignments are not supported in the Essbase cube.
- NOTE: these hierarchies will not be available for reporting and allocations.
- Only the tree assigned to the segment in COA definition will be displayed in the DAS UI.
- Make sure to perform Column and Row Flattening for these hierarchies.
Security Rules: You can specify the tree and tree version to be used while defining the data security condition.