What's New in 12.0.0.0
Log to be maintained for both Rules Palette (OIRP) and OIPA Application user
Currently, the Rules Palette does not record the updates or addition made to the Oracle Insurance Rules Palette (OIRP) user. With this enhancement the OIRP Users in History, the OIPA users can access full-featured History maintenance in OIPA/IVS Database that can be used for Audit purposes. The log related to the updates or user addition is recorded in IVSUSERHISTORY and IVSUSERHISTORYDETAILS database tables. The IVSUSERHISTORY table logs the relevant messages and operation codes, signifying the type of change, and the IVSUSERHISTORYDETAILS table logs the relevant field information.
Currently, the Rules Palette does not record the updates to the application user or the addition of a new application user made in the Rules Palette. This enhancement to Application Users in History users can have a full featured History maintenance in theOIPA Database that can be used for Audit purposes. The logs related to application user changes made through the rules palette would now be recorded in ASUSERHISTORY and ASUSERHISTORYDETAILS table. The changes made via the web services which were earlier being recorded in ASHISTORY and ASHISTORYDETAIL would also now be recorded in ASUSERHISTORY and ASUSERHISTORYDETAIL. The ASUSERHISTORY logs the relevant messages and operation codes, signifying the type of change, and ASUSERHISTORYDETAILS table records the relevant field information.
The following table describes the business rules and database table changes as part of this enhancement:
| Business Rule Changes | Database Table Changes |
|---|---|
| None | Tables Modified
IVSUSERHISTORY IVSUSERHISTORYDETAILS ASUSERHISTORY ASUSERHISTORYDETAILS |
Revert HistoryTable Redesign Code and Script to Revert the changes
Currently, in OIPA, after running the migration procedure data from ASCLIENTHISTORY and ASPOLICYROLEHISTORY would be copied to the ASHISTORY Table with HISTORYTYPECODE '01' and '02' respectively. ASCLIENTHISTORYDETAIL and ASPOLICYROLEHISTORYDETAIL would be copied to ASHISTORYDETAIL. With this enhancement, the application will create the entire data of ClientHistory and PolicyRoleHistory data in the ASHISTORY table and detail in the ASHISTORYDETAIL. ASCLIENTHISTORY, ASPOLICYROLEHISTORY, ASCLIENTHISTORYDETAIL, and ASPOLICYROLEHISTORYDETAIL will not be available in the database.
The following table describes the business rules and database table changes as part of this enhancement:
| Business Rule Changes | Database Table Changes |
|---|---|
| None | Tables Modified
ASCLIENTHISTORY ASPOLICYROLEHISTORY ASHISTORY ASCLIENTHISTORYDETAIL ASPOLICYROLEHISTORYDETAIL ASHISTORYDETAIL |
Save OptionText Value available for Combo and Radio Fields
Currently, in OIPA the business rules (BR) which create or update entity-specific data save only the option value for Combo and Radio datatype fields, this is because a rule (CopyTo, for example) can only update one value in the database at a time. If they update the OptionText, the user can view an updated user-friendly description that is not in sync with the field's actual value. If they update the option value, the user will see a user-friendly description that does not reflect the field's value. With this enhancement, OIPA provides flexibility in the configuration to add Option Text along with Option value for Radio and Combo fields across business rules as listed below:
This enhancement enhances OIPA’s capabilities for process automation and adds to configuration flexibility to save OptionText value for combo and radio datatype fields as it keeps the option text value and option value data in sync.
The following table describes the business rules and database table changes as part of this enhancement:
| Business Rule Changes (Option Text) | Database Table Changes |
|---|---|
|
AddAgreementRoles |
None |
| Addlmpairments | |
| AddRequirements (For Requirements) | |
| AddToListBill | |
| AddRequirements (For Transactions) | |
| AddRoles | |
| CopyToAgreementFields | |
| CopyToAgreementRoleFields | |
| CopyToAddressFields | |
| CopyToClassFields | |
| CopyToClassGroupFields | |
| CopyToClientFields (For Requirements) | |
| CopyToClientFields (For Transactions) | |
| CopyTolmpairmentField | |
| CopyToClientRelationshipFields | |
| CopyToCommissionDetailFields | |
| CopyToImpairmentFields (For Requirements) | |
| CopyToPolicyFields(For Requirements) | |
| CopyTolntakeProfileFields | |
| CopyToListBillFields | |
| CopyToPendingActivityFields | |
| CopyToPolicyFields | |
| CopyToProgramFields | |
| CopyToQuoteBenefitFields | |
| CopyToQuoteMemberFields | |
| CopyToQuoteVersionFields | |
| CopyToRequirementFields (For Requirements) | |
| CopyToRequirementFields (For Transactions) | |
| CopyToRoleFields | |
| CopyToSegmentFields | |
| CopyToWithholdingFields | |
| CreateClients | |
| CreatePolicy | |
| CreateSegments | |
| GenerateBillDetail | |
| GenerateCommissionDetails | |
| GeneratePendingRequirements | |
| GenerateSuspense | |
| MaintainComments | |
| MaintainDisbursement | |
| MaintainProgram | |
| MaintainRelationship | |
| ReinstateProgram | |
| SpawnActivities | |
| TerminateProgram | |
|
Business Rule Changes (Option Text Collection) |
|
| Add Roles | |
|
CopyToAgreementFields |
|
| CopyToAgreementRoleFields | |
| CopyToClassFields | |
| CopyToClassGroupFields | |
| CopyToClientFields(For Transactions) | |
| CopyToClientRelationshipFields | |
| CopyToCommissionDetailFields | |
| CopyToImpairmentFields(For Transactions) | |
| CopyToIntakeProfileFields | |
| CopyToPendingActivityFields | |
| CopyToQuoteBenefitFields | |
| CopyToQuoteMemberFields | |
| CopyToQuoteVersionFields | |
| CopyToRequirementFields (For Transactions) | |
| CopyToRoleFields | |
| CopyToSegmentFields | |
| CreatePolicy | |
| MaintainComments | |
| MaintainProgram | |
| MaintainSuspense | |
| ReinstateProgram | |
| TerminateProgram |
AsFile Supports Create Client Requirements
Currently, OIPA supports submitting PolicyClient and Policy requirements using AsFile. With this enhancement, OIPA allows submitting Client Requirements using AsFile and the requirement gets added to the Client without having the need for Policy context.
The OIPA FileReceived Web Service allows an application to send data in XML format and execute core OIPA features against it. A SOAP message is sent by a client application to the FileReceived Web Service. The SOAP message includes two parameters, FileID and XML. The FileID identifies the configuration to use from the AsFile table for processing and transforming inbound XML into OIPA's AsXml. The XML element represents data to be sent to the OIPA for creating objects.
When the AsFile sent is successful, the message will consist of the transformed AsXml. If the request is not successful, then the Web Service response will consist of a SOAP Fault detailing the errors. (i.e. the Output will be xml with error/success message).
SPAWNING MultiValueFields and MultiValueFields GroupName
OIPA was not supporting spawning of MultiField values and passing of MultiField group names currently. However, with this enhancement, OIPA will now allow automated insertion of activities where MultiFields are part of the entry data and users can spawn values to MultiField fields, when any number of MultiField groups are defined within the MultiField rule that is used in the spawned transaction.
The spawning of MultiField is supported by <MultiFields> element, which is the child of <Spawn> element. The configuration for MultiField rule has <Start> and <End> tags that sets the number of MultiField records, which gets displayed on the UI, the Start and End tags will accept literal integer, Auxiliary field or SQL. While spawning MultiFields the Start and End cannot be validated, since it is not possible to run SQL in the child transaction at the time of spawning, so configuror has to take values in Start and End tags of MultiField rule in to consideration while spawning a transaction with MultiField rule. The spawned MultiFields and MultiFields count (Start and End on MultiFields rule) matches, such that there is no difference in spawned MultiField records and displayed Multifield records on UI.
The following table describes the business rule and database table changes as part of this enhancement:
| Business Rule Changes | Database Table Changes |
|---|---|
| Multifield | None |
PRODUCT LEVEL OVERRIDES OF ACTIVITY FILTERS
Currently, ‘Activity Filters’ can be configured for Client, Plan, and Policy Activity screens where the definition can be defined at a Company, Plan, Security Group, and User levels in OIPA. However, with this enhancement, users will now be able to configure Activity Filters at the Product level for Policy and Plan Activity screens. The 'New Activity Filter Wizard' enables users to select 'Product' to create an activity filter at the Product level. Allowing Activity Filters at the Product level will reduce the configuration effort of adding Activity Filters for each Plan.
MONEYTYPE INSIDE THE REMOVEBYFUND DOES NOT APPEAR TO BE WORKING PROPERLY
The cost basis is the original value of an investment that has previously been taxed and is free of further taxation by the taxing authority. The taxable gain is determined as the positive difference between the Policy's cash value and the cost basis and does not change due to fixed interest or market valuation changes. Currently, in OIPA the cost basis is not tracked by the system and can only be tracked through configuration and dynamic fields.
With this enhancement, the configuration instructs the system on how to modify fund and deposit level cost basis data through Assignment and Math configuration within a transaction. Cost basis values progress between Activities and are available in all <Math> configurations following Valuation processing. Additional configuration in the Values Screen allows display of fund level cost basis and taxable gain.
The cost basis values carried from one valuation to another are persisted in records on the AsDepositValue or AsFundValue tables. Differences between an activity's start and end values are persisted in AsDepositValuationEffect and AsFundValuationEffect tables where data for those tables normally store those changes to a fund's value. For backward compatibility, null values are considered as 0.
Valuation: The Valuation data will contain cost basis information. This information will be equal to the ending values of the immediately preceding Activity's ending cost basis information. Valuation data is made available to an Activity's Math, Post Assignment Validate Expressions, Screen Math, Inquiry Screen, Values Screen, and Scheduled Valuation through the existing configuration where valuation is performed.
Assignment: Assignment configuration includes a new attribute to provide values for adding and removing value from the cost basis data, in the assignment's <MoneyType> element. The new attributes will reference "collection" variable types whose contents will provide the amount of change to apply to each fund or deposit.
ApplyByFund: Adds money to a fund so all manipulation of cost basis values should be positive values. Refer to the updates in the ApplyByFund Elements And Attributes.
The following table describes the business rules and database table changes as part of this enhancement:
| Business Rule Changes | Database Table Changes |
|---|---|
|
None
|
ASDEPOSITVALUE ASDEPOSITVALUATIONEFFECT ASFUNDVALUATIONEFFECT ASFUNDVALUE |
Setup ReassignAllocations BR to correctly persist data written by WriteDefaultAllocations
Currently, OIPA allows an activity that invests money into a Policy's funds to also update a Policy's allocation upon completion of the activity. This feature was limited to investments or the application of money and was not available for simple withdrawals or the money removal side of transfers. This enhancement fixes that limitation by adding configured behavior to the ReassignAllocations and WriteDefaultAllocations business rules allowing the withdrawal or removal of allocation data to be persisted to a Policy's allocation type. This also applies to the more complex transfer allocation scenario where fund withdrawal and money application information are provided by the Allocation data.
The ReassignAllocations business rule prepares the allocation data for potential update of a Policy Allocation using the optional WRITEALLOCATIONSET configured attribute. The WriteDefaultAllocations business rule optionally completes the update to a specific Policy allocation type with the prepared allocation data.
AllowEvents Element for Default Allocations
Currently, when using the TransactionAllocationScreen there is no input Allocation record in the case where the allocation may be optionally derived in math configuration and populated in ReassignAllocations. This enhancement will introduce the ALLOWEVENTS element that will allow the configuror to specify whether or not to load the default allocations. If the option is Yes, then the default allocations are loaded, that is, if the condition is true. If the option is No, then default allocations are loaded independently of the condition.
ASFUNDVALUE to Support Greater than 2 Decimal Places
Currently, OIPA supports assignment of investments in funds that match the scale of the funds' currency; i.e. up to 2 decimal places for US Dollar which is in line with the dollar standard (100 cents in 1 dollar). With this enhancement, supports a conversion scenario from a non-OIPA administrative system to OIPA where currency rounded cash values would itself create a financial impact on future interest or credit valuation or unit purchases.
The following table describes the business rules and database table changes as part of this enhancement:
| Business Rule Changes | Database Table Changes |
|---|---|
| None |
ASFUNDVALUATIONEFFECT ASDEPOSITVALUATIONEFFECT |
GroupCustomerSearchScreen Configuration Supports Multiple Typecodes
Currently in OIPA, the GroupCustomerSearchScreen supports only one TypeCode which is ‘20’, which corresponds to Group Customer. However, with this enhancement, OIPA will now support multiple customer types, each with its own set of search criteria and results. This will provide the flexibility to either configure multiple typecodes for multiple group customer types or the screen can just be configured without a TypeCode if only TypeCode 20 is being used for Group Customers. The user will also have the ability to search for all group customers in the database by using the All Customer Type selection that is supported by the Tyepecode '*' where the search fields and result columns would be common for all customer types.
Multifields Business Rule Supports Dynamic Value
Currently, in OIPA the multifield rule configuration defines a set of one or more fields and a number range, that allows the user to select the number of fields to be displayed on the screen. The number range is defined in the <Start> and <End> tags of the multifield configuration. In some scenarios, the configurer cannot define the <Start> and <End> tags in advance, the count of repeating fields required is dependent on the set variables, fields, or derived values on the OIPA screen. With this enhancement the Multifields business rule configuration now supports dynamic values to be defined from the set variable from screen math or fields to generate the number range to display the number of multifield rows on the screen, these supplied values can be supplied can either be assigned from the parent transaction rule configuration where the multifield element is configured or as per the existing functionality i.e. from the Multifield rule configuration.
Improved the Add Claim Field Functionality
Currently, in OIPA, users do not have the ability to configure the Claims functionality. This enhancement of the claims process in OIPA is made more functional and seamless, allowing users to expand the claim functionality and configurators to configure dynamic fields. As OIPA's claim functionality has been enhanced and it now caters to dynamic fields and optionally multifields. A new screen business rule, ClaimScreen has been introduced to support the dynamic claim fields. The existing attached business rules, CreateClaim and CopyToClaimFields have been enhanced to support dynamic fields and optionally multifields. The UpdateClaimStatus business rule can now update multiple claims with the use of collections.
The following table describes the business rules and database table changes as part of this enhancement:
| Business Rule Changes | Database Table Changes |
|---|---|
|
ClaimScreen CreateClaim CopyToClaimFields UpdateClaimStatus |
ASCLAIMFIELD ASCLAIMMULTIVALUEFIELD ASCLAIMHISTORY ASCLAIMHISTORYDETAIL |
Override business rules to support policy context at the Product-state level
Currently, OIPA allow business rule supports Product override, but not a Product/State override. With this enhancement OIPA business rules configuration uses the existing configuration in the OIPA system while defining products/plans. Rules Palette has been updated to allow override of business rules at the product and state level and OIPA best match logic ensure that the appropriate override level is used.
DoSegmentRecalculations attached rule to process all the segments on the policy
Currently the attached DoSegmentRecalculations business rule provides the order in which the Segments of that policy should be processed. With this enhancement, OIPA adds the ability to retrieve the newly calculated SEGMENTFIELD value in Math when the DoSegmentRecalculations Rule loops through multiple Segments. A new attribute to the Math Variable TYPE SEGMENTFIELD/SEGMENTGUID indicates whether the value should be retrieved from memory or database. If memory is configured and nothing is in memory, it behaves the way it does in existing functionality and it looks for the value in database, if a value does not exist in database as well it returns null it will not error.
