Oracle® Insurance Rules Palette 10.1.2.0 E59346-01

Overview of System Rules

System rules are used to control processing in OIPA. System rules exist as global rules but can be overridden to meet the needs of individual plans. Plan overrides are on both the Global and Main Explorer. Company overrides are only accessable via the Global Explorer pane.  

System rules are configured using the XML Source pane. Visual editing is not available for these rules at this time. An explanation of each rule is provided below.  

Refer to the XML Configuration Guide topic in this help system for a list of all elements, attributes and values needed for System rule configuration. View Business Rules | System Rules. 

System Rules

AutomaticPolicyNumber : This business rule is a system rule that is located in the Global Explorer tab in the Business Rules | System folder. This business rule generates the policy number when a new policy is created.  

AutoProcess: This business rule determines whether activities should process as soon as they are added or when specifically executed. If set to Yes, the AutoProcess button is checked on the Activity screen. 

ChartofAccountsSpecifications: This business rule is used to filter or pinpoint the account/account entry details where the accounting should be performed, since a transaction can have more than one account and account entry details. Multiple suspense accounts can also exist, which in turn can have multiple account entry details.Using this business rule, criteria information for each (dynamic) field on the ChartOfAccountsScreen business rule can be defined. For additional information on the configuration of this rule, refer to Steps to Set-up CoA Criteria.      

ChartofAccountsResults: This business rule is used to write results to the AsAccountingDetailField table. This additional information is client specific and is used for various accounting purposes. For additional information on the configuration of this rule, refer to Steps to Set-up CoA Results.  

ClientAddressTypes: This business rule allows the user to specify which address roles appear in the Address screen's Address Type drop-down box when adding a new address for a client or customer. The address roles in the drop-down selection are driven by the rule's configuration to specify which address is available based on client or customer type. There are several configuration steps that must be accomplished before configuring this rule:

• Define the client types in AsCode using the code name AsCodeClientType. Use the Code Names editor in the Admin Explorer of the Rules Palette to edit codes.
• Define the address roles in AsCode using the code name AsCodeAddressRole. Use the Code Names editor in the Admin Explorer of the Rules Palette to edit codes.
• Configure the Address Screen business rule.
• Add security for Client Address and Group Customer Address under Company Pages.

When configuring the ClientAddressTypes business rule, note the following:

• The CLIENTTYPECODE attribute allows the user to specify the type code for client. The attribute value should be a code from AsCodeClientType.
• The value entered for the <ClientAddressType> element should be an address role code from AsCodeAddressRole. If a client can be assigned multiple address roles, then each role must be defined within its own <ClientAddressType> element.

CompanyCosmetics: This business rule identifies several signification details that apply across a particular company.

• Defines the background to display on all screens except the login screen.
• Identifies the status code(s) that will represent the shadow status code
• Enables or disables the ActivityShading feature.
• Enables or disables the Requirement Shading feature.
• Indicates that a Money data type screen or transaction field will automatically round the entered amount to the specified significant digits of the currency (DisplayRoundPlaces ) using the CurrencyRoundMethod on the AsCurrency table. The <RoundCurrencyEntry> element controls this and accepts values of Yes and No.
  • Yes: value entered is rounded to the significant digits set by the DisplayRoundPlaces column on the AsCurrency table for the given currency code based on that currency’s CurrencyRoundMethod.
  • No: value entered is truncated according to the value set in the DisplayRoundPlaces column of the AsCurrency record.

Computation: This business rule supports scheduled computation. It is executed for each policy or segment defined in the ScheduleValuation rule's Query element array when scheduled computation must be performed. The RULENAME attribute allows a user to give each computation rule a distinguishing name. There are two main sections included in this rule: Input and Output.

The Input section defines a MathVariables section containing standard math variable syntax and operations. The MathStatement element is not supported. The context of the Policy or Segment defined in the ScheduledValuation rule Query element carries over to the named computation rule. Policies will be able to execute loops of their segment records and segments will have access to their related policy records. The Query element can be used to specify the SegmentGUIDs that the Computation rule is executed against in lieu of using segment loops. Copybooks and functions with contextual overrides are supported within the Math syntax, however, the context cannot go below that of the originating transaction (i.e. Plan Activity level).

