Oracle® Insurance Rules Palette 10.1.2.0 E59346-01

Programs Prototype

A program can be set up to run on a policy or specific segment for a predetermined period of time. It includes attributes that define the program instance and as a result, activities can be run over time according to a specific schedule. Examples of such programs include asset rebalancing, automatic investment plans, systematic withdrawals and cost of living adjustments.

Program Configuration

Three programs were configured on the Functional Prototype Plan to demonstrate program functionality.

• Program A: This is a policy program linked to the Functional Prototype Plan and the Rider with Roles segment. Navigate to the Global Explorer | Programs | Program A | ProgramDefinition.xml. The ProgramDefinition contains the following configuration.

  • Fields: In addition to the fixed Program fields, the following fields have also been configured. ProgramStartDate (Fixed field), ProgramEndDate (Fixed Field), ProgramEffectiveDate (FixedField), ClientName (dynamic field), ProgramFrequency (dynamic field), ProgramAmount (dynamic field), NextScheduledDate ( Disabled field). This date is disabled and updated through CopyToProgram Fields on certain activities).

  • Validations: there are three validations added to the validations section.

  • Transactions: there are four transactions configured for Program A.

    • SetUpProgram: This transaction is created when the green Start icon is clicked on the Program screen for a new program. All fields are pre-populated with the exception of the TestText field. This transaction will spawn the PolicyProgramAScheduledActivity activity, with a spawn date of the next business day. There is one attached business rule, ResetProgram, which will move the program status back to PendingReady upon reversal of the SetUpProgram activity.
    • PolicyProgramAScheduledActivity: This activity is created and spawned from SetUpProgram. All fields are disabled with the exception of the TestText field. Math will determine if the activity effective date is greater than or equal to the Program End Date. If it is greater, then the TerminateProgram activity will generate and the program will be terminated upon the successful processing of the TerminateProgram activity. The TerminateProgram attached business rule causes this to occur. If the date is not greater, then the PolicyProgramAScheduledActivity will spawn on the next business day. The next spawn date is copied to this field.
    • TerminateProgram: This activity is added to a program when the PolicyProgramAScheduledActivity effective date is greater than or equal to the Program End date. The ACTION=Terminate attribute must be present in configuration. Processing the activity will end the program.The Grace activity will also cause the TerminateProgram activity to generate.
    • ReinstateProgram: When the IntRateCalcMoneyIn activity is processed, a program can be reinstated if the program was suspended (08). The ReinstateProgram rule must be attached to the activity. In Program A, the ReinstateProgramSkip activity is generated. This activity determines through configuration that the activity PolicyProgramAScheduledActivity will not be added and processed during the period of suspension. ReinstateProgramSkip will spawn PolicyProgramAScheduledActivity on the next business day.

     

    There is one plan and one segment linked to this program.

     

    • PolicyProgram:The Add and Maintain operations are both available for this program. One test condition also exists for this program. If a policy's Issue State Code is 03, for Arizona, then programs cannot be added. Navigate to the Global Explorer | Programs | Program A | Plan Programs | Functional Prototype Plan | PolicyPrograms.xml.
    • SegmentProgram: The Both operation identifies that the Add and Save buttons will be available for programs. One test condition also exists for this program. If a policy's Issue State Code is 05, for California, then programs cannot be added. Navigate to the Global Explorer | Programs | Program A | Segment Programs | Rider With Roles| SegmentPrograms.xml
• Program B: This is a policy program linked to the Functional Prototype Plan only. The Both operation identifies that the Add and Save buttons will be available for programs. One test condition also exists for this program. If a policy's Issue State Code is 05, for California, then programs cannot be added. Navigate to the Global Explorer | Programs | Program B | ProgramDefinition.xml.
  • Fields: In addition to the fixed Program fields, the following fields have also been configured. ProgramStartDate (Fixed field), ProgramEndDate (FixedField), ProgramEffectiveDate (FixedField), ClientName (dynamic field), ProgramFrequency (dynamic field), ProgramAmount (dynamic field), NextScheduledDate ( Disabled field. This date is disabled and updated through CopyToProgram Fields on certain activities).
  • Validations: there are three validations added to the validations section.
  • Transactions: there are four transactions configured for Program B.
    • SetUpProgram: This transaction is created when the green Start icon is clicked on the Program screen for a new program. All fields are pre-populated with the exception of the TestText field. This transaction will spawn the PolicyProgramAScheduledActivity activity, with a spawn date of the next business day. There is one attached business rule, ResetProgram, which will move the program status back to PendingReady.
    • PolicyProgramBScheduledActivity: This activity is created and spawned from SetUpProgram. All fields are disabled with the exception of the TestText field. Math will determine if the activity effective date is greater than or equal to the Program End Date. If it is greater, then the TerminateProgram activity will generate and the program will be terminated. The TerminateProgram attached business rule causes this to occur. If the date is not greater, then the PolicyProgramBScheduledActivity will spawn on the next business day. The spawn date is copied from the CopyToProgramFields attached rule.
    • TerminateProgram: This activity is added to a program when the PolicyProgramBScheduledActivity effective date is greater than or equal to the Program End date. The ACTION=Terminate attribute must be present in configuration. Processing the activity will end the program.The Grace activity will also cause the TerminateProgram activity to generate.
    • ReinstateProgram: When the IntRateCalcMoneyIn activity is processed, a program can be reinstated if the program was suspended (08). The ReinstateProgram rule must be attached to the activity. In Program B, the ReinstateProgramProcess activity is generated. This activity determines through configuration that the activity PolicyProgramBScheduledActivity will be added and processed during the period of suspension. There is the possibility that multiple PolicyProgramBScheduledActivity activities generate. For example if the Program suspended on 1/1/2012 and the ReinstateProgramProcess transaction is processed on 1/10/2012, 10 PolicyProgramBScheduledActivity activities will be generated. This will make up for the time the Program was in suspension. They all will have the same effective date. The ReinstateProgramProcess activity will spawn PolicyProgramBScheduledActivity activity/activities with an effective date on the next business day.

     

    There is one plan linked to this program.

    • PolicyProgram: The Add and Maintain operations are both available for this program. One test condition also exists for this program. If a policy's Issue State Code is 05, for California, then programs cannot be added. Navigate to the Global Explorer | Programs | Program B | Plan Programs | Functional Prototype Plan | PolicyPrograms.xml
