Transaction Element

An Activity in OIPA represents an action to be completed on a business entity such as a premium payment, additional investment, Policy activation and termination, cash value removal, investment transfer, etc. The OIPA business entities that can have activities are Company (Primary and Subsidiary), Plan, Client, Group Customer and Policy. Activities generate results from calculations, valuation, money movement, entity updates and other entity creations. The complete definition of an Activity's functionality is configured in transaction rules and the transaction's related attached business rules that process during on load of the Activity Screen, during the Activity's data entry, during Activity processing and post-Activity processing results presentation.

Some of the functionalities that a transaction defines are:

  • A user's data entry fields and

    • the validations and data restrictions supported by Events, Actions and ScreenMath

    • the logical dependencies between data fields also supported by Events, Actions and ScreenMath

    • their visibility and access characteristics of the data fields

    • data entry for allocations, withholding, suspense and recurring data structures

  • invocation of fund valuation

  • calculations for entity updating, money investment, money withdrawal, money transfers between Policy funds

  • business validations resulting in business errors and warnings

  • group membership

  • controls on the activity's effective date value

  • activity rescheduling

  • workflow task generation

  • generation of additional activities for follow-up or continued progression of the business process

  • use of reusable features to simplify configuration (copybooks and functions)

  • and indicate same day processing order.

Instances of transactions (Activities) are added to Policies, Clients, Group Customers, Companies and Plans. Some of the Activity's processing behavior are defined by the transaction's type. Transaction types are combined with additional category types that results in each combination providing its own impact to the Activity's processing behavior. These categories are:

  • Financial

    • Allows an activity to process Valuation and move money in, out and between funds of a Policy.

    • The system maintains a strict processing order so as to maintain a sequential history of financial and entity modifications.
      A Policy's finances and data state at any point in time are a reflection of all activities completed prior to that point in time.

      • Processing an Activity that is effective before other active Activities (backdating) must first undo the financial and data updates completed by the active Activities in a reverse order of their processing.

      • The processing of the undo activities results in a financial state that is appropriate to process the new backdated Activity.

      • Following completion of the backdated Activity, the undone Activities reprocess to bring the Policy and its finances up-to-date. This now reflects a Policy's up-to-date financial state and data values that includes the impact of a new Activity.

  • Reversible/Nonreversible

    • Reversible indicates the activity can be reversed and recycled by the user or through adding backdated activities.

    • Nonreversible indicates that the activity cannot be reversed by the user or by adding backdated activities.

      • There is a feature on the OIPA UI that allows users with the proper authorization access to directly reverse these activities for corrective processing.

      • Generated nonreversible Activities are not reversed when the generating reversible Activity (parent) is reversed.

    • Financial transaction types without other attributes default to Reversible. It is important that financial transactions are reversible to maintain the ability to properly calculate accurate Policy cash values throughout the life cycle of a Policy. Financial transactions that are not reversible severely impacts the system's ability to maintain accurate Policy cash values during corrective and backdating process scenarios.

  • Nonreversing

    • This attribute indicates that Activities cannot reverse active Activities with a higher processing order.

    • Since this attribute disrupts the sequential history, activities with this characteristic should not modify the Policy's data or its financial data. These activities should be restricted to:

      • processing where strict processing order is not necessary. For example: address change, because it changes on an effective date regardless of other financial and non-financial transactions.

      • generating activities on other entities that do not need strict processing order.

      • generating statements or documents based on the Policy's current data state.

        • If the Policy data state changes due to corrective processing, activities of the same transaction must be duplicated to collect and report the new data state. This maintains a complete history of events and data collection as they actually occurred and possibly delivered to the Client.

      • Financial transaction types without other attributes default to the opposite of Nonreversing (reversing) and always impact subsequent active activities.

  • Document

    • Document transactions generate data to pass to document generation applications.

  • ScreenUpdate

    • ScreenUpdate transactions define the activity processing to activate time sensitive changes to Group Customer entities.

  • Policy

    • Indicates activities that may be added to a Policy.

  • Client

    • Indicates activities that may be added to a Client.

  • Plan

    • Indicates activities that may be added as Plan level activities and may process on data across multiple Policies of the Plan.

    • This also indicates activities that may be added as Subsidiary Company level activities and may process data across multiple Plans and their Policies.

    • This also indicates activities that may be added as Primary Company level activities and may process data across multiple Clients or Group Customers.

  • Intake

    • Indicates activities are available for use during the Data Intake process.

The combinations of the categories above supported by OIPA are:

  • Client-Document

  • Client-Document-Nonreversible-Nonreversible

  • Client-Financial

  • Client-Financial-Nonreversible-Nonreversing

  • Client-Financial-Reversible-Nonreversing

  • Client-GCQuote

  • Client-ScreenUpdate

  • Intake-File

  • Intake-Record

  • Plan-Document

  • Plan-Document-Nonreversible-Nonreversing

  • Plan-Financial

  • Plan-Financial-Nonreversible-Nonreversing

  • Policy-Document

  • Policy-Document-Nonreversible-Nonreversing

  • Policy-Document-Reversible-Nonreversing

  • Policy-Financial

  • Policy-Financial-Nonreversible-Nonreversing

  • Policy-Financial-Reversible-Nonreversing

  • Policy-IssueDocument

