Checklist for relationship changes in cost data objects

For new cost data subclasses, there are multiple things you must do carefully to ensure that your cost data works with the default rating engine. This topic summaries changes for a cost data subclasses, either for new subclasses or modifications to add links to policy graph objects. This topic contains links to earlier topics that discuss some subjects in more detail.

The most important thing to add to a CostData subclass is an extra relationship (foreign key) to indicate where the cost links within the policy graph. For example, for a vehicle-related cost, the cost might attach to the graph at the level of a vehicle and line-level coverage. Within the cost data object, the foreign keys are fixed ID values encapsulated in a Key object.

To add another relationship (foreign key) to a cost data subclass, perform the following steps.

  1. Add the foreign key as private variables on the CostData with the variable type Key. Prefix the name with an underscore, such as _covID.
  2. Add new arguments to the constructor for these new values. In the constructor, set your private variables based on the constructor arguments.
  3. Override the cost data method setSpecificFieldsOnCost. Set your foreign key properties when creating a new cost.
  4. Override the cost data property get function for the KeyValues property. Add any new relationships to the list that this property get function returns. For example, for a vehicle-related cost, suppose there are two cost data objects that are otherwise the same but for different vehicles or a different coverage. By properly adding the key values for vehicle and coverage to the key values, the rating engine considers the costs different. The rating engine does not merge together or otherwise throw them away as duplicate.

    If you customize built-in entities or create entirely new cost data subclasses, remember to add entity relationships to the KeyValues return value. Otherwise, new costs disappear during the merging process.

  5. Override the cost data method getVersionedCosts. Use the new foreign key properties in the cost data object to find the existing costs (in the database) that are for the same thing. For example, for a line-level vehicle cost, this method must return only the ones that are for a specific vehicle and coverage.

If you customize built-in entities or create entirely new cost data subclasses, remember to consider your new entity relationships in your getVersionedCosts implementation. Otherwise, new costs disappear during the merging process.

The other typical thing a cost data subclass must do is to add extra properties that distinguish between costs that are different but that connect at the same level. For example, suppose you have several possible line-level taxes, such as state tax, uninsured coverage surcharge, and so on. You would need a tax type field that explains which tax this represents. Like a foreign key property, add this information as a new private variable in the class, add it to the constructor, and do all steps in the previous numbered list.

In some cases, you might need to add to cost data variables but not add them to the KeyValues return value or use them in the cost data method getVersionedCosts. For example, you might add the following types of information.

  • Useful information about the cost data, such as its rating tier
  • Information that does not uniquely identify the cost in the graph, for example the cost for state tax for vehicle 1 and coverage B

A common mistake is to add new entity relationships but not add them to the KeyValues return value or add within your getVersionedCosts implementation. This makes new costs disappear during the merging process. Be careful to do all of these steps correctly.