Are you sure you want to extend PolicyPeriod?

In Guidewire PolicyCenter, one of the core objects is PolicyPeriod. It is not uncommon to see someone try to extend the PolicyPeriod with the rationale, “This change seems more policy related and does not fit on the line or one of its sub objects.”

The problem is that PolicyPeriod is NOT EffDated (effective dated), it is an EffDatedBranch.  PolicyCenter processes these objects very differently.

The easiest way to see this is to with a bit of code.

Start by extending PolicyPeriod.ext with a new field.

<column  name="EffDatedTestPP_Ext"
  nullok="true"
  type="shorttext"/>

Now extend EffectiveDatedFields.etx with a similar field.
Note: If you have not modified this yet, you need to extend this from EffectiveDatedFields.eti in Metadata

<column
  name="EffDatedTestEDF_Ext"
  nullok="true"
  type="shorttext"/>

Next, expose these fields on the UI.  Yes, we can write queries to prove the change but the UI is easier to see and simple enough to construct.  To keep this example simple and available on most products, I modified PolicyInfoInputSet.PCF and placed new code at the bottom of the input set to see both new fields.

  <Label
    label=""EffDated vs. EffDatedBranch""/>
  <TextInput
    editable="true"
    id="EffDated"
    label=""EffDated""
    value="policyPeriod.EffectiveDatedFields.EffDatedTestEDF_Ext"/>
  <TextInput
    editable="true"
    id="EffDatedBranch"
    label=""EffDatedBrach""
    value="policyPeriod.EffDatedTestPP_Ext"/>

If this were for production, I would use display keys but hard-coded them for this example. Notice there is one TextInput for each field we created.

Now lets start our server and see what happens with a few transactions.

First, create a Submission. I am using Homeowners, and here is the Policy Info Screen.

Now I start a future Policy Change for 6/1/2021. As expected, the values of both fields have not changed. I am going to update both fields with this Policy Change. 

Then issue the change.

So far, the EffDated and EffDatedBranch are as expected but we we only have a Submission and a single change which “seems” to work… until you go out of sequence.

Now change the policy, still in future but earlier than 6/1/2021.  Let’s choose 3/1/2021.  Since this is an out-of-sequence transaction, you will be prompted to continue.  Then you’ll be notified that there are future transactions.

As you can see, the EffDated field is as expected, the value as of 3/1.  This is actually the value from the Submission itself on 1/1. But the EffDatedBranch is based upon the Policy Period and thus sourced from the last bound transaction, the Policy Change on 6/1.

This makes the Submission value appear gone from EffDatedBranch.  It’s not but isn’t easily accessible.  In order to find it, you must jump through some Query hoops which can be challenging. Also, it does not take advantage of the OOS (Out of Sequence) Merge handling facility.

So what actually happened?

Before we answer, let’s take a quick side trip into slices.  

What is a slice? A slice represents a transaction which, in turn, represents a period of time. Let’s see this graphically with a 6-month submission.  We’ll show this slice in blue.

Now add a policy change transaction effective February and show that slice in orange.

We now have two slices, the initial submission and Policy Change 1.  Note that this new slice effectively “ends” the first slice.  Let’s add another policy change effective April, using green this time. Another transaction means another slice.

But what happens with transactions in the past?  The process is the same but the new slice appears between existing slices.  The new slice is shown in yellow, between orange and green.

Now that you know what a slice is, let’s get back to what actually happened?

During the Submission, PolicyCenter creates a PolicyPeriod and the first slice date set at binding. All subsequent transactions copy the latest bound period and start a transaction based on the slice date requested. PolicyPeriods know about all their slices, both future and past.

Imagine the PolicyPeriod as a bucket that provides access to all slices of that policy period. Those slices are the EffDated objects which provide the value of a field based on the slice for a given slice-date. For primitive items stored on the PolicyPeriod, there is only one value, the latest value. As the example showed, PolicyPeriod is NOT versioned but EffectiveDatedFields are.

Don’t get me wrong, there are valid reasons to extend PolicyPeriod with data.   Still, the number one question you need to ask yourself: “Do I need to know when this field’s value changes and be able to see all the values historically?”  If you answer yes, you must use effective dated fields.

Danual Lewis
VP of Professional Services

---

Watch or read our other posts at Kimputing Blogs. You’ll find everything from Automated testing to CenterTest, Guidewire knowledge to general interest. We’re trying to help share our knowledge from decades of experience.