What's New in 11.3

Oracle Insurance Policy Administration (OIPA) 11.3.0.0 includes the following feature enhancements in the Rules Palette and OIPA applications.

Funds and Valuation Enhancements

Ability to have Funds with Negative Values

This feature allows Fixed Funds to contain negative cash values and negative deposits in the valuation processing. The enhancement provides a provision to the configuror whether to allow negative fund values using a definition element. When the Removals from a fund are larger than the fund's value, OIPA represents this deficiency as a negative fund value. The daily interest, expense, and costs are accumulated as additional deficiencies to this negative fund value. A negative interest accumulates a negative cash value and further decreases the value of the fund. Negative cash values accumulate negative interest at the same rate as they did for positive values along with the rate changes, and generate different accounting entries in OIPA.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • GrossFullWithdrawal Assignment
  • GrossFullWithdrawalWithAllocations
  • ActivityResultsScreen

Tables Modified

  • AsPolicyValue
  • AsPlanFund
  • AsProductFund

Redesign Data Storage for PIT

The data records that are generated for a policy activity's valuation are being consolidated to a more space-efficient design that may decrease overall space consumption by approximately half. The system now stores beginning and ending valuation values for deposits, funds, and policies by eliminating the options that allowed other choices. Configuration has one record to access for an activity's beginning and ending values for each deposit, fund, and policy.

Point in Time (PIT) valuation generates data that provides valuation at the start of an activity and at the end of an activity when money has been added, removed, or moved around the investment options. This data occupied two separate records for each of the fund's deposits with:

  • Deposits summarized up to the fund at start and end of activity
  • Each fund summarized to the policy at start and end of activity

This improvement combines the data into one record for each of the entities; deposits, funds, and policy. For example, if the system valued 3 existing deposits in each of 4 different funds, the system has been recording 24 records for the deposits, 8 summarizing to the funds and 2 summarizing to the policy; a total of 34 records. The improvement reduces the volume to 12 records for the deposits, 4 records for the funds and 1 record for the policy; a total of 17 records. Other scenarios result in a less profound difference, but the overall expected space savings are somewhere less than but close to 50%.

In the past, customers had a choice to record ending valuation records only where money moved or for every fund, deposit, or both. This feature eliminates the former option and all ending valuation data is now stored regardless of money movement affecting the fund's/deposit's value. In addition, the system allowed optional storage at the start of an activity. That option has been removed and valuation at the start of an activity is always recorded. This enhances valuation performance. With this feature, an activity's beginning valuation always starts with the ending valuation of the prior activity. When that ending valuation was recorded, OIPA was required to search all of the valuation history to pick up significant ending fund values.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • WriteValuationElement

Rules Deprecated

  • PointInTimeValuation

New Tables Added

  • AsFundValue
  • AsDepositValue
  • AsPolicyValue

Correct PIT Valuation Issues when Activity is in G/L Pending Status

This enhancement ensures that PIT valuation begins correctly with the ending values of the previous valuation and that removals correctly affect deposits in a LIFO/FIFO order. This enhancement removes the update to ActivityGMT when the activity status changes from Gain/Loss Pending to Active. Activity status updates occur as follows:

  • In scenarios where the activity's status moves from Gain/Loss Pending (14) to Active (01), the current activity's ActivityGMT is not updated.
  • ActivityGMT contains the timestamp value when the activity's status changes to 14.
  • In scenarios where the activity moves to Active (01) without stopping in Gain/Loss Pending (14) or the activity attempts execution and errors, the ActivityGMT is updated with the current timestamp.

Allow Calculated or Configured Values Per Fund

This enhancement allows configuration of values for a fund (for example, calculate the fund’s yield) by using a new rule called, ValuationFields. The configured values are calculated during valuation processing. Values can be calculated and stored at Deposit, Fund, and Policy levels. This functionality is available only when the fund is used by a Plan that utilizes Point In Time (PIT) valuation processing; if the Plan uses Inception Valuation, the Fund’s ValuationFields business rule is ignored. A user can configure the Fund’s calculated values to display on the Values screen or use in Math (with standard Valuation syntax example: Valuation:Fund:Yield ).

The ValuationFields business rule can perform aggregate functions on calculated values. The supported aggregate functions are: MIN, MAX, SUM, COUNT, AVERAGE, and functions, such as GMEAN, MEDIAN, MODE. The ValuationFields business rule is overridden at the Fund level.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

  • ValuationFields

Rules Modified

  • ValuesScreen

 

None