The Output section defines a Mappings section that contains the named computation fields and their data types and then maps each to a math variable from the Input section. The mapped fields are created on the AsScheduledComputationField table and associated to the record on AsScheduledComputation.

DataDictionaryEnforcement: This business rule can force users to use the Data Dictionary. 

DisbursementNumber : This business rule is used to configure the disbursement number format and sequence. 

DuplicateClient: This business rule defines the criteria identifying a duplicate client. If it does not exist the system will not perform a check for duplicated clients. This rule has a Primary Company context and is extraordinary in that it does not resolve to the global level. The rule supports the resolution of copybooks.

DuplicatePolicy: This business rule can be configured to prevent users from entering policies with the same policy name and/or policy number as an existing policy record in the database. There are two types of messages available: warning messages and error messages. Either of these messages can be assigned to the policy name field or the policy number field to alert a user of an existing policy with the same information (warning) or prevent a user from adding a policy with the same information (error). DuplicatePolicy is currently only configurable via the XML Source Pane. For detailed information on configuring the DuplicatePolicy rule, navigate to the XML Configuration Guide in the Rules Palette help menu and search for Configuration Overview | Business Rules | System Rules | DuplicatePolicy.

EligibleSegmentNamesByPolicyStatus: This business rule is used to make segments selectively available to policies based on the policy status. If a particular policy status is included in the rule only the segment names referenced are available for entry for that policy status. If a policy status is not included in this business rule then all of the plan's segments are available.  

GainLossCalculation: Gain/Loss is the gain or loss incurred by a company when a financial activity buys and/or sells variable fund units. This business rule determines whether or not the system should calculate Gain/Loss for the back-dated transactions. For example, if a transaction processed on a date that is a few days after the effective date of the transaction, the difference in price would be calculated as a gain or loss to the company.  

There are two columns in AsValuation table that are used to store Gain/Loss information.

• ValuationGainLoss: ValuationGainLoss is populated during forward activity processing. 

• GainLossOnShadow: GainLossOnShadow is populated when a financial activity is reversed.  

InterestRateCalculation: This business rule defines the type of interest calculation as well as the specific details of the calculation for fixed funds. Methods of interest rate calculation can be assigned to fixed funds using this rule. In most cases, this rule is overridden on a specific fund level. View interest rate prototype example.

Multifield:  This business rule defines the main combo box where the number of multifields is determined. It is like a copybook, where it can be called from various transactions or screens and there may be many MultiField business rules. It works in conjunction with a Multifield transaction, which calls the Multifield business rule.

PlanOrder: PlanOrder configuration will define the sort order for all screens that have a system defined Plan and Plan Group drop down box. The required element <OrderBy> will be used to define the ordering basis.

For plans, this basis will be AsPlan columns or dynamic plan fields. If a fieldname is used that is not applicable to all plans, then the plans where the field is not applicable will appear alphabetically at the end of the drop down list.

For PlanGroups, the ordering basis will be the PlanName column of AsPlan. An alphabetical sort order will be applied to PlanName.

ORDER is an optional attribute of the <OrderBy> element. The valid values of this attribute are ASCENDING or DESCENDING. An ascending sort order is the default order if the ORDER attribute is absent from the configuration.

The following screens contain a Plan or Plan Group drop down box:

• StateApproval
• OIPA Table Views (Plan Withholding, Plan Fields, Plan Allocations and Unit Value Table)
• PolicySearch
• PolicyScreen
• DisbursementSearch
• Plan Activity
• Company Activity
• DisbursementApproval

PoinInTimeValuation : This business rule is configured to indicate how often valuation records may be saved to the database. Options include writing valuation records at the beginning of an activity and conditions to write valuation records at the end of an activity. It also directs the display of a beginning valuation area on the Valuation tab of the Activity Results screen. 

PrecisionValues : The PrecisionValues business rule provides rounding precision convention (i.e. number of digits allowed after the decimal point) for the display of Unit Values and for the calculation and display of Number of Units. Unit Values and Number of Units are displayed on the following OIPA screens:

