Oracle Balance Sheet Planning extends setup and maintenance of assumptions by allowing users to integrate conditional logic (optional) into the setup of, prepayment methods. You can define prepayment methodologies using IF-THEN-ELSE logic based on the underlying characteristics of your financial instruments, such as dates, rates, balances, and code values. The Conditional Assumption UI is accessed from the Assumption Browser by selecting the Conditional Assumption icon.
The conditional logic is defined through use of Data Filters and/or Maps. These existing objects provide the building blocks for defining Conditional logic. For example, each Data Filter can provide the logic for a specific condition. In the example below, the where clause is "Adjustable Type Code = 'Adjustable Rate'". This type of Data Filter can be selected within the Conditional Assumption UI.
Similarly, a Mapper object provides the necessary reference to one or more hierarchies, when dimension / hierarchy data is needed to define conditional logic. In the example below, this map refers to a hierarchy created on the Organization Unit dimension.
Note Maps are accessed from the Infrastructure (HOME) page. You can find them at the following path: Common Object Maintenance > Unified Analytical Metadata > Map Maintenance |
To create a map, use the following steps:
1. Navigate to Map Maintenance.
2. Select icon to create new Map.
3. On the left hand side, select one or more hierarchies that were enabled in the initial step.
4. Fill in required information, e.g. Name, Effective Dates, and Entity Name.
5. Click Save button.
6. From the Map Maintenance Summary page, select the Map and the icon for " Mapper Maintenance".
Here, you will see the hierarchy and all parent/child relationships.
The range of product attributes supported for conditional assumptions and available for use within Data Filters is determined by columns which are part of the "Portfolio" definition. The "Portfolio" table class is seeded with the installation, and can be extended to include user defined columns.
For more information on adding user defined columns to the Portfolio table class, see Data Model Utilities Guide, Chapter 2 – Object Management.
When using mappers, Conditional Assumptions can be attached to any level of the hierarchy, allowing assumptions to be inherited from parent nodes by child nodes.
For example, you can use the Org Unit column to drive the assignment of Transfer Pricing Methods for all members of a particular Organization. You can create one Conditional Assumption to convey the entire Transfer Pricing Methodology logic and attach it to the top-level node of the Org Unit hierarchy. All nodes below the top-level node will inherit the same Transfer Pricing assumption.
The logic included in a Conditional Assumption determines the specific Transfer Pricing method, Prepayment assumption or Adjustment Rule that the system will assign to each individual instrument record at run time.
The Conditional Assumption screen allows users to select explicit conditions (from Data Filters and/or Maps) and apply methods and rule selections to each condition directly. The Filter Conditions are processed by the engine in the order that they appear on the screen. As soon as a condition is satisfied, the related assumption is applied. The following screenshot displays a representative Conditional Assumption using a Data
Note If an instrument record does not meet any of the conditions, then the rule logic reverts to the standard assumption that is directly assigned to the Product / Currency combination. In the example below, you can see that Fed Funds has both a direct assignment and a conditional assumption. If the condition is not met, the "Fixed Rate" assumption (ELSE condition) will be applied. In the case of Reverse Repo's, there is only a Conditional Assumption. In the absence of an ELSE assumption, the engine will use the conditional assumption in all cases for the Product/Currency pair. To avoid this, users should define the Standard/Else assumption with an appropriate input. |
Conditional Assumptions can be applied only to detailed account records (data stored in the Instrument Tables).