Fund Categorization and Display for Financial Tracking

This enhancement allows the categorization of funds. A user can use this functionality to track investments by categories for the required tracking purposes. If this feature is configured, funds are listed by category on the policy’s Values screen and the processed activity’s Valuation tab.

A new code name, AsCodePlanFundCategory, is used to define the applicable fund categories. After the categories are entered in the AsCode table, they can be associated to the fund in the Rules Palette. A new column, Category, has been added to the AsPlanFund and AsProductFund tables to store this new value. A new Business Rule, FundCategoryOrder, is configured to define the order in which the Categories are displayed in OIPA. The applicable configured categories are displayed on the Values Screen’s Fund Detail and Policy and Asset Graph Sections and the processed activity’s Valuation tab will display the fund categories in the configured order. If the Rule is not present or configured to ‘off’ the funds will display as currently do, with no mention of a category name.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

  • FundCategoryOrder

 

Tables Modified

  • AsPlanFund
  • AsProductFund

Allow Valuation from ScreenMath

This enhancement enables configuration of valuation in ScreenMath to calculate the updated values as of valuation date by supporting the MathValuation MathFunction in ScreenMath. Previously, this functionality was only available in Math. Now, the Valuation can be run for OnLoad, OnChange, and OnSubmit events and if necessary, calculate and view the values before running the activity. The ScreenMath section of Screen Rules can be configured with this enhancement. Valuations run in ScreenMath are not stored in the database.

Display Fund Status

This enhancement supports the display on Values screen, processed Activity screen, and Inquiry screen and supports dynamic calculations of funds in Math Valuation even when the balance of the funds is zero. Configuration controls how long a fund is available for display/calculations based on the amount of time the fund balance has been zero. After the configured duration has passed and the fund balance is still zero, the fund no longer displays or allows calculations of dynamic values. This enhancement has no impact on existing customers who do not want to utilize this new functionality. This requirement is specific to the funds with zero value only. This feature does not affect the funds with non-zero value (positive or negative). The Values/Valuation continue to display as-is unless the user want to use this new functionality.

  • This feature supports tracking by fund and by deposit and is only applicable to Point In Time (PIT) valuation. Inception valuation does not support this functionality.
  • A new field, TrailingCalculationDuration, is introduced on the PlanFund in the Rules Palette Admin Explorer. The configuror needs to enter the number of days the fund should appear on the Values screens even when the balance is zero.

The existing database fund tables have been modified to support this enhancement as follows:

  • AsPlanFund added the column VALUERESETDURATION, which stores the number of days after the value of the fund reaches 0. It should still be displayed on the valuation screen.
  • AsFundValue and AsDepositValue added the column ZEROBALANCEDATE, which captures the date on which the fund value reached zero the last time.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • PlanFund

Tables Modified

  • AsPlanFund
  • AsProductFund
  • AsFundValue
  • AsDepositValue

RemoveByFund Assignment Enhancement to Remove the Specified Bucket

This functionality adds the ability to withdraw money from a specific bucket of one or more indexed funds by using the RemoveByFund assignment. The RemoveByFund assignment allows an activity to remove money from one or more funds without the use of an allocation. The activity can use its configured logic to determine which funds and the amount to remove from each fund. The removal can now target a specific indexed fund bucket.

  • In existing functionality, the RemoveByFund assignment identifies the fund or funds from which to remove money. This is now enhanced by adding a new attribute called BUCKET, which indicates the bucket number from which the money to be removed.
  • In existing functionality, Removals from deposits, if tracking by deposit, continue in LIFO or FIFO order. This is now enhanced such that the cash value of the bucket must be sufficient to cover the removal amount.
Business Rule Changes Database Table Changes

Rules Modified

  • Transaction (RemoveByFund Assignment)

 

None

Dynamic Allocation Percentages for Model Asset Classes

Unlocked Asset Class based models now support dynamically weighing the asset classes themselves in addition to just the funds. The overall Asset Class allocation can be based on the sum of all the funds within the class. When using Asset Class based models in OIPA, even if the funds are unlocked for editing of allocation percentages, the Asset Classes are not editable. The system now supports dynamic Asset Class allocations in addition to dynamic Fund allocations. When creating the model in Rules Palette, the Asset Class can be left empty or zero and when used within OIPA, the system automatically calculates the Asset Class allocation based on the fund entries.

AsCode Changes: A new system code has been introduced to AsCodeModelType with a code value of “03” and description of Unlocked Asset Class. If a model is defined as a typecode “03,” the system allows individual funds to be unlocked and the asset class allocations are not predefined.

