Where to override the default rating engine

There are several different ways you can integrate your own rating engine into this flow, depending on what parts of the built-in system you choose to replace. First, it might help to understand the mechanics of the AbstractRatingEngine so you know where to intercede in that flow.

From a code-level perspective, the default rating engine has the following flow.

To rate a period, first PolicyCenter finds the implementation of the IRatingPlugin interface. PolicyCenter includes a built-in implementation that triggers the default rating engine behavior.
PolicyCenter calls the plugin implementation’s ratePeriod method.
The rating plugin iterates across all policy lines. For each, the plugin creates a rating engine of the right rating engine subclass. All of these rating engine object are instances of the abstract rating engine class.
The rating plugin calls the rate method of each rating engine and passes the PolicyLine entity for the policy line as an argument.
The built-in rating engines for standard rating lines (not worker’s compensation) log some information and then call the rateOnly method to get the cost data objects.
The rateOnly method has the following structure.
1. Get a list of slice dates for the policy. These are the dates that the policy changed in some way across effective time within the policy period.
2. With each slice date, slice the policy at that date. With each slice, call the rateSlice method to calculate cost data objects for each slice. If rating from the job effective date forward only, then get a list of cost data objects that represent all the costs from the database prior to that effective date. In other words, the rating engine had already calculated those slices, so there is no need to recalculate them. The rateSlice method is the typical place for implementing formulas for each type of premium, including rate table lookups.
  This is the critical part of your rating code for costs that make sense in slice mode. Consider encapsulating your actual algorithm into separate Gosu classes, one for each type of premium.
3. Merge the cost data objects from all slices where possible.
4. Calculate prorated amounts. This step assumes linear proration. You can avoid proration for a cost by explicitly setting the actual amount (CostData.ActualAmount) property.
5. Call the rating engine’s rateWindow method to get things like taxes and period-wide (non-linear) discounts.
  This is the critical part of rating code for costs that make sense only as calculations using period-wide subtotals. Consider encapsulating your actual algorithm into separate Gosu classes, one for each type of premium.
After the rateOnly method returns, the rate method uses results to update the cost entities in the database.
The rate method validates the results.

There are three basic strategies you could use to integrate your rating integration code into PolicyCenter.

Focus on rating each slice, and use the built-in architecture. This strategy is the easiest and safest approach.
Use built-in cost data objects, but rewrite slice and window logic.
Do everything on your own with raw cost entities. This strategy is not recommended.

The following table compares and contrasts these three strategies.

Strategy	What to override	Description
Focus on rating each slice, and use the built-in architecture	The rating engine `rateSlice` and rateWindow methods	The easiest and safest approach is to let your rating engine conform to the PolicyCenter definition of slice costs. This strategy lets you leverage the built-in rating code within the AbstractRatingEngine class. In your rating engine, override one or both of the methods `rateSlice` and `rateWindow`. You probably need few if any changes to the built-in rateOnly method. PolicyCenter determines which slices in effective time to rate and how to merge and prorate costs. Run your internal rating algorithm or call out to an external rating engine from the rateSlice method. Your rateWindow method typically would be different logic, or a separate call to an external rating engine. Note that even if you handle slice costs in an external system, you might handle window mode costs such as taxes directly within PolicyCenter Gosu code. These types of costs are typically simpler to calculate.
Use built-in cost data objects, but rewrite slice and window logic	The rating engine rateOnly method	If you do not want the built-in logic for handling slices, you can override the rateOnly method on each rating engine. For example, your rateOnly method might call out to your internal rating algorithm or an external rating system. Your rateOnly method must construct the full list of expected cost data objects. If you base your rating engine on the built-in AbstractRatingEngine class, your rating engine automatically handles generation and persistence of the `Cost` rows. However, if you are rewriting the `rateOnly` logic entirely, you must traverse the policy graph and prorate costs as appropriate. The worker’s compensation line of business is a good example of when to use this approach. A slice-by-slice rating algorithm does not match regulator-imposed requirements.
Do everything on your own with raw cost entities	The entire rating plugin	This strategy is not recommended. However, you could choose to swap out the built-in rating plugin architecture completely and do something entirely different in your rating plugin. If you take this approach, you must manually calculate cost entities and attach them correctly to the policy graph. Although this offers you the most control over rating integration, it requires much more work to understand details of PolicyCenter revisioning to ensure you properly attach costs to the policy.

Strategy

What to override

Description

Focus on rating each slice, and use the built-in architecture

The rating engine rateSlice and rateWindow methods

The easiest and safest approach is to let your rating engine conform to the PolicyCenter definition of slice costs.

This strategy lets you leverage the built-in rating code within the AbstractRatingEngine class. In your rating engine, override one or both of the methods rateSlice and rateWindow. You probably need few if any changes to the built-in rateOnly method. PolicyCenter determines which slices in effective time to rate and how to merge and prorate costs. Run your internal rating algorithm or call out to an external rating engine from the rateSlice method. Your rateWindow method typically would be different logic, or a separate call to an external rating engine.

Note that even if you handle slice costs in an external system, you might handle window mode costs such as taxes directly within PolicyCenter Gosu code. These types of costs are typically simpler to calculate.

Use built-in cost data objects, but rewrite slice and window logic

The rating engine rateOnly method

If you do not want the built-in logic for handling slices, you can override the rateOnly method on each rating engine. For example, your rateOnly method might call out to your internal rating algorithm or an external rating system. Your rateOnly method must construct the full list of expected cost data objects. If you base your rating engine on the built-in AbstractRatingEngine class, your rating engine automatically handles generation and persistence of the Cost rows. However, if you are rewriting the rateOnly logic entirely, you must traverse the policy graph and prorate costs as appropriate.

The worker’s compensation line of business is a good example of when to use this approach. A slice-by-slice rating algorithm does not match regulator-imposed requirements.

Do everything on your own with raw cost entities

The entire rating plugin

This strategy is not recommended. However, you could choose to swap out the built-in rating plugin architecture completely and do something entirely different in your rating plugin. If you take this approach, you must manually calculate cost entities and attach them correctly to the policy graph. Although this offers you the most control over rating integration, it requires much more work to understand details of PolicyCenter revisioning to ensure you properly attach costs to the policy.