Policy period plugin

Modifying plugin for a particular line of business

To modify the plugin behavior for a particular line of business, put line-specific functionality in the PolicyLineMethods implementation class. These classes have names with the LOB prefix with the pattern LOBPolicyLineMethods. For example, the PolicyPeriodPlugin policy period plugin implementation has a postApplyChangesFromBranch method. This method calls postApplyChangesFromBranch for each line in the policy period.

override function postApplyChangesFromBranch(policyPeriod : PolicyPeriod, sourcePeriod : PolicyPeriod)
{
  for (line in policyPeriod.Lines) {
    line.postApplyChangesFromBranch(sourcePeriod)
  }
...
}

To implement functionality for the workers’ compensation line of business, the gw.lob.wc.WCPolicyLineMethods class implements the postApplyChangesFromBranch method.

override function postApplyChangesFromBranch(sourcePeriod : PolicyPeriod) {
     ...
}

Setting written date for a transaction

If PolicyCenter needs to set the written date for a transaction, PolicyCenter calls the policy period plugin method determineWrittenDate to set the Transaction.WrittenDate property. This method takes a policy period and a transaction object. The policy period is the policy period that owns this transaction. The Transaction.WrittenDate property is the date for accounting purposes that the premium is considered as written.

The method returns a java.util.Date object that represents the written date.

In the built-in implementation of this plugin, the code checks whether the period state date is after the transaction’s posted date. If so, the method returns the period start date. Otherwise, returns the transaction’s posted date.

Getting the unassigned policy number display string

The policy period plugin defines a getter for the UnassignedPolicyNumberIdentifier property. This property returns a display string for the policy number if the policy number is not assigned. In the built-in implementation, this getter returns the value Unassigned. This is the value of the display key PolicyPeriod.UnassignedPolicyNumberIdentifier.

You can check the PolicyPeriod.PolicyNumberAssigned Boolean property to see if a policy number is assigned. In the base configuration, this value is false when the PolicyPeriod.PolicyNumber is null.

Specifying types to omit if copying a contractual period

Implement the returnTypesToNotCopyOnNewPeriod method to tell PolicyCenter which entity types must not be copied from one contractual period to the other during renewal, rewrite, and rewrite new account jobs.

For example, you have custom entities that you use for integration or accounting reasons. But you might not want to copy them from one period to another. For example, perhaps you might want to force recalculation of some values to get unique IDs in the new period.

The method takes no arguments and returns a set of entity types (IEntityType) to omit. You can define the set directly in-line using Gosu shorthand for set creation.

override function returnTypesToNotCopyOnNewPeriod(): Set<IEntityType> {
  return { RatingPeriodStartDate, Form, FormEdgeTable, FormAssociation }
}

Specifying types to omit if copying a branch

Implement the returnTypesToNotCopyOnNewBranch method to tell PolicyCenter which entity types must not be copied from a branch. PolicyCenter calls this method during renewal, rewrite, rewrite new account, audit, cancellation, issuance, policy change, and reinstatement jobs. PolicyCenter also calls this method during multi-version quoting and side-by-side quoting.

For example, you have custom entities that you use for integration or accounting reasons. But you might not want to copy them from one period to another. For example, perhaps you might want to force recalculation of some values to get unique IDs in the new period.

The method takes no arguments and returns a set of entity types (IEntityType). You can define the set directly in-line using Gosu shorthand for set creation.

After setting period window

Implement the postSetPeriodWindow method to customize behavior after a user changes the period window of a contractual period. PolicyCenter calls this method if a user changes the effective date or expiration date of a contractual period. The method gets the PolicyPeriod of the new branch, the old start date, and the old end date. You can check the PolicyPeriod.PeriodStart and PolicyPeriod.PeriodEnd dates to get the current values if needed.

The built-in plugin implementation calls the postSetPeriodWindow method for each line of business in the policy period.

For example, the WCPolicyLineMethods class has a postSetPeriodWindow method. This method updates workers’ compensation jurisdiction rating period start dates (RPSDs) after the period change.

This built-in behavior is probably sufficient for most situations and you do not need to modify it.

After creating draft branch in new period

Implement the postCreateDraftBranchInNewPeriod method to customize behavior after a user creates a draft branch in a new contractual period. PolicyCenter calls this for renewal jobs and rewrite jobs. The method takes a PolicyPeriod entity and returns nothing.

The built-in plugin implementation calls the postCreateDraftBranchInNewPeriod method for each line of business in the policy period.

For example, the WCPolicyLineMethods class has a postCreateDraftBranchInNewPeriod method. This method updates workers’ compensation jurisdiction rating period start dates (RPSDs) after creating a draft in the new period.

Before promoting a branch

Implement the prePromote method to customize behavior before a branch is promoted. After a job completes and its draft branch becomes legally binding, PolicyCenter calls this method before promoting the draft branch. This method takes a PolicyPeriod entity and returns nothing.