Group Customer Enhancements

Allow New Security Group to Access Plans Under a Group Customer

Previously, when creating a new security group, security could only be granted to the plans manually one at a time using the Rules Palette. A new option Grant Access to All Plans has been added to Rules Palette - Security Groups. Selecting this option grants authorization of all of the applicable Plans to the newly added Security Group.

DI Batch Processing in Parallel for the same Group Customer and Profile

This enhancement allows batch records to process in parallel for the same group customer and same profile where the records contained in that batch are identified as ”Independent.”

An Independent record has no dependency between the primary member and its members. If the file is identified as containing “Independent” records, then the files can be processed in parallel. If the file is identified as containing ”Dependent” records, then the files are processed sequentially. To identify whether a file contains “Independent” or “Dependent” records, a new tag is added to the file header record in which Yes/No values can be specified. The default value for the new column “Independent” is 'No.'

Requirements Enhancements

Elements in AddRequirements Resolves the Values from Math Variables and Fields

This enhancement adds flexibility to the AddRequirements business rule to retrieve the requirement name, initial status, and allowance for duplication from the activity's math variables or fields. This can replace complicated logic that determines the requirements to generate into the activity's math section. It allows the AddRequirements business rule configuration to be a boilerplate across multiple transaction configuration provided by activity math and fields. These factors are likely to reduce the scale of maintenance tasks associated to the rule's configuration.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • AddRequirements

 

None

Ability to Override a Requirement at the Product Level

In existing functionality, Requirements could only be overridden at Company, Plan or State levels. This enhancement adds the ability to override Requirements at the Product/Child Product level. Rules Palette has been updated to allow override of Requirement at the product level and OIPA best match logic ensures that the appropriate override level is used.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • Requirement (added Product override level)

 

None

Add Support for CopyBook Use in Requirements

Previously, any CopyBook configuration present in the Requirement rules were ignored by the system. CopyBooks and Functions are now supported in all three Requirements sections, Source, Definitions and Results. In addition, all of the Requirements attached Rules support the CopyBooks.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • RequirementDetail
  • RequirementDefinition
  • RequirementResults
  • AddRequirements
  • AddImpairments
  • CopyToRequirementResultFields
  • CopyToPolicyFields
  • CopyToClientFields
  • CopyToRequirementFields
  • CopyToImpairmentFields
  • MatchRequirementResult
  • ProcessActivities
  • SpawnActivities
  • StatusChange
  • UpdateImpairmentStatus

 

None

Add Client Level Requirements

OIPA now supports Client Level Requirements (without policy/application context). Requirements can be added to a Client by using the Client/Requirement screen or by a client level activity. A new attribute is added to the ClientScreen business rule to indicate whether Client Level Requirements are allowed. The default is No. If set to Yes, and if the appropriate security exists, the Requirement node is available on the Client screen’s left navigation pane.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

  • ClientRequirementScreen

Rules Modified

  • ClientScreen
  • RequirmentDetail (override level)
  • RequirementDefinition (override level)
  • RequirementSource (override level)

 

None

Workflow Enhancements

Create a Workflow when the User Processes a Transaction

In previous releases, the Workflow Task generation was limited to automated processes of cycle, DI, and AsFile post insert processors. This implementation allows user-initiated activity execution to generate Workflow Tasks if additional configuration is provided. The earlier functionality is maintained as the default.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • ValidateExpressions
  • Transaction
  • GeneratePendingRequirements
  • Requirement

 

None

Generate Workflow at Client Level

This enhancement supports the creation of workflow tasks at the Client level. Now, the Workflow tasks are generated through Client-level activities when those activities are run by Cycle, DI, AsFile, or user initiated from the UI.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • ValidateExpressions
  • Transaction
  • GeneratePendingRequirements
  • Requirement

 

None

Segments Enhancement

Specify the Segment using a Unique Identifier

The CreatePolicy rule has multiple purposes. When the specific purpose of an activity with this rule is to copy coverages from a source policy, additional identification is needed to be certain the correct segment data are copied. This enhancement adds the ability to identify the source segment by its unique identifier. This will allow a source policy with one or more segments that have the same name (same segment definition) to identify the source segments that may be copied to the new policy.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • CreatePolicy

 

None

Rates Enhancement

Add More Rate Criteria Columns to Rates

