Is proration always linear?

Each rating line determines the cost for each slice as if it were the cost for the entire term, even if it is only part of the term. For rate-scalable costs, which is the typical type of cost, the rating engine linearly prorates costs based on the percentage of the term that each cost is effective. In other words, PolicyCenter gets the term amount (Cost.TermAmount) then calculates the actual cost for this slice. This calculation uses the fraction of the days in the term this cost in this slice is active.

To get the length of time in the term, the default rating engine gets the NumDaysInRatedTerm property from the cost.

The rating engine calculates the amount (Cost.StandardAmount) with the following pseudo-code that uses a fictional function calcNumDays that calculates the number of days between two dates.

var daysEffective = calcNumDays(Cost.ExpirationDate, Cost.EffectiveDate)
Cost.StandardAmount = Cost.TermAmount * (Cost.NumDaysInRatedTerm / daysEffective)

For most types of costs, this approach works for rate-scalable costs.

You might have a rare case in which you want non-linear proration. For example, a snow plow might have higher cost during winter months. You could represent the winter months as one type of coverage and the non-winter months with a different and lower coverage. However, if you want to represent the coverage as a single type of coverage cost but with non-linear proration, this requires changes to the proration plugin.

If you want to change this logic, refer to the class gw.plugin.policyperiod.impl.ProrationPlugin in the static inner class ForGivenRoundingLevel in the method called prorateFromStart.

There are two different places where the default rating engine assumes linear proration.

• In the proration step within the main merge-and-prorate part of the algorithm. You can workaround this by skipping proration by explicitly setting the standard amount (CostData.StandardAmount) and the actual amount (CostData.ActualAmount) properties on a cost data object.
• If you permit a line of business to rate only from the effective date forward, the default rating engine assumes linear proration in some of that code. The default rating engine constructs cost data objects for costs that are earlier in effective time than the job effective date. The default rating engine assumes that it can linearly prorate costs that span the job effective date.