Deciding whether to rate only from change date forward

Policy changes, reinstatements, and cancellations typically rate the policy only from the change date forward. The application user interface enforces the rule that users cannot make changes that affect prior dates or backdate rate changes.

PolicyCenter encapsulates this logic in the shouldRateThisSliceForward method on AbstractRatingEngine.

If you want the rating engine to rate the line from the effective date of the job forward, return true. If you want to rate the whole period starting at the period start, return false.

Choosing to rate from the change date forward is a performance optimization compared to rating the whole policy from the period start date. Even if you choose to use this optimization, PolicyCenter in some cases still rates the whole policy from the period start date, for example for a cancellation. Design your code to ensure that if PolicyCenter rates the entire period or from the change date, the rating engine always returns the same consistent cost values.

The behavior of the built-in implementation is described below.

• Policy changes rate from the change date forward provided that the period start date did not change. The method returns true. If the period start date changed, the method returns false.
• Reinstatements rate from the change date forward provided that the period start date did not change. The method returns true. If the period start date changed, the method returns false.
• Cancellations always rate from the change date forward. The method returns true.
• All other jobs always rate the whole period. The method returns false.

Subclasses can override this method to return true if the rating engine must always re-rate the whole period for a particular line of business. If the line allows for edits that are prior to the effective date, typically it is necessary to re-rate the whole period. For example, in general liability or workers’ compensation lines, any job can result in changes prior to the effective date of that job. This quality is a result of how users edit exposures in window mode (not a particular slice date). If a particular rating engine never rates from the change date forward, you can override the shouldRateThisSliceForward.

This is the case for the built-in general liability line of business rating engine because you can edit some things in window mode. Window mode edits can cause changes to the policy prior to the effective date of the policy change.

When rating from the change date forward, at the end of the rating, PolicyCenter must contain a complete set of CostData objects representing the entity graph and its costs. So, PolicyCenter must still create CostData objects for each Cost already in the database even if you do not intend to rate it.

To implement this, the rating engine for every line of business must implement the existingSliceModeCosts method. This method must determine which costs are slice mode costs (and thus might not be rated).

You also must implement the rating engine method createCostDataForCost. It must create a CostData object from an existing cost. The actual logic that operates using these methods is in the extractCostDatasFromExistingCosts method. It contains additional logic to un-prorate rate-scalable costs and to prorate basis-scalable costs or overridden costs.