Transaction definition includes a processing order which describes the execution order of an entity's activities when they have the same effective date. The processing order is a simple integer value that organizes the activities sequentially from lower to higher values. The processing order value on its own does not completely satisfy all scenarios. Activities normally process in an ascending effective date order, and this is also considered part of the processing order. The system also needs additional information to maintain a strict processing order when multiple activities of the same transaction are effective for the same effective date because they all have the same initial processing order value. The broader and more complete processing order includes the activity's effective date, the transaction's processing order value and the activity's creation and processing timestamps.

Many of the transaction's capabilities are defined on associated linked pages. The descriptions below are listed in a preferred configuration order.

Note: This <Transaction> element is not the same as the sub-elements of several other business rules.

TransactionElement: Elements and Attributes

Element

Parent Element

Attribute

Description

<Transaction>

     This is the first and root element in the definition of a transaction.
 

<Transaction>

ALLOWQUOTE

Optional:

The attribute enables and disables the Activity's Quote functionality.

Values:

  • No:

    • default

    • Activity quote functionality is not available.

  • Yes:

    • Activity quote functionality is available and enabled.

<CopyBook>

<Transaction>

  

Optional:

This element provides the name of a copybook whose content is inserted into the configuration exactly where it is found. 

The actual copybook content is found through a best match algorithm using data from the containing rule's context. A copybook adopts the containing rule's context so that copybooks can be nested and are all discovered using the same context throughout the chain of copybooks.

The content of the copybook is configuration suitable for any one section of a transaction, or the entirety of multiple or all sections of a transaction.  Placed immediately after the opening <Transaction> element, as it is here, more often indicates the entirety of the transaction.  This however is dependent on the configuration content of the copybook and the rest of the transaction's direct configuration.

A copybook must also be initiated within the correct section as its content warrants. For example, a copybook with <Field> content must be initiated within the <Fields> section of the transaction.  This same copybook cannot contain <Math> configuration as it is inappropriate to have <Math> content within a <Fields> section.

Values:

literal copybook name

<EffectiveDate>

<Transaction>

  

Required:

See EffectiveDate element

<ProcessByCycle>

<Transaction>

  

Optional:

Indicates when immediate processing of spawned Activities generated by ActivitySequence are transferred to the Cycle engine when processing is initiated from the OIPA UI. Cycle allows multi-threaded processing and should be restricted to use cases when there is a need for large volume processing such as instantiation of Policies during a Group Customer enrollment.

Values:

  • No:

    • default

    • ActivitySequence workloads are not transferred to the Cycle engine and remains with the OIPA processing engine.

  • Yes:

    • ActivitySequence workloads are transferred to the Cycle engine.

<Reschedule>

<Transaction>

  

Optional:

See Reschedule element

<Transitions>

<Transaction>

  

Optional:

See Transitions element

<FundLevels>

<Transaction>

  

Optional:

See FundLevels element

<AllowComments>

<Transaction>

  

Optional:

See AllowComments element

<Allocation>

<Transaction>

  

Optional:

See Allocation element

The functionality of this element is replaced by the TransactionAllocationScreen attached rule and configuration should migrate toward using the new rule.

<AllocationFrom>

<Transaction>

  

Optional:

See AllocationFrom element

The functionality of this element is replaced by the TransactionAllocationScreen attached rule and configuration should migrate toward using the new rule.

<DefaultAllocation>

<Transaction>

  

Optional:

See DefaultAllocation element

The functionality of this element is replaced by the TransactionAllocationScreen attached rule and configuration should migrate toward using the new rule.

<FundAllocation>

<Transaction>

  

Optional:

See FundAllocation element

The functionality of this element is replaced by the TransactionAllocationScreen attached rule and configuration should migrate toward using the new rule.

<Valuation>

<Transaction>

  

Optional:

See Valuation element

<ValuesBlock>

<Transaction>

  

Optional:

See ValuesBlock element

<ValueFinancialEntry>

<Transaction>

  

Optional:

This element initiates Financial Entry calculations during Activity processing and allows access to its values in the Transaction's <Math>. 

This element should be left empty as its existence in a transaction initiates the Financial Entry functionality.

<Suspense>

<Transaction>

  

Optional:

See Suspense element

<MultiSuspense>

<Transaction>

  

Optional:

See MultiSuspense element

<Withholding>

<Transaction>

  

Optional:

See Withholding element

<Membership>

<Transaction>

  

Optional:

See Membership element

<Address>

<Transaction>

  

Optional:

See Address element

<WorkflowTask>

<Transaction>

  

Optional:

See Workflow element

<Fields>

<Transaction>

  