This feature provides the ability to increase the number of rate criteria columns from the default of 10 to the required number of columns based on the business needs. These required number of rate criteria columns are defined in AsCode table of AsCodeRateCriteriaColumns CodeName. It means the AsCodes table defines the maximum number of RateCriteria columns that can exist in the system across all Primary Companies. The system reads this pre-defined CodeValue from the AsCodes table and creates the specified number of rate criteria columns dynamically in the AsRate and AsRateGroup tables.

Rules Palette Enhancements

Rules Palette Release Management Improvements

Release management improvements allow a user to manage the configuration and version history content for each entity that may contain multiple layers of data dependent on the entity's design in OIPA. The IVSCodeRuleType code table is used to encode all the entities that are captured in configuration packages and can be added to a Release Management package. Each encoded entity contains its own content and history syntax. This enhancement extends Release Management/Versioning to the following entities that were not included earlier:

  • ActivityFilters
  • AllocationModels
  • AssetClass
  • AssetClassFund
  • Comments
  • Fund
  • FundPlans
  • FundPlanStatuses
  • FundProducts
  • IntakeProfile
  • Masks
  • PlanBenefitFunds
  • PlanChildFunds
  • PlanStateApproval
  • ProductParentFunds
  • ServiceGroups
  • Workflow Definition
  • Workflow Queue/Role
  • Company
  • Enrollment Transaction
  • Product
  • Rate Group
  • Security Auth Company
  • Security Auth Company Page
  • Security Auth Company Web Services
  • Security Auth Inquiry Screen
  • Security Auth Plan
  • Security Auth Product
  • Security Auth Plan Page
  • Security Auth Transaction
  • System Date
  • Translations

Release Management Utility

This enhancement implements a utility that deploys the OIPA Detached Migration Configuration Package to the target environment. You can run this utility from a command line or an automated script for continuous deployment. The deployment utility loads a Detached Migration Release Package (generated by the Rules Palette) into the target environment by parsing individual files of the package.

Support from Rules Palette to Populate AsFileOutput Table

This enhancement allows the addition of records to ASFILEOUTPUT table by using the Rules Palette. A new node, FileOutput has been added under the Admin Explorer in Rules Palette. Similar to other Admin items, this new option has Check In/Check Out ability, the ability to delete, and so on.

Enhanced AsMapGroup Functionality

The Rules Palette functionality has been enhanced to provide an efficient and user-friendly way to load Map Group, including multiple sets of Map Criteria and Map Values in a single session, using Excel spreadsheets with minimal setup in the Rules Palette. The spreadsheet import option is used to create only a new Map Group record. A user can update an existing Map Group record only through the Rules Palette user interface.

In addition, two new MathVariables, MAPGROUP and MATHGROUPARRAY have been introduced to efficiently retrieve information from AsMapGroup. They can be configured in transaction Math or ScreenMath. MAPGROUP returns a single value and MAPGROUPARRAY can return multiple values based on the parameters.

Client Enhancement

Ability to Identify the Client Screen Context

OIPA screens have the ability to bring the identity of a Client to the screen data. When the user attempts to provide the identity of the client, a Client dialog box is displayed, which enables the user to either find an existing Client or add a new Client. This enhancement provides the Client dialog box and its configuration with additional information about the screen from which the user navigated. This additional information can be used to find an existing client or add a new client and alter its presentation.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

  • ClientActivityLinkScreen

Rules Modified

  • ClientScreen
  • ClientSearchScreen

 

None

Other Enhancements

Name the MultiFields in the Database to Group Fields

Previously, instances of MultiFields were stored in the MultiValueField tables for all objects. When this data was queried from the database, there was no way to know how to group them unless screen rules were read, which was problematic when using APIs. To address this, a new column, GroupName, has been added to the MultiValueField tables. The GroupName column is populated with the Name configured in the MultiField Rule. The Name element in the MultiField rule is now mandatory.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • MultiField Rules

Tables Modified

  • ASACTIVITYMULTIVALUEFIELD
  • ASADDRESSMULTIVALUEFIELD
  • ASAGREEMENTMULTIVALUEFIELD
  • ASAGREEMENTROLEMVF
  • ASCLASSGROUPMULTIVALUEFIELD
  • ASCLASSMULTIVALUEFIELD
  • ASCLIENTMULTIVALUEFIELD
  • ASCLIENTRELATIONSHIPMVF
  • ASPLANSEGMENTNAMECLASSMVF
  • ASPOLICYMULTIVALUEFIELD
  • ASROLEMULTIVALUEFIELD
  • ASSEGMENTMULTIVALUEFIELD
  • ASSUSPENSEMULTIVALUEFIELD
  • ASPLANSEGMENTNAMEMULTIFIELD
  • ASPROGRAMMULTIFIELD

