Provide your own prorater subclass

Any implementation of the proration plugin interface must implement one method called getProraterForRounding. This method must return an instance of the class gw.financials.Prorater. The recommended way to implement this is for the plugin implementation to declare an inner class that extends the Prorater class.

The built-in implementation gw.plugin.policyperiod.impl.ProrationPlugin contains an inner class ForGivenRoundingLevel, which extends Prorater.

Your prorater subclass

Your Prorater implementation must override some methods of Prorater and can optionally override others, as described in the following table.

Prorater method	Required to override?	Description
`construct`	Required	Sets private variables to store the rounding level and rounding mode from constructor parameters. Your constructor must call `super`.
`prorateFromStart`	Required	Prorates an amount of money. Its parameters are listed below. A period start date A period end date A date to prorate to An amount as a `BigDecimal` Returns the new amount as a `BigDecimal` value.
`scaleAmount`	Optional	Scales an amount with the rounding level and rounding mode passed to the constructor. There are two method signatures for this method. One method signature takes a `BigDecimal` value and returns a `BigDecimal` value. One method signature takes a `MonetaryAmount` value and returns a `MonetaryAmount` value. If you override scaleAmount method that takes a `MonetaryAmount`, you might also need to override the `BigDecimal` version. The default implementation of the `MonetaryAmount` version of the method calls the `BigDecimal` version of the method. In contrast, if you modify the `BigDecimal` version, you do not need to update the `MonetaryAmount` version of the method
`toString`	Optional	Returns a description of this proration engine.
`financialDaysBetween`	Optional	Calculates the number of financial days between two dates. In the base configuration, includes or ignores a leap day based on configuration parameters.
`findEndOfRatedTerm`	Optional	Takes a start date and a number of days and returns the corresponding end date of the policy term. In the base configuration, includes or ignores a leap day based on configuration parameters.

The Prorater class has a method called prorate that PolicyCenter rating code calls to prorate an amount. The prorate method is public but is final, which means that you cannot override the method. The built-in implementation of this method calls the method prorateFromStart and implements standard proration.

In the base configuration, the financialDaysBetween and findEndOfRatedTerm methods ignore a leap day if either of the following conditions exists.

The IgnoreLeapDays parameter on the plugin interface is true.
The IgnoreLeapDays parameter is not specified, and the config.xml parameter IgnoreLeapDayForEffDatedCalc parameter is true.

The financialDaysBetween and findEndOfRatedTerm methods are complementary. Therefore, a change in one method often necessitates a corresponding change in the other method. For example, in the following code, the values for newDate and date2 must be the same after running the code.

     var numDays = prorater.financialDaysBetween(date1, date2)
     var newDate = prorater.findEndOfRatedTerm(date1, numDays)

How PolicyCenter rating code interacts with prorater subclasses

The PolicyCenter rating system generates Cost entity instances to represents costs of items on a policy. The Cost.ActualAmount property indicates the actual cost after proration. PolicyCenter calculates this cost by calling the computeAmount method on the corresponding CostData object for that type of cost. In the base configuration, the computeAmount method on a CostData class uses the prorater class that the proration plugin provides.

On a partial-term job such as PolicyChange, some rated amounts may change, so corresponding Cost entity instances must change, too. Typically, PolicyCenter adds partial-term offset and onset transactions.

Offset transaction – Covers the old premium for the remainder of the term
Onset transaction – Covers the new premium for the remainder of the term

If the computeAmount method of the CostData object and the prorater disagree about the TermAmount property and the effective date range, PolicyCenter must resolve the discrepancy. PolicyCenter assumes that the Cost entity instance is correct and the Transaction calculation is wrong. PolicyCenter generates full offset and onset transactions instead of partial ones, thus the offset and onset effective dates represent the entire period range, starting at the PeriodStart date.