Slice mode APIs

In most cases, you access a PolicyPeriod related to a job. In standard application contexts, PolicyCenter sets up the PolicyPeriod and sets the slice date to the effective date for the job. Typically you do not need to do anything special to set a slice date if you want to work with the branch at the effective date. Simply access the properties on entities referenced from the PolicyPeriod and work with it as a graph of objects.

To ensure you access a PolicyPeriod entity instance in slice mode, you can call its getSlice method:

// get a handle to the PolicyPeriod in slice mode with a specific date and SAVE the return value
slicedPolicyPeriod = aPolicyPeriod.getSlice(sliceDate)

The returned object represents the same PolicyPeriod entity instance, but it is a different object in local memory that Gosu specially marks as in slice mode. Remember to use the return value from the getSlice, not your original reference to the PolicyPeriod. The original in-memory copy of the entity instance is unchanged.

If you get properties on a slice mode object to access other objects, those objects are also automatically in slice mode. In typical code, you can navigate up or down the object graph hierarchy without worrying about the revisioning details. At any time you can get the object.SliceDate property to get the slice date.

In most cases, it is best to call getSlice on the root PolicyPeriod and navigate down the object graph from there. However, you can call getSlice on an individual revisioned subobject of PolicyPeriod if necessary.

For example:

autoLineExpiration = vehicle.getSlice(sliceDate).PolicyLine.PolicyPeriod.ExpirationDate

The foreign key links after the getSlice method implicitly use the slice date to find the right version of the PolicyLine.

Note: If a policy period is in slice mode and you get any subobjects, they are in slice mode automatically. it is redundant to call getSlice with the same slice date.

Be sure that the slice date that you pass to getSlice is in the effective date range for that object. If you try to pass a date outside the required range, then Gosu throws an exception.

For example, if you removed an auto from an auto policy before the slice date, Gosu throws an exception because that auto is not effective at that date. However, if you call getSlice on the PolicyPeriod and navigate down the object graph for that slice, you do not need to worry about unavailable effective dates for subobjects. This is why it is typically best to call getSlice on the PolicyPeriod and navigate down the object graph from there.

Note: For many use cases, it is best to slice the root PolicyPeriod with a specific slice date. In other words, call getSlice on the root PolicyPeriod entity instance and then navigate down the object graph from there.

Automatic changes for slice mode edits

When editing objects in slice mode, certain changes happen automatically:

  • If in slice mode and you change an existing subobject of the PolicyPeriod, the changed entity instance automatically splits into two entities. One entity instance represents the change before the slice date and one entity instance represents after the slice date. The split does not occur if the split date is already the effective date of the entity instance. If a split is needed, it happens immediately in the in-memory version of the entity instance. Even if a property is reverted after a split, the entity instance remains split.
  • If in slice mode and you add a subobject of the PolicyPeriod, the new entity instance automatically has an effective date of the slice date.
  • If in slice mode and you delete a subobject of the PolicyPeriod, the entity instance automatically has an expiration date the day of the slice date. However, if the split date is already the effective date of the entity instance, the entity instance is simply deleted.
  • To handle situations like out-of-sequence jobs and preempted jobs, merging changes forward to future effective dates is not handled automatically in Gosu at the time the change is made. The job process and workflow files detect this issue at quote time. The job files and PCF files offer the user a chance to apply changes to later effective dates and resolve any conflicts. For more information, see Out-of-sequence jobs, Preempted jobs, and Applying changes to future renewals.

Slice mode notes

  • You can mark an entity instance in the data model to not automatically split on an edit. For example, PolicyCenter uses this feature for objects that never split, such as transactions and forms. Other objects can be split but only split explicitly, for example costs and Workers’ Compensation Jurisdictions. To mark an entity instance to not automatically split on editing, set the data model attribute autoSplit to false.
  • A scalable field that scales as a result of a split shows up in the PolicyCenter list of differences as a window edit.