Overview of Attached Rules

(This business rule can be attached to a plan or client level activity to add existing clients in the database to new agreement roles on an existing agreement. The rule consists of a test condition, which when true will add the agreement role and copy back the agreement role detail information established during the Add Agreement Role activity. This rule can only add roles to the agreement the activity is processed against.

This business rule is attached to a transaction in order to add Impairments based on the configured Impairment criteria.

This business rule is attached to a transaction or requirement in order to add requirements based on the configured requirement criteria.

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.

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.

This business rule will insert one or more policy records into a list bill.

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.

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.

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.

This business rule is attached to a transaction or requirement to allow one or more MathVariables to be copied from the activity/requirement to one or more Claim fields. If the fields are displayed on the Claim screen, the values will be viewable.

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.

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.

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.

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.

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.

The CopyToCommissionFields BR can be attached to a Transaction at Client/Plan/Policy/Company Level. This is a standard CopyTo business rule which can be used to update the Non-System fixed fields and the dynamic fields (with the exception of StatusCode). This rule support collections. A Commission record can be updated,

• by the exact client or policy that created the claim.
• by a transaction at Policy level to which the segment is linked.
• by a Plan level activity of the plan to which the Policy belongs or the Company level activity of the company to which the Plan belongs can update a commission record.

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.

This business rule is attached to a transaction or requirement to allow one or more MathVariables to be copied from the activity/requirement to one or more impairment fields. If the fields are displayed on the impairment screen, the values will be viewable. In addition to field values, CopyToImpairmentFields will automatically update the OptionText of combo box and radio button fields.

(This is the Drop-down text)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.

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.

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.

This business rule will update existing list bill records with new values.

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.

This business rule will update phone data from an activity as required. It is attached to a transaction to allow one or more MathVariables to be copied from an activity to one or more phone fields when the activity to which this rule is attached is processed. There is no AsPhoneFields table attached to AsPhone and this rule can be used to update only the fixed fields.

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.

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>

This business rule is used to copy values from one or more activity fields to other quote fields. The values that are copied to quote fields will be written to the corresponding columns of the AsQuoteBenefit and AsQuoteBenefitField database tables. This rule overrides at Company and Plan Level.

This business rule is used to copy values from one or more activity fields to other quote fields. The values that are copied to quote fields will be written to the corresponding columns of the AsQuoteMember and AsQuoteMemberField database tables. This rule overrides at Company and Plan Level.

This business rule is used to copy values from one or more activity fields to other quote fields. The values that are copied to quote fields will be written to the corresponding columns of the AsQuoteVersion and AsQuoteVersionField database tables. This rule overrides at Company and Plan Level.

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.

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.

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.

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

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.

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.

This business rule is used to copy back values to the alternate name for the purpose of creating a new alternate name instance. The rule can be attached to a transaction to create an instance of an alternate name for a client. The rule uses the current ClientGUID the user is adding the alternate name to and also uses the From and To format similar to CopyTos to create the values for the alternate name.

This business ruleis 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.

The business rule provides the ability to configure an activity-based creation of a new claim, based on events occurring on an existing policy. This rule can be used when a claim should be created at a policy or client level. One or more claims may be generated from a single source policy, but only one new claim per activity is supported. Multiple claims are allowed in a single policy based on the events. This business rule must be attached to a non-reversible activity and must be listed in the TransactionBusinessRulePacket.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Attach this rule to any level activity (Plan/Policy/Client) to add comments to any entity. The ObjectArray defined in transaction math contains all of the field data for the comment, and the target entity for the comment.

Some system generated fixed fields can be available in the transaction math. Identify those fixed fields, which values you can not override (Such as: UpdatedGMT, UpdatedBy, CreatedGMT, CreatedBy, any auto generated GUID).

Use this rule to add records to the AsCommissionDetail /AsCommissionDetailField table. It is attached to the transactions at Policy/Client/Plan level.

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 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.

This business rule is used to create a suspense record when a transaction with this attached rule is processed.

This attached rule provides a mechanism in OIPA to administer the Bill Details within a Bill once a Bill record has been created without deleting and recreating the Bill. The user will be able to add and remove Bill Detail records from existing Bills.

This business rule provides the ability to:

• Aattach additional Bill Detail records to the Bill after the Bill was created. A policy, client or group customer level activity may process to insert one or more Bill Detail records as identified in a MathVariable array of GUIDs.
• Remove Bill Detail records to the Bill after the Bill was created. A policy, client or group customer level activity may process to remove one or more Bill Detail records as identified in a MathVariable array of GUIDs.
• Move Bill Detail records from one Bill to another. A policy, client or group customer level activity may process to remove one or more Bill Detail records as identified in a MathVariable array of GUIDs and insert them into another Bill with the same or another MathVariable array.

MaintainBill rule in the Rules Palette

1. MaintainBill APE transaction overrides will be automatically added to the TransactionBusinessRulePacket.
2. The MaintainBill APE will appear in the Global rules menu as an attached business rule.
3. The MaintainBill APE will appear in the Main Explorer menu as a transaction attached rule.

Business Rule Override Level

The transaction should identify distinct target Bill records for the add/remove actions and allow selection of one or more BillDetail records to add or remove. Multifields would be the most logical input mechanism.

This rule allow a copy-to functionality to update the entity comments. CopyToCommentsFields are used for this purpose. Specify the target entity in the rule. OIPA creates the comment in an object array, so the entity gets defined in the math when the comment object is initiated.

COMMENTS, STATUSCODE, and all dynamic fields are up-datable. GUIDS and system-generated fields are not up-datable.

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.

This business rule is attached to a requirement to match a specified requirement result with the requirement to which this rule is attached.

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.

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.

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.

This business rule is attached to a requirement to set conditions for the automatic processing of activities.

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.

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.

ctivities 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 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.

Tosupport 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.

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.

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 empty (FieldsDoNotExist element) or filled with a value (FieldsExist element) at the time the transaction is processed. View Roles Exist prototype.

This business rule will remove one or more policy records from a list bill.

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 RULENAMEattribute 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.

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.

This business rule is attached to a transaction or requirement in order to spawn an activity from the transaction or requirement.

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.

This business rule controls the order in which the rules attached to the transaction are processed.

TransactionCosmetics rule controls display of values on the Detail column of the Activity screen and warnings for delete and recycle actions. A tool tip element can be used to provide custom details to the user when the cursor hovers over icons in OIPA.

This business rule processes and updates any status changes on a Claim. Processing the transaction or requirement to which this business rule is attached will change the status of the claim to the one specified in this rule. For example, changing the claim status from "Claim Registered" to "Claim Approved".

Attach UpdateCommentsStatus rule to activities to update the status of multiple entity comments.

The UpdateCommissionDetailStatus BR is attached to a Transaction at Client/Plan/Policy/Company Level. This rule can be used to update the commission records status by configuring the Update tag with Yes/No values. A Commission record status can be updated,

• by the exact client or policy that created the claim.
• by a transaction at Policy level to which the segment is linked.
• by a Plan level activity of the plan to which the Policy belongs or the Company level activity of the company to which the Plan belongs can update a commission record.

This business rule processes any status changes on the impairment. The update is not necessarily to the same status. Each status of an impairment is updates to its own value. The status code values comes from AsCodeImpairmentStatus. Processing the transaction to which this business rule is attached changes the status of the impairment to the one specified in this rule.

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.

(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 &gt; 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 &lt; MinimumFaceAmountMV></Expression>

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 SHOWORIGINALattribute 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)

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.