• Program C: This is a segment program linked to the Rider with Roles segment only. The Both operation identifies that the Add and Save buttons will be available for programs. One test condition also exists for this program. If a policy's Issue State Code is 05, for California, then programs cannot be added. Navigate to the Global Explorer | Programs | Program C | ProgramDefinition.xml.
  • Fields: In addition to the fixed Program fields, the following fields have also been configured. ProgramStartDate (Fixed field), ProgramEndDate (FixedField), ProgramEffectiveDate (FixedField), ClientName (dynamic field), ProgramFrequency (dynamic field), ProgramAmount (dynamic field), NextScheduledDate ( Disabled field. This date is disabled and updated through CopyToProgram Fields on certain activities).
  • Validations: there are three validations added to the validations section.
  • Transactions: there are three transactions configured for Program C.
    • SetUpProgram: This transaction is created when the green Start icon is clicked on the Program screen for a new program. All fields are pre-populated with the exception of the TestText field. This transaction will spawn the SegmentProgramCScheduledActivity activity, with a spawn date of the next business day. There is one attached business rule, ResetProgram, which will move the program status back to PendingReady.
    • SegmentProgramCScheduledActivity: This activity is created and spawned from SetUpProgram. All fields are disabled with the exception of the TestText field. Math will determine if the activity effective date is greater than or equal to the Program End Date. If it is greater, then the TerminateProgram activity will generate and the program will be terminated. The TerminateProgram attached business rule causes this to occur. If the date is not greater, then the SegmentProgramCScheduledActivity will spawn on the next business day. The spawn date is copied from the CopyToProgramFields attached rule.
    • TerminateProgram: This activity is added to a program when the SegmentProgramCScheduledActivity effective date is greater than or equal to the Program End date. The ACTION=Terminate attribute must be present in configuration. Processing the activity will end the program.The Grace activity will also cause the TerminateProgram activity to generate.

     

    There is one segment linked to this plan.

    • SegmentProgram (Rider With Roles): The Both operation identifies that the Add and Save buttons will be available for programs. One test condition also exists for this program. If a policy's Issue State Code is 05, for California, then programs cannot be added. Navigate to the Global Explorer | Programs | Program C | Segment Programs | Rider With Roles| SegmentPrograms.xml.

Two new code names were added to AsCode.

• AsCodeProgramType: this user defined code identifies the types of programs. The TYPE attribute in the ProgramScreen business rule references this code name and its values.
• AsCodeProgramStatus: this system code identifies program statuses. It is referenced in the <ProgramPriorStatusCode> element in the ProgramDefinition rule, when identifying a program's status prior to suspension.

Several attached rules were configured and attached to the transactions referenced in the programs above.

• CopyToProgramFields: this attached rule updates dynamic disabled program fields. It can only be attached to a program transaction.
• SuspendProgram: this attached rule creates the SuspendProgram activity, which suspends the program when successfully processed.

• ResetProgram: this attached rule returns the program to a Pending Ready status when the SetUpProgram activity is reversed.

• TerminateProgram: this attached rule creates the TerminateProgram activity, which terminates the program when successfully processed.
• ReinstateProgram: this attached rule creates the ReinstateProgram activity, as defined in ProgramDefinition. A program can be reinstated from Suspend status.

Transaction Configuration

The Program Configuration section above shows how the transactions are associated to the program. The information in this section explains the configuration driving the transactions.

• SetUpProgram: This transaction was used in all three programs. It spawns the scheduled activity for each program. The configuration demonstrates how scheduling is controlled. The Function - NYOKWithDirection is used to trigger the spawning of the scheduled activities on the next business day. The ResetProgram rule is attached to this transaction.
• PolicyProgramAScheduledActivity, PolicyProgramBScheduledActivity and SegmentProgramCScheduledActivity: Using Function- NYOKWithDirection, each scheduled activity is configured to spawn on the next business day. The attached CopyToProgramFields rule copies the NextBusinessDay math variable to the NextScheduledDate on the Program screen. The TransactionBusinessRulePacket uses rule IF syntax to determine when the TerminateProgram rule should execute.
• TerminateProgram: this transaction will terminate any program on the policy after it is processed.
• Grace: this existing transaction was modified to spawn TerminateProgram. It adds a TerminateProgram transaction override to Grace demonstrating the use of the rule attached to a non-program activity. TerminateProgram will terminate any programs on the policy.
• Reinstate: this transaction was configured in two different ways to demonstrate how a program is reinstated and what happens to program activities that were suspended. This transaction spawns the scheduled program activity. The transaction has the ReinstateProgram attached rule overridden at the transaction level. The ReinstateProgram rule will reinstate the program and generate a ReinstateProgramSkip or ReinstateProgramProcess based on the behavior defined in the ProgramDefinition.

View Prototype Example in OIPA

1. Log in OIPA using the Prototype Company user ID and password.
2. Click Policy | New from the Main menu.
3. Type the new policy information and save the record.
4. Click Programs from the Left Navigation menu.
5. Add a program and save.

6. Click the start icon in order to create the SetUpProgram activity.

7. Click Activities to see the program activities.