Special Considerations for Segment Value Security

Back-End Processes

Segment value security by business function isn’t enforced for back-end processes.

Back-end processes are submitted processes that run in the background without active engagement from users. Some of these processes can generate or update financial data that’s framed by chart of account values like accounting transactions and account balances.

This table provides examples of such back-end processes.

Module	Back-End Processes
General Ledger	Posting, Translation, Revaluation, Open Period
Subledger Accounting	Create Accounting

Note: While reports on financial data are also submitted for processing, they aren’t considered back-end processes. They’re requests to display financial data in an output format.

Segment value security by business function isn't enforced for such back-end processes for these reasons.

As accounting becomes more automated, administrators are more likely to submit back-end processes on behalf of end users, who work with the financial data resulting from these processes.
In some cases, the application itself might initiate the submission of the back-end process.
The user submitting back-end processes might be detached from the end users who will ultimately work with the resulting financial data.
There might be a lack of direct correlation between the back-end processes and the security profiles of the users submitting these processes.

The key to securing financial data is to ensure that end users should only be able to access the financial data that they’re authorized to work with. As such, enforcement of segment value security by business function is strictly applied when such users update financial data, or report or inquire on it.

Setup Tasks

Segment value security by business function isn’t enforced for setup tasks.

Some setup tasks are related to the configuration of application or processing rules that produce accounting transactions and financial data. Such setup tasks often touch on elements of a chart of accounts and include configurations and mapping rules that drive what chart of account values will be used when the financial data is generated.

Access to such setup tasks, especially around setting up reference data, is typically granted only to an administrator job role, where users assigned that role would be responsible for configuring the application. These users don't work directly with the financial data itself.

In addition to reference data setup, these tasks also include transaction generation setups, which can directly generate accounting or journal entries.

Here are some examples.

Assets: Asset book definition
General Ledger: Allocation formulas
General Ledger: Chart of accounts configuration
General Ledger: Chart of Accounts Mapping rules
General Ledger: Ledger definition
General Ledger: Revaluation definitions
Intercompany: Balancing Account rules
Receivables: AutoInvoicing rules
Subledger Accounting: Create Accounting rules
Subledger Accounting: Transaction Account Builder rules

Setup tasks typically don’t have a selection for a security context value, such as a data access set, business unit, asset books, or intercompany organization, for the purposes of establishing the data security element while working on the setup record.

If such security context objects were referenced, it's for the purpose of identifying which instance of that object the setup is being configured for, rather than about creating financial data with that security context value.

The administrator, or the user provided functional access to work with such setup tasks, can set up configurations and accounting rules across all ledgers, business units, asset books, and intercompany organizations in the application. A setup administrator user can use any account value, even for a secured chart of accounts value set. Access to the setup tasks alone allows the user to work with any of such setup records without further data security enforcement.

Oracle Transactional Business Intelligence Reporting

For segment value security with Oracle Transactional Business Intelligence (OTBI) reporting, enforcement by business function isn't supported.

Once a chart of accounts value set is secured, security will be enforced across all business functions, regardless of whether each distinct business function is enabled for enforcement or not. So long as the value set is security enabled, security enforcement will apply in all business functions of General Ledger, Payables, Receivables, Assets, Intercompany, and Subledger Accounting.

With OTBI reporting, it's possible to put together reports that cross multiple products (business functions). Moreover, the user doesn't directly select which data access security context (Data Access Set, Business Unit, Asset Books, and so on.) to currently work with. Instead, in general, the user's cumulative data access security assignments are always simultaneously taken together. Both of these factors affect the ability to precisely and fully apply segment value security by business function.

When performing OTBI reporting with the General Ledger subject area specifically, the user's current data access set selection determines the applicable data security. This is because the user's currently selected data access set in the application is stored in a profile option. The application leverages this and singularly applies it in evaluating which segment value security user rule assignments should apply for the user when reporting on ledgers with a secured chart of accounts. When reporting on ledgers that don't have a secured chart of accounts, the user's cumulative assigned data access sets are simultaneously applied.

Features Without a Data Security Context

There are product features that involve working directly with financial transactions and balances where a user’s data security context can’t be established.

Here are some examples.

Standard Subledger Accounting Oracle Analytics Publisher reports that can involve the financial data of one or more ledgers where there isn’t always a direct or unique match to a specific security context value that’s assigned to a user, such as a data access set.
Non-General Ledger Oracle Transactional Business Intelligence reports where no specific data security context selection can be established for a user to derive the specific segment value security by business function grants that are applicable to that user.

