Key values for each cost data subclass

After the rating engine for each line of business generates cost data objects, the default rating engine merges cost data objects for similar costs. The rating engine considers two cost data objects mergable if they satisfy all of the following conditions.

  • They have different but adjacent date ranges. For example, the date range January 1 through March 15 (end of day) and the date range March 16 through September 29.
  • They have the same price, in other words the same value in the TermAmount property.
  • They represent pricing for the same kind of cost for the same thing. For example, for a personal auto coverage cost data object, only merge the cost data objects if the objects share the same coverage ID and vehicle ID. This may require checking multiple properties, and even properties not directly on the object.

It is insufficient to check merely the fixed ID for the cost or the fixed ID of the target object. Technically, two costs can be equivalent and mergable even if they have different fixed IDs.

So, each cost data class must help the default rating determine whether two cost data objects are the same costs for the same things. The default rating engine asks the cost data class to provide a list of values that collectively identify which properties to compare for two cost data objects. Generally, that includes matching subtype-specific columns that uniquely identify the set of related costs and the object whose price this represents.

For example, as described in the bullet list earlier in this topic, suppose there are two personal auto coverage cost data objects. The default rating engine must merge the objects if and only if they have different date ranges and matching vehicle ID and coverage ID. This means that the vehicle ID and coverage ID values are what PolicyCenter calls the key values for the matching algorithm.

Do not confuse key values with Key objects that contain a numeric fixed ID value and an entity type. The fixed ID Key objects are how cost data objects store a link to a revisioned object within the policy graph.

Each cost data class must return a list of its own key values in its KeyValues property getter function. In other words, you must override the property get function for the KeyValues property. To continue the example of the personal auto coverage cost data, that cost data class returns a list that contains the vehicle ID and coverage ID from private variables. In Gosu this looks like the following code segment.

protected override property get KeyValues() : List<Object> {
  return {_vehicleID, _covID}
}

Setting this list properly is crucial for the PolicyCenter default rating engine to merge and convert cost data objects properly. Be extremely careful how you implement this method in new cost data classes.

Carefully consider how you implement the KeyValues method. Errors in this method corrupt rating data during the merge process.

PolicyCenter uses the key values that you return to create an instance of CostDataKey. That object encapsulates the key values that the default rating engine uses as it merges cost data objects.

How the rating engine uses the key values property

To help in the merge process, PolicyCenter has the concept of the cost key for a given cost. This topic provides some context about how the rating engine uses the key values property in the cost data object.

Do not confuse cost keys with Key objects, which simply contain a numeric fixed ID value and an entity type. The fixed ID Key objects are how cost data objects store a link to a revisioned object within the policy graph.

For Cost entity instances, the key has type CostKey and includes the following properties.

  • The type of the Cost
  • The ChargePattern, ChargeGroup, and RateAmountType columns
  • Any other columns on the Cost that are not defined on the Cost delegate and not a standard policy graph property like cost.EffectiveDate.

Extension properties on the Cost delegate (in Cost.etx) are not part of the CostKey.

In contrast, for cost data objects, the key has type CostDataKey and includes the following properties.

  • The CostData subtype
  • The ChargePattern, ChargeGroup, and RateAmountType properties
  • Any values in the CostData.KeyValues property for that cost data subclass

Compare the following statements.

  • Cost entity instances are the same kind of cost for the same thing only if the values match for all properties on their CostKey objects.
  • Cost data objects are the same kind of cost for the same thing only if the values match for all properties on their CostDataKey objects.