• Policy Screen’s Values link
• Activity Result Screen’s Allocation link
• Activity Result Screen’s Valuation link

This rule can be overridden at the company and plan levels.

As of the 9.5.0.0 release, the PrecisionValues rule performs the functionality of the UnitValuePrecision rule, which is deprecated.

RedemptionAmountFormula: This rule defines the calculations that must be performed to determine the redemption fee associated with a withdrawal activity. Redemption fees can be applied to a withdrawal if the deposit has not yet matured at the time of withdrawal. This rule must reference the redemption dynamic fields in the FundScreen rule, using the exact name.

TransactionTimes  : The TransactionTimes business rule controls how an activity behaves based on the time of day it is processed. The rule is attached to transactions and any portion of the rule may be configured as a CopyBook overridden at the Company or Plan levels. TransactionTimes also exists as a System Rule at the Global, Company, and Plan level.

TransactionTimes provides two primary elements for controlling whether or not a transaction may process when added or updated: UpdateDate and Allow. Both elements have a common optional attribute called MESSAGE that displays a configured message if any of the validation criteria fail for the primary element. If the value of the message attribute is equal to an entry found on the translation table, the localized (translated) version of the message is displayed to the user; otherwise, the literal value of the message attribute is displayed. If no message attribute exists, then a system message displays a default error message: Screen alert message is not defined. Unless otherwise indicated, the message appears at the top of the Activity Detail screen. To control the messages that display, the system processes in the order UpdateDate and Allow. Failure alert messages are displayed in the order that the associated validations are processed.        

The TYPE attribute for the Allow and UpdateDate elements determines when the associated validation is applied based on the screen action being performed.

• Add: invokes the validation when the activity is first added to the system.
• Delete: invokes the validation when the activity is deleted.
• Process: invokes the validation when the activity is processed.
• Recycle: invokes the validation when the activity is recycled.
• Reverse: invokes the validation when the activity is reversed.
• Update: invokes the validation when the activity is re-opened from a pending status or during the re-display of the activity when recycling.

Security group Override buttons for the Allow and UpdateDate elements determine which user security groups are exempt from processing the validation. Override buttons are available for Add, Delete, Process, Reverse, and Update. The system checks permissions for the current user’s security group and the list. If the group has the proper override permission checked, then the timing validation is not executed. 

Override Buttons in Transaction Security

The UpdateDate element always targets the EffectiveDate field on the activity. The VALUE attribute identifies the source date value. The source date is always derived from the system date record for the Plan’s MarketMaker calendar. Custom values are not supported. The available date values are:      

• NextSystemDate

• NextBusinessDate

• NextMonthEndDate

• NextQuarterEndDate

• NextYearEndDate.  

Another attribute on UpdateDate is AUTO, which allows a value of Yes or No (the default being No). If the attribute is set to Yes and the validation fails, the failure alert message is displayed and the effective date is changed to the VALUE attribute’s date reference. Clicking OK again on the activity’s detail screen saves the activity and closes the detail screen if there are no alert messages from other timing validations. If the AUTO attribute value is set to No and the validation fails, the failure alert message displays as a confirmation with an OK and Cancel option. Selecting the confirmation’s OK sets the effective date to the VALUE attribute’s date and closes the alert message. If there are no more alert messages, the system saves the activity and closes the activity detail screen. Selecting the confirmation’s Cancel closes the alert message and if there are no more alert messages, returns to the Activity Detail screen for more editing without changing the effective date.      

The Allow element controls whether or not the activity can be saved based on the time date validation criteria. If all the criteria are true, the activity is saved. 

ValuationDetails: This rule allows the configuror to set the proper rounding in valuation calculations for deposits.  

WriteValuationElements: This business rule limits the amount of valuation information that is written. Existing valuation fields can be written to the system and are divided into sections: Policy, Fund, Deposit, and PolicyValues. Inside of these sections the available elements are from a set list. The only exception is the Policy Values section, which can be configured to access any variables from the Policy Values business rule. CopyBooks may be used in this rule. The rule can be overridden by Plan.