Overview of Attached Rules
Attached rules are rules that are attached to transactions or requirements for supplemental processing. On the Main Explorer they are listed under the transaction's or requirement's Attached Rules node, and, for transactions, are also added to the TransactionBusinessRulePacket.
The XML Configuration Guide contains a detailed explanation of the elements, attributes and values used to configure these business rules. Select Help from the Main Menu and open the XML Configuration Guide. Attached Rules are located in the Business Rules | Attached Rules folder.
Attached Rules
Activity Summary: The ActivitySummary business rule drives the Activity Summary screen. This rule allows for the configuration of the summary screen and summary groups including activity fields and math variables, allocation changes and activity results.
This rule should be attached to a transaction but not placed in the TransactionBusinessRulePacket.
AddImpairments: This business rule is attached to a transaction in order to add Impairments based on the configured Impairment criteria.
AddRequirements: This business rule is attached to a transaction or requirement in order to add requirements based on the configured requirement criteria.
Add Roles: This business rule adds existing clients in the database to new roles on an existing policy or segment. This rule can only be attached to a policy-level transaction and can only be used to add roles to the policy on which the activity is being processed. View Add Roles prototype.
ConfirmationScreen : This business rule should be attached to a transaction if a Confirmation screen is required. It should NOT be placed in the TransactionBusinessRulePacket. The rule adds a Confirmation screen to the activity it is attached to and displays the screen immediately after all validations have been processed, the activity has been saved, and the user clicks the OK button on the Activity Details screen, or on the Verification screen.
The screen provides custom information to the user. Title, message and field sections are available for configuration. The title is displayed as the heading for the Confirmation screen. If a title is not configured, then the policy number and transaction name will display. Messages can be static or dynamic. Dynamic messages will include substitution fields only from the main body of the transaction. Only static messages will be translated. Fields must be configured within the main body of the transaction to be available for display on the Confirmation screen. Multi-currency support is available for fields.
A confirmation number can also be configured for tracking purposes. The originating activity's confirmation number should be configured using an Identifier field and an Identifier math variable should be used to generate confirmation numbers for spawned activities.
Refer to the Confirmation screen prototype for a detailed explanation of how to configure this screen.
CopyToAddressFields: This business rule allows one or more math variables to be copied from an activity to one or more address fields, upon processing the activity with this rule attached.
CopyToAgreementFields: This business rule is used to copy one or more activity values to one or more agreement fields. A MathVariable or a field name can be used to place a single value into an agreement field and a collection can be used to place multiple values onto multiple agreements. The values that are copied to agreement fields will be written to the corresponding columns of the AsAgreement or AsAgreementField database tables.
In addition to field values, CopyToAgreementFields will automatically update the OptionText of combo box and radio button fields.
This rule must be listed in the TransactionBusinessRulePacket.
CopyToAgreementRoleFields: This business rule is used to copy one or more activity values to one or more agreement role fields. A MathVariable or a field name can be used to place a single value into an agreement role field and a collection can be used to place multiple values onto multiple agreement roles. The values that are copied to agreement role fields will be written to the corresponding columns of the AsAgreementRole or AsAgreementRoleFields database tables.
In addition to field values, CopyToAgreementRoleFields will automatically update the OptionText of combo box and radio button fields.
This rule must be listed in the TransactionBusinessRulePacket.
CopyToClassFields: This business rule is used to copy values from one or more activity fields to one or more class fields. The values that are copied to class fields will be written to the corresponding columns of the AsClass or AsClassFields database tables.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToClassGroupFields: This business rule is used to copy values from one or more activity fields to one or more class group fields. The values that are copied to class group fields will be written to the corresponding columns of the AsClassGroup or AsClassGroupField database table.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToClientAltIdFields: This business rule is used to copy values from one or more activity fields to one or more client alternate ID fields. The values that are copied to client alternate ID fields will be written to the corresponding columns of the AsClientAltId database table.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToClientFields: This business rule is attached to a transaction or requirement to allow one or more math variables to be copied from an activity to one or more client fields upon processing the activity to which the rule is attached.
CopyToClientRelationshipFields: This business rule is used to copy values from one or more activity fields to one or more client relationship fields. The values that are copied to client relationship fields will be written to the corresponding columns of the AsClientRelationship or AsClientRelationshipField database tables.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToGroupCustomerFields: This business rule is used to copy values from one or more activity fields to one or more group customer fields. The values that are copied to group customer fields will be written to the corresponding columns of the AsGroupCustomer database table.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToIntakeFileFields: This business rule is used to copy values from one or more activity fields to one or more Data Intake file fields. The values that are copied to Intake File fields will be written to the corresponding columns of the AsIntakeFile or AsIntakeFileField database tables.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToIntakeProfileFields: This business rule is used to copy values from one or more activity fields to one or more Data Intake profile fields. The values that are copied to Intake Profile fields will be written to the corresponding columns of the AsIntakeProfile or AsIntakeProfileField database tables.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToIntakeRecordFields: This business rule is used to copy values from one or more activity fields to one or more Data Intake record fields. The values that are copied to Intake Record fields will be written to the corresponding columns of the AsIntakeRecord or AsIntakeRecordField database tables.
When this business rule is attached to a transaction, it will also need to be added to the corresponding TransactionBusinessRulePacket business rule.
CopyToPendingActivityFields
This business rule can be used to update activity field and withholding field values in policy activities that have not yet become active on the system and have not processed the transaction math. A single activity or withholding field can be updated or multiple fields may be updated.
Only policy activities that are in a pending status are eligible to have field values changed. Pending statuses are defined as activities that have not yet run the Transaction Math section or any attached rules, typically statuses '02' and '09' (Pending and Pending with errors respectively). Plan level activities will not support the undo/redo processing of the CopyToPendingActivityFields rule.
If the updating activity attempts to update the fields of a target activity that is not in a pending status or if the updating activity and target activity are one and the same, a business error will be generated and activity processing will halt.
The <Test> element within <Tests> can be used to set conditions for the update of the activity or withholding fields of a policy. When multiple test conditions are configured to determine if a pending activity or activities' fields should be updated, all conditions must be met in order for the update to be made.
CopyToPolicyFields: This business rule is attached to a transaction or requirement to allow one or more math variables to be copied from an activity to one or more policy fields. If the fields are displayed on the Policy screen, the values will be viewable.
CopyToProgramFields: The CopyToProgramFields business rule is used to update program fields. The update capability of the rule is restricted so that fixed program fields and program status may not be updated. The rule may only be attached to a program transaction. Updates are limited to dynamic disabled program fields.
As a best practice, the ProgramGUID should be referenced in the configuration so that the GUID can be used as an identifier. An example of this is shown below:
<MathVariable VARIABLENAME="ProgramGUID" TYPE="EXPRESSION" DATATYPE="TEXT">Program:ProgramGUID</MathVariable>
CopyToRequirementFields: This business rule is attached to a transaction or requirement to allow the results of the activity’s math calculations to write out to a defined group of RequirementGUIDs.
CopyToRoleFields: This business rule is attached to a transaction and allows one or more math variables or activity fields to be copied to one or more specified RoleFields, upon processing the activity to which the CopyToRoleFields business rule is attached. The rule allows updates to multiple roles. This rule must be listed in TransactionBusinessRulePacket.
CopyToScheduledValuationFields: This rule will create fields in the AsScheduledValuationField. It allows a ScheduledValuation activity to store valuation data from various sources in one convenient location. This rule, though attached to a transaction, does not appear in the TransactionBusinessRulePacket business rule.
CopyToSegmentFields: This business rule is used to copy one or more activity values to a segment field. A MathVariable or a field name can be used to place a single value into a segment field and a collection can be used to place multiple values on multiple segments. This rule must be listed in the TransactionBusinessRulePacket
CopyToWithholdingFields: This business rule loads the withholding fields from the database and updates them based on the values specified in the business rule. The <From> element identifies the math variable or field where a value is being obtained. The <To> element identifies the field that is being updated. Only one set of withholdings can be updated by a rule.
The <Test> element within <Tests> can be used to set conditions for the update of the Withholding fields of a policy or client. When multiple test conditions are configured to determine if a pending activity or activities' Withholding fields should be updated, all conditions must be met in order for the update to be made.
CreateAdditionalRates: This business rule adds a new rate to AsRate using criteria specified in the plan- or company-level transaction to which it is attached. A Rate Table (a set of Rate Groups with the same name) is specified in the <RateDescription> element of this rule, and the Rate Table must have a consistent set of criteria across all of its data. There may be anywhere from zero to 10 criteria, and only Rate Tables that contain one Rate Group are eligible for the addition of new rates. If the Rate Table does not exist or has multiple Rate Groups, a business error will be generated. Any number of Rate Sets may be added to a Rate Table by using the repeatable <CreateRate> element. The exact rates to be added are specified by a math variable, the name of which should be the value of CreateAdditionalRates' <RateCollection> element.
CreateClientAddress: This business rule is attached to a transaction to identify the client or array of clients that will receive the address information captured by the transaction. This should only be used with non-reversible transaction types.
CreateClients: This business rule allows the insertion of new client records from an activity, as well as the creation of relationships, class memberships, addresses and activities related to the new clients being created. Activities created for new clients can be inserted into activity sequencing.
CreateRates: The CreateRates business rule creates a rate group data table record and the rate data table records to go with it. Activity processing is expected to add rates by a forward processing activity. The CreateRates rule applies only in special situations and is not used for valuation rates. This rule is only available to plan level transactions in Primary or Subsidiary companies.
The CreateRates rule must be attached to a transaction and be listed in the TransactionBusinessRulePacket of the transaction.
CreatePolicy: The business rule is introduced to provide the ability to configure the activity-based creation of a new policy based on events occurring on an existing policy. One or more policies may be generated from a single source policy, although only one new policy per activity will be supported. All policies will be created in a pre-issue status pending user review. CreatePolicy business rule will be attached to a non-reversible activity and must be listed in the TransactionBusinessRulePacket.
For Benefit Split, this rule should allow for Benefit fund GUID/amount collection. A target benefit split type code should be specified. The rule should allow a “Copy Source” operation that will copy a specified segment’s activity benefit split based on type code. This feature only applies if the COPYSOURCE attribute of the Segment parent element is set to “Yes”. If no source benefit split record exists, then no error is given and no benefit split record will be created for the created policy segment.
CreateSegment: This business rule creates one or more new segments on a policy when attached to a transaction and specific expressed conditions are satisfied. This rule must be listed in the TransactionBusinessRulePacket. View Create Segment prototype.
For Benefit Split, the rule should allow for Benefit fund GUID/amount collection. A target benefit split type code should be specified. Benefit fund GUIDs are specified as this writes directly to AsBenefitSplit and there is no relation logic to look them up from the Parent fund.
CycleProcessBehavior: The CycleProcessBehavior business rule is used to determine how errors are handled during cycle processing. The business rule allows users to stipulate conditions for retrying a transaction that has failed during cycle processing, as well as the number of times the system should automatically retry it. The <Halt> element in the rule's configuration specifies a condition for ending or continuing the cycle, while the <RetryIterations> element specifies the number of retry attempts.
CycleProcessBehavior is available for plan, policy and client transactions. When this rule is present, the system will automatically retry the activity that has returned an error. If the system performs the specified number of retry attempts without success, the transaction will remain pending.
DeliveryRequirements: This business rule defines the fulfillment criteria of the activity’s requirements via its date fields. The rule must be attached to a transaction and needs to be in the TransactionBusinessRulePacket of the transaction.
DisbursementUpdate: This business rule is attached to a plan level transaction and will update the status of any pending disbursements identified by the transaction to an active status. The rule allows for a change in disbursement status from pending to active only. Accounting can optionally be triggered by this rule. Disbursement Accounting is defined by the Chart of Accounts Entry screen. Accounting is invoked during the process of moving a pending disbursement to active. Reversal processing is handled by the policy or client level activity reversal. Reversing the plan level activity will not undo the changes to the disbursement or its accounting.
DoBenefitSplitChange: The DoBenefitSplitChange will allow an activity to redefine/restructure the benefit split records on any given segment to align with a specified parent fund allocation. This rule writes the updates from one segment’s benefit split records to AsBenefitSplit. Segment allocation records do not need to be built as a result of this rule. An AssignmentMethod element will indicate the type of action the rule is to perform. These are not assignment types, just general directions of money movement.
DoSegmentRecalculations: This business rule can be attached to a transaction that specifies the names and execution orders of segments attached to a policy. When the rule is processed, the segments for the current policy will be loaded and calculated in the order specified.
For Benefit Split, the Activity GUID must be carried to the benefit split records created from the segment calculate general rules.
ExternalProcess: The ExternalProcess business rule provides the capability of calling custom Java code in order to facilitate greater functionality. A common use may be to generate documents in a manner specific to the document generator being employed. This is an attached rule and must be listed in TransactionBusinessRulePacket.
This business rule should be used in conjunction with the GenerateDocument rule.
FundListForAllocation: This business rule is introduced to define controls for the fund dropdown on the Activity add/edit screen. It should not be included in the TransactionBusinessRulePacket.
Generate Document: This business rule describes the document that needs creation upon the execution of a transaction. Multiple output file formats are supported and can be created using a single rule. This rule is not included in the TransactionBusinessRulePacket. This business rule should be used in conjunction with the ExternalProcess rule. View Generate Document prototype.
GeneratePendingRequirements: GeneratePendingRequirements defines the comparisons of requirement criteria to math variable values. If all conditions identified in the rule are true, then the requirement is generated. This rule must be used in conjunction with DeliveryRequirements and TransactionBusinessRulePacket.
GenerateSuspense: This business rule is used to create a suspense record when a transaction with this attached rule is processed.
MaintainSuspense: This business rule allows suspense field values to be changed and accounting generated through a collection of multiple suspense tickets. This rule is attached to a transaction and must be listed in the TransactionBusinessRulePacket.
MatchRequirementResult: This business rule is attached to a requirement to match a specified requirement result with the requirement to which this rule is attached.
PostAssignmentValidateExpressions: This rule processes after the math and assignment processing has completed and can be configured to halt the continued processing of an activity in Pending or NUV Pending status. If configured to do so, error messages can be displayed that can be overridden or canceled by the user. Warning messages, which will not halt processing, can also be configured. If post assignment math is run multiple times in an activity with this attached rule, then the value from the last time run is the one that is logged.
A math variable (from the MathVariables section) or Field substitution may be made in the validation message. The only supported data types for substitutions are ‘TEXT’, ‘INTEGER’, ‘CURRENCY’, ‘DATE’ or ‘DECIMAL’. Therefore any other data types will need to be converted to TEXT, INTEGER or DECIMAL before being passed into the validation message. Special characters such as ‘$’ or ‘%’ need to be added in the validation message and will not be included in the substitution.
Refer to the ValidateExpressions description below for additional information on validation message substitutions.
PriceCorrection: This rule will accept fields, multi-value fields or math variables as input. The PriceCorrection business rule must be specified in the TransactionBusinessRulePacket and can only be attached to transactions that are configured within Primary Companies’ plans. When attached to a Primary Company level transaction, the PriceCorrection business rule performs the following two tasks:
- Updates records in the AsNetAssetValue database table to reflect the corrected Base, Bare, and/or Offer Unit Value(s). As long as funds are configured within the price correcting activity’s Field(s), MathVariable(s) or referenced MultiField business rule, and as long as at least one of the Unit Values for any identified fund is different from the price used in the original activity, then the Unit Value(s) for that fund will be updated accordingly. If the Unit Values for a fund are not different from the original set, then the fund’s price will not be updated and the rule will prevent the activity from searching for policies affected by the price correction.
- Searches for policies affected by the price correction. These policies have processed activities with the following criteria:
- Price Correction Indicator set to “Yes”
- have been selected as those requiring price correction (i.e. contained within <FundGUID> element of the PriceCorrection business rule)
- have used the unit value that is being corrected as of the same date as the price correction date (i.e. date contained within <EffectiveDate> element of the PriceCorrection business rule).
Once all affected policies are identified, the rule inserts (spawns) a high Processing Order “dummy” activity into the affected policies. The effective date of the "dummy” activity is the effective date of the earliest activity (if more than one) that had fund movements, for each of the affected policies. Once processed, the “dummy” activity reverses all subsequent activities, so that they can be re-processed with the corrected set of unit values.
Each plan that has policies within a Primary Company and has unit values capabilities must have a “dummy” transaction configured. Each one of these Policy level “dummy” transactions has to have the same name. If the “dummy” transaction is not configured on an affected policy’s plan, then a system error will be generated when the PriceCorrection activity is processed.
The Price Correction activity that this rule is attached to will be able to update all fund levels, including Benefit Split when the first task listed above is performed. However, if Benefit Split Allocations were calculated using means other than activities (e.g. via CalculateGeneral business rule, invoked from a Segment screen), then the PriceCorrection business rule will not be able to identify the affected policies. Therefore, it is a recommended best practice to use activities for initial and all subsequent Benefit Split Allocation calculations.
Point-in-Time functionality will affect how the PriceCorrection business rule searches for the affected policies.
ProcessActivities: This business rule is attached to a requirement to set conditions for the automatic processing of activities.
ProcessRequirements: This business rule is attached to a transaction in order trigger the processing of requirements. This rule supplements the ability of requirements to schedule execution. Processing a transaction with this rule attached will trigger the processing of requirements that are not necessarily scheduled to be executed at the given moment.
QuoteScreen: This business rule is attached to a transaction to enable display of a Quote button on the Activity Detail screen. The Quote button allows users to view activity results prior to actually processing an activity. This button is only available for Client and Policy level non-document transactions – including any lower sub-categories of these transaction types (e.g. Policy-Financial-Reversible-Nonreversing, Policy-Financial-Nonreversible-Nonreversing, Client-Financial-Nonreversible-Nonreversing).
Transaction configuration can now define the buttons available to the Activity Detail screen. When the Quote screen is attached to a transaction, the Quote button by default is available. If all buttons available to the screen are not needed, the <Button> element (a sub element of <Buttons>) can be used in transaction XML to define the available buttons. If the button configuration is absent from the transaction configuration, then all buttons will be available by default. For more information on configuring buttons on the Activity Details screen, see the Buttons Element page in the XML Configuration Guide—navigate to Transaction Rules | Transaction Elements | Buttons Element.
The QuoteScreen rule and the VerificationScreen rule are mutually exclusive. If both the Quote Screen and Verification Screen are attached to a transaction, only the Verify button is available on Activity Detail.
Activities can be added from the Quote screen. An Add New Activity link will display in the Quote window if the following QuoteScreen configuration exists:
- QuoteScreen business rule contains a <Transactions> element with at least one transaction that can be added from the Add New Activity link.
-
EligibleTransactionsByPolicyStatus business rule (policy level activities only) contains at least one transaction for the current Policy status, that is also configured within the <Transaction> element of the QuoteScreen business rule.
-
User has appropriate OIPA Security role.
ReassignAllocations: ReassignAllocations business rule is used to override existing activity allocations. This is useful when the end user is not allowed to select allocations or with automated activities where the user is not involved in an on-line experience with the activity. Allocation records are created when this business rule is processed. The Allocation records contain the funds the money is moving into or out of.
To support Benefit Split functionality, this rule can be modified to accept a collection of FundGUID/Percent or Amount value pairs in lieu of the standard SQL in the <To> element. The COLLECTION attribute holds a math variable collection of either FundGUID/Percent or FundGUID/Amount value pairs. ALLOCATIONMETHOD is an attribute that holds a literal value or variable value (i.e. code value) indicating the allocation method to use. Amount, indicated by the code value "02", is the only value allowed.
ReassignBenefitSplit: This rule deactivates the current active benefit split record and activates the future record. The rule writes to AsBenefitSplit. The <From> element specifies the source BenefitSplit type code of the allocation to activate. Generally "51" is the Type Code that is used here. The <To> element specifies the target BenefitSplit type code for the allocation. Generally "05" is the type code used here. The “From/To” elements should be in repeatable groups that allow a single activity to update multiple Segment Benefit Splits. Each group should identify the related GUID for the policy's active benefit split records to be modified.
RolesExist: This business rule is used
primarily to validate whether or not the specified role codes exist on
the policy, using role code configuration. Apart from that, this business rule
is used to verify that certain specified policy or segment role fields are
ScheduledValuation: This business rule allows the transaction to which it is attached to execute valuation or scheduled computation for all policies returned by a query contained within the rule without adding policy financial activities to those policies. It is best suited for plan level transactions. The rule also includes switches to include the PolicyValues business rule during the valuation process, write deposit information and what left-over processes from prior attempts may be deleted.
The <Computation> element indicates that scheduled computation should be performed, instead of scheduled valuation. The value of Policy or Segment within the element tells OIPA the type of computation to perform. The RULENAME attribute of this element indicates the rule that should be used to drive the scheduled computation process.
View the Scheduled Valuation prototype or the Scheduled Computation prototype.
ShadowPendingActivities: This business rule is used to delete an activity from the Activity screen when the specified condition is satisfied. More than one activity can be deleted, but the activity must be in pending status. The activity will appear shadowed once processed. OIPA will give an error if the user tries to delete an activity that is not in pending status.
Only activities of the same type can be deleted. For example, the rule attached to a policy activity can delete only pending policy activities.
SpawnActivities: This business rule is attached to a transaction or requirement in order to spawn an activity from the transaction or requirement.
StatusChange: This business rule processes any status changes on a policy bringing the policy up to date. Processing the transaction or requirement to which this business rule is attached will change the status of the policy to the one specified in this rule. For example, changing the policy status from lapse to loan repayment.
TransactionBusinessRulePacket: This business rule controls the order in which the rules attached to the transaction are processed.
TransactionCosmetics: This business rule controls the icon, button and reverse icon for the associated transaction. It also sets amount values from the transaction to display on the Activity screen. A tool tip element can be used to provide custom details to the user when the cursor hovers over icons in OIPA.
UpdateRoleStatus: The UpdateRoleStatus business rule allows a transaction to update the status of multiple roles. The update is not necessarily to the same status. Each status on a role is updated to its own value. The system supports three status code values from AsCodeRoleStatus:
-
01: Active
-
98: Inactive
-
99: Deleted
The OIPA implementation may develop more role status codes as needed. The rule is attached to a transaction and must be listed in TransactionBusinessRulePacket.
ValidateExpressions: The Validation section in a screen rule or a transaction supports the ability to configure hard edits and pop-up error or warning messages. The purpose of this business rule is to identify errors, and to fix and allow overrides. This business rule is overridden at the transaction level.
ValidateExpressions can also enable the ability to override errors from an activity's Verification screen by giving the OVERRIDABLE attribute of the <Expressions> element a value of "Yes". If errors are configured to be overridable, expressions defined as warnings will not have the option to be overridden.
A math variable (from the MathVariables section) or Field substitution may be made in the validation message. The only supported data types are ‘TEXT’, ‘INTEGER’, ‘CURRENCY’, ‘DATE’ or ‘DECIMAL’. Therefore any other data types will need to be converted to TEXT, INTEGER or DECIMAL before being passed into the validation message. Special characters such as ‘$’ or ‘%’ need to be added in the validation message and will not be included in the substitution.
Formatting of substitutions will not be handled except with data type ‘CURRENCY’. If a ‘CURRENCY’ math variable is used, then all that will display is the decimal portion without the currency code. The currency code should be added in the configuration. This can be accomplished by adding a math variable with the currency code and using it in the validation such as $$$CurrencyCode$$$.
Some validation messages need to reference the actual value of a math variable. In those situations, the ValidateExpressions or PostAssignmentValidateExpressions business rule may be attached to a transaction, with the math variable referenced in the Expression surrounded by $$$.
<Expression TYPE="ErrorOnTrue" OVERRIDABLE="Yes" MESSAGE="Owner’s Age of $$$OwnerAgeMV$$$ must be less than or equal to $$$MaxAgeNY$$$">OwnerAgeMV > MaxAgeNY And IssueStateCodeMV = '32'</Expression>
In the expression above, if the OwnerAgeMV was set to 82 and MaxAgeNY is 80, then the validation message would appear when the lightning bolt icon is clicked on the Activity screen. The message would read, “Owner’s Age of 82 must be less than or equal to 80."
Current V9 configuration supports assigning a math variable using a prefix plus a value from major system area such as Policy, Plan, Activity or Client in segment or transaction and activity Action/Events processing. Instead of assigning a prefixed value to a math variable (Plan: MinimumFaceAmount for example), the prefix and value may be used directly in the validation message.
A prefixed value can also be referenced in a validation message. If a face amount minimum limitation defined on a certain plan as $100,000 needs to be exposed through a message, then the configuration would read:
<Expression TYPE="ErrorOnTrue" OVERRIDABLE="Yes" MESSAGE="Minimum Face Amount for this plan is $$$Plan:MinimumFaceAmount$$$>FaceAmountMV < MinimumFaceAmountMV></Expression>
VerificationScreen: This business rule is attached to a transaction to enable display of a Verify button on the Activity Detail screen. The Verify button allows users to display a separate Verification screen with custom information. The fields displayed on the Verification screen are configurable to include any field or any math variable that would be available in activity results had the activity been processed. The screen will also optionally display activity allocations, requirements and error messages. The SHOWORIGINAL attribute in the rule controls whether original allocations display along with the final allocations.
Transaction configuration can now define the buttons available to the Activity Detail screen. When the Verification Screen is attached to a transaction, the Verify button by default is available. If all buttons available to the screen are not needed, then the <Button> element (a sub element of <Buttons>) can be used in transaction XML to define the available buttons. If the button configuration is absent from the transaction configuration, then all buttons will be available by default. For more information on configuring buttons on the Activity Details screen, see the Buttons Element page in the XML Configuration Guide—navigate to Transaction Rules | Transaction Elements | Buttons Element.
The VerificationScreen rule and the QuoteScreen rule are mutually exclusive. If both the Quote Screen and Verification Screen are attached to a transaction, only the Verify button is available on Activity Detail.
OIPA users are able to override errors from the Verification screen. The ability to do so requires that the OVERRIDABLE attribute of the <Expressions> element in the ValidateExpressions rule be given a value of Yes.
The Verify button is only available for Client Financial and Policy Financial transactions – including any lower sub-categories of these transaction types (e.g. Policy-Financial-Reversible-Nonreversing, Policy-Financial-Nonreversible-Nonreversing, Client-Financial-Nonreversible-Nonreversing).
WriteDefaultAllocations: Allocations define how money is applied to a policy. The WriteDefaultAllocation business rule instructs the system to write/copy the default allocations, which are pre-defined funds, to the AsAllocation table for both policy and plan levels. It is customary to establish a level default allocation. The allocation specified in this business rule is used if no other allocation instructions are given or if transaction processing dictates that all funds are deposited into a certain fund or set of funds.
This business rule allows an activity to insert/update default allocation records. It is also used to control and recognize only positive allocations and ignore the negative allocations for all the source funds. The effective date column can be set in AsAllocation table via this business rule when the new allocation records are written/copied. This business rule can be used with any transaction (like RebalanceStart, InitialPremium, SystematicWithdrawalStart, etc.) that performs fund allocations.
Copyright © 2009, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices