The policy period and effective date fields

The PolicyPeriod entity is the root of the graph of revisioned objects. The PolicyPeriod is the branch that all EffDated objects in the graph point to. The PolicyPeriod defines the PeriodStart and PeriodEnd.

Although the PolicyPeriod entity is the root of the revisioned graph, it does not behave like other revisioned objects. The PolicyPeriod entity delegates to the EffDatedBranch interface, but not to EffDated. Because the PolicyPeriod is not EffDated, the PolicyPeriod is handled differently than everything else in the policy period graph and does not have behaviors like splitting on slice mode edit. Therefore, any property, such as one containing data, a typekey, or foreign key, placed directly on PolicyPeriod behaves differently than one placed on EffDated objects such as PolicyLine or PolicyLocation.

A property added directly to PolicyPeriod is for the full term. These properties always have the same value from PeriodStart to PeriodEnd. You can still edit a property value on PolicyPeriod in a policy change, but that value replaces the former full term value. The value is not effective as of the effective date of the policy change job.

For example, the PolicyPeriod has unrevisioned properties that apply to the full term. Some of these properties are:

• TermNumber – An integer
• CreateUser and UpdateUser – Foreign key to User
• Job – Foreign key to Job

Revisioned properties related to the PolicyPeriod are off of the EffectiveDatedFields object. Some of these revisioned properties are:

• OfferingCode – A patterncode
• ProducerCode – Foreign key to ProducerCode
• PrimaryLocation – Foreign key to PolicyLocation
• PrimaryNamedInsured – Foreign key to PolicyPriNamedInsured
• BillingContact – Foreign key to PolicyBillingContact
• PolicyAddress – Foreign key to PolicyAddress

These properties are all items that are revisioned but not tied to a PolicyLine. For convenience, the PolicyPeriod object defines derived properties that enable you to access these revisioned properties. For example, you can access EffectiveDatedFields.BillingContact through the derived property PolicyPeriod.BillingContact.

The following diagram shows PolicyPeriod and EffectiveDatedFields entities.

Arrays and one-to-one relationships of EffDated objects behave the same whether placed on the PolicyPeriod or an EffDated object. All array or one-to-one relationships have a foreign key back to the object to which they are attached. Arrays of EffDated objects attached to a PolicyPeriod vary across effective time. For example, the PolicyPeriod has an array of PolicyContactRole objects that are EffDated. You can determine array membership by the EffectiveDate and ExpirationDate. For example, on 1/1/2019, the array contains one PolicyContactRole object. On 3/1/2019, a policy change adds two PolicyContactRole objects. On 5/1/2019, another policy change removes the first PolicyContactRole.