After handling a preemption

Implement the postCreateNewBranchForPreemption method to customize behavior after a branch has been created to handle preemption. Preemption is name for the situation in which two concurrent jobs for a policy were based on the same branch. After the second job finishes, you must choose whether to apply changes from recently-bound jobs into the active job that is about to be bound. Otherwise, you must withdraw the current job.

In the user interface it might appear that any changes applied as part of preemption are merged into the active branch. However, PolicyCenter actually creates an entirely new branch with based-on revision set to the most recently bound PolicyPeriod in that contractual period. PolicyCenter applies changes from preempted branches (or multiple branches for multiple preemptions) to handle the preemption. After handling the preemption, PolicyCenter discards the active branch that the user was actively working on and was preempted by earlier bound changes.

This method is called after the new branch is created but before the old draft branch is discarded. The first method parameter is the new branch (a PolicyPeriod) created to handle the preemption. This new branch was cloned from the most recently bound branch and then PolicyCenter applies (merges) all changes from the preempted job. This new branch has a based-on revision property that is set correctly so there is no longer a preemption issue. The second argument is the draft branch that the user was actively working, which is the job that was preempted.

After creating branch for new edit effective date in a policy change

Implement the postCreateNewBranchForChangeEditEffectiveDate method to customize behavior after PolicyCenter creates a branch for a change to the edit effective date in a policy change.

To change the edit effective date during a policy change, PolicyCenter replaces the active branch that the user was actively working on with a new branch, PolicyCenter then discards the branch that the user was actively working on. PolicyCenter makes a new branch based on the most recently bound branch, copies the changes from the active branch that the user was working on into the new branch, and then discards the active branch that the user was working on.

This method is called after the new branch is created but before the old policy change branch is discarded. The first method parameter is the new branch (a PolicyPeriod) created for the change to the edit effective date. The second argument is the branch for the policy change before changing the edit effective date.

After applying changes from a branch

Implement the postApplyChangesFromBranch method to customize behavior after PolicyCenter applies changes from a branch. PolicyCenter calls this method in the following circumstances.

• When handling preemptions. PolicyCenter calls this method after applying changes from the preempted branch to the newly created branch.
• In a policy change when a user changes the edit effective date. PolicyCenter calls this method after applying changes from the policy change branch to the new branch with the changed edit effective date.

PolicyCenter calls this method in jobs that can be preempted. These jobs are primarily policy changes, but can also be audit, cancellation, reinstatement, and renewal jobs. Only policy change jobs can have their edit effective date changed.

The postApplyChangesFromBranch method takes two PolicyPeriod entity instances as arguments. The first argument, policyPeriod, is the period to apply changes to. The second argument, sourcePeriod, is the PolicyPeriod to generate changes from.

In the case of a preemption, the sourcePeriod is the original PolicyPeriod the user was working on in a job. For example, the user starts a policy change which adds a vehicle and two coverages to that vehicle; this is the sourcePeriod argument. This job is preempted by another job. The policyPeriod argument is the PolicyPeriod created for the preempting job. PolicyCenter applies the changes to policyPeriod by adding the vehicle and two coverages to the policyPeriod branch. Then PolicyCenter calls this plugin method.

Whether to apply property changes in slice or window mode

Implement the Boolean canDateSliceOnPropertyChange method to determine whether to apply a property change to an object at a particular date, the slice date. This method returns true in most cases. In the base configuration, a few exceptions require window mode, such as exposures in general liability and workers’ compensation. In slice mode, applying a property change on a date splits the object and causes it to automatically prorate its scalable values.

The built-in plugin implementation calls this method when changing the effective date in a policy change transaction. If this method returns true, changes that were introduced by the policy change are reapplied at the new effective date of the transaction.

For example, the WCPolicyLineMethods class has a canDateSliceOnPropertyChange method. This method selectively returns false on certain objects, such as WCCoveredEmployee or WCFedCoveredEmployee.

Whether entity types appear in slice or window mode when applying differences

Implement the returnTypesToNotDateSliceOnApplyDiff method to determine which entity types do not have changes applied on a certain date, or window mode. In the base configuration, this method returns the few entity types that require window mode, such as jurisdictions in workers’ compensation. For these entity types, changes are applied for the entirety of its existence, or not at all.

In the base configuration, this method is called when changing the effective date of a policy change.

The built-in plugin implementation calls the TypesToNotDateSliceOnApplyDiff method for each line of business in the policy period. For all lines, the RatingPeriodStartDate entity type is included in the results.

When copying a submission

Implement the postCopyBranchIntoNewPolicy to customize the behavior when copying a submission.

In the base configuration, this method is called after a new submission is created and the policy and policy period are cloned.

The built-in implementation cleans up the policy period and readies it for editing.