Create Comments from Activities

This enhancement allows the user to create and update entity Comments from an activity through the attached rules.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

  • GenerateComments
  • MaintainComments
  • UpdateCommentsStatus

 

None

Allow Policy Level Activities to Update Disbursement Status

Currently, a disbursement transaction is generated by the system and the status of the activity gets updated to active after the activity is processed. Subsequently, a record for disbursement is generated in the pending status. This enhancement provides the ability to update disbursement status using a policy-level transaction without creating plan or company level transactions. Single or multiple disbursements can be updated.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

  • DisbursementUpdate

 

None

Ability to Access External Application Links from OIPA

OIPA provides the ability to configure third-party links to access third-party client applications, such as Accounting Management Systems, Document Management Systems (DMS), and other external systems that operate outside and independent of OIPA. Users can configure these external application links at the Primary Company level that can be accessed from the Admin menu; and at the context level such as Client, Case, Suspense, Policy, and Group Customer that can be accessed from the left navigation pane.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

  • ExternalLinks

 

None

OIPA Screen Changes to Support Accessibility Requirements

To support the Screen Reader requirement for accessibility, the location of the Save and Cancel buttons has been modified for the following screens in OIPA:

  • Case
  • Client Withholding
  • Policy
  • Policy Withholding

Service Layer Enhancements

Authentication and Authorization

The current security model of Service Layer only allows authentication and authorization using container based security. Now, the authentication and authorization process of Service Layer API is enhanced as per the industry standards that leverages the delegation security model with-in OIPA framework via oAuth 2.0 protocol. It establishes data security at a row level and secures the APIs and Data accessed via Service Layer.

When the Service Layer is registered with the IDP (Identity Provider), CLIENT ID (client_id) and CLIENT SECRET (client_secret) are generated, which can be configured in the Relying Party Server in a secured encrypted file format. The client applications (such as web, mobile) can access the OIPA REST APIs by exchanging the authorization code with authorization server and receiving access token in exchange. The following authorization grant types of oAuth 2.0 GRANT can be used by different client applications.

  • Client Credential Grant: In Machine-2-Machine interaction (a client application authenticating another client application) can use client credential grant.
  • Authorization Code Grant: A web application with a server (back-end channel) can use authorization code grant.
  • Password Grant: A native app (mobile native, android, or iOS apps) can use password grant.
  • Implicit Grant: A single web page application (SPA) that is just browser based and has no server can use implicit grant.

POST and PUT Services

This feature enables third-party integration allowing them to seamlessly connect, collaborate, and exchange data within the OIPA ecosystem. The new service endpoints add PUT and POST capabilities to the following entities:

  • Policy
  • Client
  • Case
  • GroupCustomer (only phone and address sub-resources are supported)
  • Segments
  • Roles
  • Requirements
  • Segment Roles

GET Service Enhancements to Include Plan, Product, and Company

Currently, GET capability is supported for Client, Policy, Case, Client Relationship, and Group Customer entities. This enhancement extends GET capability for the following entities:

  • Plan
  • Product
  • Company

Get Service Enhancement to Include Segment Role

Currently, the service layer GET capability for Policies or Segments is limited and does not return any of the Segment Roles. This enhancement extends the GET capability to include the Segment Roles.

Coherence Cache Refresh Service

Whenever there are any changes to the business configuration, such as business rules, transactions, authorization, and so on in the Rules Palette, it does not get reflected in the application unless the server is restarted. A new web service has been implemented (which can be called within OIPA) to clear the cache after any updates in the Rules Palette. This causes all the logged in users to be logged out. When they login again, the cache is refreshed with the latest data and the changes are reflected in the application.

Fetch Business and Non-Business Date from Calendar

A new REST service has been implemented to retrieve calendars using the GET method.

Admin Console

Improved Overall Navigation of Admin Console System

Previously, Admin Console only supported a Home page and Cycle screen. This release adds new screens and functionality, thus improving the overall navigation of the system.

Read Logging

This feature provides the ability to capture the navigation data for screens that users navigate in OIPA and provides an audit for the screen navigation in the Admin Console. Logging of screen navigation can be set ON or OFF through PAS properties.

User Logs Purging

This enhancement provides users with controls and tools to configure User Logs purging based on certain criteria (for example, by age or last access). A user can run this as a scheduled job or on an ad-hoc basis.