Optional:

See Fields element

<MultiFields>

<Transaction>

  

Optional:

See MultiFields element

<Buttons>

<Transaction>

  

Optional:

See Buttons element

<Events>

<Transaction>

  

Optional:

See Action/Events element

<ScreenMath>

<Transaction>

  

Optional:

See Action/Events element

<Actions>

<Transaction>

  

Optional:

See Action/Events element

<Math>

<Transaction>

  

Required:

See Math element

<ActivitySequenceProcess>

<Transaction>

  

Optional:

See ActivitySequenceProcess element

Note: This element cannot co-exist in the same transaction configuration with <Spawns> element or else it will result in an error message in OIPA.

<Spawns>

<Transaction>

  

Optional:

See Spawns element

Note: This element cannot co-exist in the same transaction configuration with <ActivitySequenceProcess> element or else it will result in an error message in OIPA.

XML Schema

<Transaction ALLOWQUOTE="[Yes|No]">
    <CopyBook>[copybook name]</CopyBook>
    <EffectiveDate>...</EffectiveDate>
    <ProcessByCycle>[No | Yes]</ProcessByCycle>
    <Reschedule>...</Reschedule>
    <Transitions>...</Transitions>
    <FundLevels>...</FundLevels>
    <AllowComments>...</AllowComments>
    <Allocation>...</Allocation>
    <AllocationFrom>...</AllocationFrom>
    <DefaultAllocation>...</DefaultAllocation>
    <FundAllocation>...</FundAllocation>
    <Valuation>...</Valuation>
    <ValuesBlock>...</ValuesBlock>
    <ValueFinancialEntry/>
    <Suspense>...</Suspense>
    <MultiSuspense>...</MultiSuspense>
    <Withholding>...</Withholding>
    <Membership>...</Membership>
    <Address>...</Address>
    <WorkflowTask>...</WorkflowTask>
    <Fields>...</Fields>
    <MultiFields>...</MultiFields>
    <Buttons>...</Buttons>
    <Events>...</Events>
    <ScreenMath>...</ScreenMath>
    <Actions>...</Actions>
    <Math>...</Math>
    <ActivitySequenceProcess>...</ActivitySequenceProcess>
    <Spawns>...</Spawns>
</Transaction>

XML Example

<Transaction>
    <EffectiveDate STATUS="Disabled" TITLE="Effective Date" TYPE="SYSTEM"/>
    <CopyBook>CopyBook-FundRelation</CopyBook>
    <Fields>
        <Field>
            <Name>TotalPremiumAmount</Name>
            <Display>Total Premium Amount</Display>
            <DataType>Money</DataType>
            <Disabled>Yes</Disabled>
        </Field>
    </Fields>
    <Math>
        <MathVariables>
            <MathVariable VARIABLENAME="TotalPremiumAmountMV" TYPE="FUNCTION" DATATYPE="DECIMAL">ToDecimal(Activity:TotalPremiumAmount)</MathVariable>
            <MathVariable VARIABLENAME="BonusRate" TYPE="SQL" DATATYPE="DECIMAL" DEFAULT="0">SELECT AsMapValue.FloatValue FROM AsMapValue JOIN AsMapGroup ON AsMapGroup.MapGroupGUID = AsMapValue.MapGroupGUID AND AsMapGroup.MapGroupDescription = 'BonusPercent' JOIN AsMapCriteria ON AsMapCriteria.MapValueGUID = AsMapValue.MapValueGUID AND AsMapCriteria.MapCriteriaName = 'PlanGUID' AND AsMapCriteria.TextValue = '[Policy:PlanGUID]' JOIN AsMapCriteria Q ON Q.MapValueGUID = AsMapValue.MapValueGUID AND Q.MapCriteriaName = 'HighFace' AND Q.FloatValue >= [TotalPremiumAmountMV] JOIN AsMapCriteria R ON R.MapValueGUID = AsMapValue.MapValueGUID AND R.MapCriteriaName ='LowFace' AND R.FloatValue<[TotalPremiumAmountMV]
            </MathVariable>
            <MathVariable VARIABLENAME="BonusAmount" TYPE="EXPRESSION" DATATYPE="DECIMAL" ROUND="2" LOG="Yes">TotalPremiumAmountMV * BonusRate</MathVariable>
            <MathVariable VARIABLENAME="BonusAmountUSD" TYPE="FUNCTION" DATATYPE="CURRENCY">ToCurrency(BonusAmount,'USD')</MathVariable>
            <MathVariable VARIABLENAME="FinancialEntryTypeCodeMV" TYPE="SQL" DATATYPE="TEXT">SELECT CodeValue FROM AsCode WHERE CodeName = 'AsCodeFinancialEntryType' AND ShortDescription='Bonus'</MathVariable>
        </MathVariables>
        <Assignment TYPE="Apply">
            <MoneyType NAME="BonusAmountUSD">67</MoneyType>
        </Assignment>
    </Math>
</Transaction>