Policy term plugin

The IPolicyTermPlugin policy term plugin calculates values related to policy terms. PolicyCenter includes a built-in implementation of this plugin in the Gosu PolicyTermPlugin class. You can modify this plugin to customize it. Alternatively, implement your own instance of this plugin to customize PolicyCenter application logic.

Calculate the period end date from a term type

Implement the calculatePeriodEnd method which returns the default expiration date as a java.util.Date object.

override function calculatePeriodEnd( effDate : Date, term : TermType, policyPeriod : PolicyPeriod ):
        Date

The input parameters to calculatePeriodEnd are described below.

  • effDate – The effective or start date of the policy period
  • term – The policy term type in the form of a TermType typecode. The value must be the policyPeriod.TermType unless the policyPeriod.TermType is null.
  • policyPeriod – The policy period (PolicyPeriod object)

This plugin method must set the expiration date for every TermType value. In the built-in implementation, term type possible values are Annual, HalfYear, and Other. You can extend this typelist as desired.

Guidewire recommends you make the calculations in this method simple, such as adding a fixed number of years, months, or days. If you make the calculations too complex, you might need to check for edge case conditions in other PolicyCenter code. Consider explaining these conditions in the user interface so users understand how these values were calculated.

Date reconciliation in the built-in implementation

Certain term types, such as half-year terms, have varying numbers of days. Date reconciliation ensures that, in the start month of the initial policy period, a new policy period starts on the same day of the month as the initial policy period. For example, date reconciliation ensures that two half-year terms provide coverage for one year exactly. You may need to implement date reconciliation for your custom term types.

This topic describes how the calculatePeriodEnd method in the built-in plugin implementation (PolicyTermPlugin) does date reconciliation for half-year terms. In some calculations, the built-in implementation uses the initial policy period start date, the start date of the first policy period for this policy.

Assume a policy with a half-year term where the first policy period starts on day X of a month. The calculatePeriodEnd method provides date reconciliation for the policy period end date by finding the first matching condition.

Condition

Period end

1. If the initial policy period start date is day X of a month

The policy period end date is day X unless one of the following conditions is true.

2. If the initial policy period start date is day X of a month and the policy period end date is in a month with fewer than X days

The policy period end date is the last day of the month.

3. If the initial policy period start date is day X of a month, and X is the last day of the month

Subsequent policy period end dates are the last day of the month.

For example, the first half-year term of a policy starts on August 30, 2018. The month of August has 31 days. Date reconciliation ensures two half-year terms provide coverage for a full year.

Period start

Period end

Description

August 30, 2018

February 28, 2019

Condition 2 applies. The period end month, February, has fewer than 30 days, so the period ends on the last day of February.

February 28, 2019

August 30, 2019

Condition 1 applies. Conditions 2 and 3 are not relevant. August is the same month that the initial policy period started, so the period ends on the same day.

The built-in plugin uses the policyPeriod parameter for date reconciliation. The calculatePeriodEnd method uses the shouldPerformDateReconciliation flag on PolicyPeriod.Job to determine whether to reconcile the date. By default, the flag is false. However, the submission, renewal, rewrite, and rewrite new account jobs set the flag to true.

Calculate a term type from period start and end dates

Implement the calculatePolicyTerm method to determine the term type of a policy term given its start date, a period end date, and a Product. The method must return a TermType typecode.

To make date calculations time-insensitive, consider using the PolicyPeriod method trimToMidnight to trim excess time values backward to midnight.

Some lines of business allow extra days of coverage at the end of an annual policy term (TermType is Annual) just in case the policy has not yet been renewed. You can add additional days to an annual term by implementing the AdditionalDaysInAnnualTerm property in the PolicyLineMethods implementation class for one or more lines of business. These classes have names with the LOB prefix with the pattern LOBPolicyLineMethods. In the base configuration, an annual workers’ compensation policy provides coverage for one year plus 16 days by defining this property in the WCPolicyLineMethods class.

override property get AdditionalDaysInAnnualTerm() : int {
    return 16
}

Calculate period end from a based on PolicyPeriod

Implement the calculatePeriodEndFromBasedOn method to return the default expiration date based on the effective date, the term type, and a based-on PolicyPeriod. This method must always return a non-null date. The return value is a java.util.Date.

The method accepts the following arguments.

  • effDate – The effective or start date of the policy period
  • term – The policy term type in the form of a TermType typecode. Set the expiration date for every TermType value and throw an exception for unexpected term types. In the built-in implementation, term type possible values are Annual, HalfYear, and Other. You can extend this typelist as desired.
  • policyPeriod – A PolicyPeriod object that a new period is based on
  • shouldPerformDateReconciliation – A Boolean value that specifies whether to perform date reconciliation. Date drifting occurs when a policy term of a given TermType (or multiple policy terms) does not cover the expected number of days. For example, two consecutive policy terms with the term type HalfYear would provide exactly one year of coverage, so date reconciliation ensures that behavior. The base configuration implements the following characteristics.
    • The end date of the second term lines up with the start date of the first term so that together, they cover one year just as an annual term would.
    • Consecutive annual terms naturally have the same start day, but are adjusted for leap year days.

For the returned date, the time part of the returned expiration date will be ignored in favor of the existing expiration time as set by the effective time plugin.