For these features, a modified form of segment value security by business function enforcement is applied. A percentage value is substituted for certain user rule assignment attributes to indicate that no specific value needs to be matched for the security grants. This broader basis of user rule assignment matching still limits a user’s access to the secured accounts that the user is granted access to when working with financial data, but on a nonspecific basis.

Here’s how it works for such features.

When determining if there are matching rule assignments for a user that can restrict the range of accessible secured accounts, the Security Context and Security Context Value attribute settings will be ignored to lower the matching threshold. The Business Function and Access Level attributes for that rule assignment can still be considered.

This would be in place of automatically applying the All Values grant when no precise user rule assignments match for the current usage scenario. That approach would effectively mean that no chart of accounts security would be enforced. Instead, this alternative approach will at least limit a user to working with only the financial data where the cumulative grants for each secured value set of the chart of accounts provide access, should such grants exist.

As another example, when working with features in the Subledger Accounting application, a user doesn't explicitly specify a security context selection (that is, a data access set, business unit, and so on). With General Ledger, that same user can simultaneously work with the financial data of ledgers across the user's cumulative data access set assignments.

This means that for those security grants for a user that can be tagged with a specific security context value, such as a data access set, it isn't possible to make perfect matches of the user’s more precisely defined rule assignments for the usage scenario in Subledger Accounting. If it happens that such grants are tagged with the All Security Contexts security context, or the Data Access Set security context paired with the All Security Context Values security context value, such grants for the user are also included as a match.

For a General Ledger user, all the user's General Ledger business function rule assignments for the secured value sets involved with the charts of accounts of the ledgers that user is working with will also be applied. This is regardless of the data access set security context and security context value that’s associated with those rule assignments. That is, all the user’s General Ledger business function rule assignments for the secured value sets will be cumulatively applied. If under such looser matching conditions there are still no matching grants for the user, only then will the default All Values grant to the relevant secured value sets apply.

Multiple Secured Chart of Account Segments

Consider these points when working with account combinations where the chart of accounts has multiple segments enabled for segment value security by business function.

For a given usage scenario, a user’s access to the account values of each secured chart of accounts segments is first considered individually and independently of the other. Then, if a user has a mixture of access levels to the account values for an account combination, the lowest level of access among these account values would be applied to the full account combination.
For an account combination where a user has no access to at least one segment's account value, that account combination is immediately one to which the user has no access. This is because access to the account combination requires access to each of its secured segment values.
For an account combination where a user has read-only access to at least one segment's account value, that account combination is a read-only account combination for the user. This is because read and write access to an account combination requires read and write access to each of the account combination's secured segment values.

As an example, the first and second segments of account combination 01-101-1000 are secured. A user has read-only access to first segment value 01 and no access to second segment value 101. The user won't have access to that account combination. Even if the user had read and write access to first segment value 01, the user still wouldn't have access to account combination 01-101-1000.

Continuing with this example, a different user has read-only access to first segment value 01 and read and write access to second segment value 101. That user’s applicable access level to account combination 01-101-1000 will be read only.

To have read and write access to account combination 01-101-1000, a user must have read and write access to both first segment value 01 and second segment value101.

If a user doesn’t have at least read-only access to accounts on every secured segment of an account combination, that user won’t even have read-only access to that account combination.

Primary Balancing Segment Value Assignments to a Ledger and Its Legal Entities

Assigning a primary balancing segment value to a ledger, or to its legal entities, isn’t chart of accounts data security related.

It’s a validation against the accounting configuration for a ledger that affects which primary balancing segment values are available and valid for a user to work with for the given ledger.

If a ledger has primary balancing segment value assignments and a particular primary balancing segment value isn’t assigned to that ledger, or to its legal entities, then that primary balancing segment value won’t be available to the user when working with that ledger. This is regardless of whether the user has been granted access using either of the following methods:

The user is provided a segment value security grant for that particular primary balancing segment value for that chart of accounts with a secured primary balancing segment.
The user is granted access to that primary balancing segment value through a full ledger data access set or a primary balancing segment value-based data access set, in the case of the General Ledger module.

Switching from Secured to Unsecured Modules

When users switch from one of the modules that support segment value security by business function to a module that doesn't, they might continue to experience limited account access in the unsecured module.

To resolve this, users might need to sign out of the application and sign back in when switching modules. This action resets the cache and allows users access to all accounts in those modules where security enforcement isn't expected.