Quoting and rating basics

Working with the Quote screen

The Quote screen displays total premium, taxes and surcharges, and total cost for a policy period. PolicyCenter displays details of the quote in the Policy Premium tab at the bottom of the screen. The Quote screen varies based on the line of business. For example, the Quote screen for a personal auto policy displays coverages by vehicle and garage location in the Policy Premium tab.

Entities associated with costs and transactions

The PolicyCenter financial system is responsible for obtaining the costs for a policy and determining the transactions necessary to achieve those costs. Costs are part of the policy. A foreign key links a cost to the policy element for which the cost provides a price. Each line of business implements its own costs with a subtype hierarchy that fits with its policy model.

Guidewire defines costs and transactions as follows:

Cost

A cost represents a unit of price for a specific combination of policy elements for a specific period of effective time. A cost is a discrete unit which cannot be broken up into smaller units. The rating system plugin in PolicyCenter or an external rating system (in production environments) returns the costs including the effective periods and any prorated amounts.

Costs attach directly to things that have a price, such as a PersonalVehicle or a PersonalAutoCov or a join between the two. There is a separate cost table for each line of business and there are subtypes of the Cost entity for each type of cost.

Transaction

A transaction represents a line item in a running log of pricing changes. You can retrieve transactions from the policy period, and transactions point to the costs that they offset or onset. Onset transactions point to costs in the same period. Offset transactions point to a cost in the based-on period.

The following are examples of how PolicyCenter handles costs and transactions.

The policy period can be shortened by a cancellation or a policy change made part way through the period. If a cost is reduced because of a shortened policy period, then a new transaction partially offsets the original cost. For example, a coverage originally costs $100 for a one year policy period. The policy is canceled six months into the policy period. PolicyCenter creates an offset transaction for -$50.
The cost changes because there is a new price. For example, a coverage originally costs $100. A policy change increases the coverage for the whole policy period, resulting in a higher price of $110. PolicyCenter creates an offset transaction for the prior cost (-$100) and a new onset transaction (+$110) for the new cost.

In the PolicyCenter default configuration, costs and transactions are implemented as delegates. Delegates are special virtual entities that define key properties or methods for a generic type. You cannot use delegates directly, but you can create an owning class that implements the delegate. Each line of business contains its own tables of costs and transactions which are implemented as owning classes to the Cost and Transacton delegates.

Note: The following sections provide information on multiple lines of business. The variable LOB stands in for the line (such as PA, BOP, or WC) in file and path names.

Cost delegate

Costs are created when the policy is rated.

The Cost delegate is the basic building block for a cost. The delegate provides the common financial columns and behaviors. The delegate assumes that the implementing line decides how the line relates to the building, vehicle, coverage or other item that is being priced.

The Cost delegate:

Has a property that indicates whether the cost is prorated or flat. If the cost is prorated, there is a property for the proration factor.
Has an effective and expiration date.
Can determine if it is fundamentally the same as another cost through the CostKey property.
Can create onset or offset transactions for particular subperiods within its effective period. The transactions created are defined by its LOBCostAdapter. You can find this interface in Guidewire Studio by going to configuration > gsrc and navigating to the gw.lob.LOB.financials package.
Can calculate the prorated amount from term amount and effective date.
Provides additional Gosu functionality defined by the LOBCostMethods Gosu interface. This interface is in the gw.lob.LOB.financials package. The user interface is the primary user of this interface. For example, the interface provides properties that can filter costs in the user interface.

In the base configuration, each line has one abstract supertype table (LOBCost) that defines all the costs for that line and contains the following key properties:

Property	Description
`Basis`	The basis for the cost over the rated term. The basis type itself may vary.
`ActualBaseRate`	The base rate, before applying modifier factors, for the cost over the rated term.
`ActualAdjRate`	The adjusted rate, after applying modifier factors, for the cost over the rated term.
`ActualTermAmount`	The cost over a rated term. If the cost is prorated, the unprorated amount.
`EffectiveDate`	The date this cost becomes effective.
`ExpirationDate`	The date this cost expires.
`NumDaysInRatedTerm`	The number of days in the standard term used for determining the term amount.
`ActualAmount`	The current amount of money for the effective period. If the cost is prorated, the prorated amount.
`RateAmountType`	Tax/surcharge, a standard premium, or a non-standard premium.

Note: An owning class for the Cost delegate must be an EffDatedBean. To view or edit the data definitions for the costs in Studio, see LOBCost.eti in configuration > config > Metadata > Entity.

Guidewire provides the owning classes for the Cost delegate as an example, based on the way policies are commonly priced for each line of business. You can model the costs to fit your business needs.

In the default configuration, a cost can be either prorated or flat.

Prorated costs

The value of a prorated cost is calculated based on the number of days it exists on the policy. Generally, the cost is prorated by dividing the number of days in the policy period by the number of days in the rated policy term. For example, the cost of a coverage for the policy term is $100. The policy term is sliced into two policy periods because a midterm policy change effective halfway through the policy term removes the coverage. The number of days in both policy periods is equal to half the term. The prorated cost for the coverage on the first half of the policy term is half of $100, or $50 for the policy period that it is in effect.

Sometimes prorating results in a cost that requires rounding. If the $100 coverage cost on the policy term is sliced into three equal policy periods, dividing by three results in a cost of $33.333... for each prorated policy period. Adding the three costs results in a value of $99.99, not $100. To ensure that the sum of the prorated costs always adds up to 100% of the unprorated cost, the prorated cost is computed using the following formula:

prorated cost =   round(cost from end of prorated period to beginning of policy term) 
                - round(cost from beginning of prorated period to beginning of policy term)

The following illustration shows how PolicyCenter calculates prorated costs. The costs are in dollars. For simplicity, assume that costs are always whole dollar amounts.

Example 1 shows a coverage that is effective for half of the policy term. If the coverage is in effect for the first half, the cost from end of prorated period to start of policy term is $50. The cost from the beginning of prorated period to beginning of policy term is $0. Rounding does not affect either value. The prorated cost is $50 ($50 minus $0).

Example 2 shows a coverage that is effective for a third of the policy term. For each prorated policy period, the cost is $33.33.... If the coverage is in effect for the middle third, the cost from end of prorated period to start of policy term is $66.66.... When rounded to a whole number, the cost is $67. The cost from the beginning of prorated period to beginning of policy term is $33.33.... When rounded, the cost is $33. The prorated cost of the coverage on the middle third of the policy is $34 ($67 minus $33).

Flat costs

The value of a flat cost is a set amount that either exists on the policy period or does not independent of the length of the policy term. The cost is always the same amount regardless of when the cost appears on the policy. An example of a flat cost might be a fee which exists whenever the insured adds an additional insured to the policy. PolicyCenter does not adjust the amount of a flat cost based the length of the effective policy period. In other words, PolicyCenter does not prorate the cost.

Some qualities of flat costs include:

If added midterm, the full amount of the flat cost is charged.
If removed midterm, the full amount of the flat cost is still charged unless the cost is removed on the same effective date that it was added.
If you lengthen or shorten the policy term, the amount of the flat cost does not change.
In a pro rata cancellation, a flat cost remains at the full amount. However, PolicyCenter reverses the flat cost if the following occurs:
- A policy change adds a flat cost effective after submission.
- A pro rata cancellation occurs effective on or before the policy change effective date.
Upon flat cancellation, refund a flat cost at the full amount.
A flat cost is charged twice if:
- You put a flat cost on the policy.
- Remove it at a later effective date.
- Add it again at another later effective date.

On the Cost object, the ProrationMethod property specifies whether the cost is prorated or flat. The property contains a ProrationMethod typekey. In the default configuration, this typekey can be one of the following values: ProRataByDays (a prorated cost) and Flat (a flat cost).

Flat cost with price change

In the base configuration, flat cost rating is designed with the assumption that the term amount remains constant for a policy term, as described above. There are no circumstances that affect the price.

If in your implementation, the price of the flat cost is not constant, but can fluctuate between issuance and a later policy change, you will observe the following behavior.

A policy change that affects the price of a flat cost generates three transactions. The first transaction reverses the flat cost. The second applies the original flat cost for the old date range. The third transaction applies the new flat cost for the new date range. This results in two flat charges: the full amount for the old date range and the full amount for the new date range.

If you need other behavior, you can configure a custom proration method, ProrationMethod.

Rating systems and flat costs

With Guidewire Rating Management, you can define and rate flat costs. The personal auto line of business contains an example of a flat cost in the Mexico Coverage - Limited coverage. In the policy line in Studio, this coverage is defined just like any other coverage. The coverage does not have a flat-rated field. You specify the flat cost in the rate routine for this coverage. For more information, see In rate routine, specify coverage as flat-rated.

If you do not use Guidewire Rating Management, you can define flat costs, but you must configure the rating for those flat costs. You can define costs as flat costs in Gosu code by setting the ProrationMethod property to Flat on the cost data object. The system table rating plugin implementation contains code to handle flat costs in the CostData class. The system table rating plugin does not contains any examples of flat costs. Although the personal auto line of business includes the Mexico Coverage - Limited coverage, you must configure the system table rating plugin to rate it as a flat cost.

Cost adapter

The Cost delegate requires that the owning class provide an implementation of the following interface:

gw.api.domain.financials.CostAdapter

This interface defines the services that the delegate needs to work properly. In the base configuration, PolicyCenter class LOBCostAdapter implements this interface. You can view the cost adapter in the gw.lob.LOB.financials package.

Transaction delegate

Transactions are created after the policy is rated.

The Transaction delegate is the basic building block for a transaction. The delegate provides the common financial columns and behaviors, and the implementing line decides how to hook into the policy graph. The Transaction for each line of business needs a foreign key to the Cost for that line of business. The Cost points to other tables for that line of business.

The Transaction delegate:

Knows if it is a prorated section of the cost it modifies, and if so, what the proration factor is.
Can retrieve the cost it modifies.

In the base configuration, each line has one transaction table (LOBTransaction) that has a non-effdated foreign key to the cost for that line and contains the following key properties:

Property	Description
`Amount`	The transaction amount for the effective time `EffDate`, `ExpDate`.
`EffDate`	The date on which the transaction becomes effective.
`ExpDate`	The date on which the transaction expires.

In general, you do not need to modify the owning class to the Transaction delegate in your custom configuration.

Transaction adapter

The Transaction delegate requires that the owning class provide an implementation of the following interface.

gw.api.domain.financials.TransactionAdapter

This interface defines the services that the delegate needs. In the base configuration, PolicyCenter class LOBTransactionAdapter implements this interface.

Policy period fields for costs and transactions

The PolicyPeriod entity has several fields which contain the total value of costs and transactions. These fields appear on the Quote screen.

After rating, PolicyCenter calculates these total value fields by adding up the underlying costs or transactions. PolicyCenter stores these calculated total value fields for better performance. For example, you can use these fields to display the total change in cost for a policy change. You can also use these fields to display the total premium for a submission. If you use the total value fields, PolicyCenter does not need to recalculate the amount.

Two cost fields store a total for the costs and represent the full price for the entire period. These values appear on the Quote screen in the Total Premium and Total Cost fields and in the Policy Premium tab. The fields for costs are:

TotalCostRPT – Total value of all costs, including taxes and fees.
TotalPremiumRPT – Total value of all premium costs.

Two transaction fields are calculated from the transactions and store the change in transaction cost for the policy transaction. The transaction cost appears on the Quote screen in the Change in Cost field. Both fields appear in Quote screen on the Cost Change Detail tab for mid-term policy transactions such as a policy change. The fields for transactions are:

TransactionCostRPT – Total value of all transactions, including taxes and fees.
TransactionPremiumRPT – Total value of all premium transactions.

PolicyCenter calculates these fields when the policy is quoted. The calculation occurs after rating the policy and if there is a valid quote. The denormalizeFinancialTotals method calculates these field values. See gw.job.QuoteProcess.gs located in configuration > gsrc in Studio.

Policy period fields for itemized charges

If PolicyCenter is integrated with a billing system that uses itemized charges, PolicyCenter checks whether the policy line requires charges to be itemized. For policy lines that do not use itemized charges, PolicyCenter sends the total values from the policy period to the billing system. For policy lines that use itemized charges, PolicyCenter categorizes the amounts from all the transactions associated with the policy period. The categories are defined either in Advanced Product Designer or by category lookup classes that you define for other product lines. In the base configuration, the personal auto line demonstrates the use of these categories. The values of each Transaction.AmountBilled for the policy period are itemized or summed based on the categories defined for the policy line.

Cost and transaction model for businessowners line

The following diagram illustrates how the various types of costs and transactions interact in the businessowners line. The BusinessOwnersLine is a subtype of PolicyLine. As you can see in the diagram, BusinessOwnersLine connects to the financial array BOPCost. The BOPTransaction entity has a foreign key to BOPCost.

The BusinessOwnersLine entity has a derived array to BOPTransaction. The BusinessOwnersLine gets its derived array of transactions by asking the PolicyPeriod for all of its BOPTransaction entities. The PolicyPeriod entity has an array key to BOPTransaction.

The line of business has a derived array of the transactions to support mid-term removal of a line in a multi-line policy. In a multi-line policy, you can delete a line entirely. If you do that in a mid-term policy change, you may have one or more offset transactions to return premium that is no longer justified for the line. These offset transactions cannot be stored on the non-existent line. Therefore, the offset transactions are stored on the policy period.

Subtypes

The concrete Cost subtypes are:

`BOPLocationCovCostCost`	`BOPCovCost`
`BOPMoneySecCovCostCost`	`BOPAddnlInsuredCost`
`BOPBuildingCovCost`	`BOPMinPremiumCost`
`BOPCovBuildingCost`	`BOPTaxCost`

The abstract Cost subtypes are:

`BOPCoveragePremium`	`BOPTaxable`
`BOPGeneralPremium`	`BOPCost`

The abstract cost subtypes extend one another in the hierarchy. This hierarchy makes it easy to get all costs of at different levels of the hierarchy. For example, if you get all BOPTaxable costs, you also get all BOPCoveragePremium an BOPGeneralPremium costs. The cost supertype, BOPCost, includes costs of all abstract subtypes.

Cost and transaction model for commercial auto line

The following diagram illustrates how the various types of costs and transactions interact in the commercial auto line. The main entity for the commercial auto line is BusinessAutoLine, a subtype of PolicyLine. As you can see in the diagram, BusinessAutoLine connects directly to financial array BACost. The BATransaction entity has a foreign key to BACost.

The BusinessAutoLine entity has a derived array to BATransaction. The BusinessAutoLine gets its derived array of transactions by asking the PolicyPeriod for all of its BATransaction entities. The PolicyPeriod entity has an array key to BATransaction.

Cost and transaction model for commercial property line

The following diagram illustrates how the various types of costs and transactions interact in the commercial property line. The CommercialPropertyLine is a subtype of PolicyLine. As you can see in the diagram, CommercialPropertyLine connects directly to financial array CPCost. The CPTransaction entity has a foreign key to CPCost.

The CommercialPropertyLine entity has a derived array to CPTransaction. The CommercialPropertyLine gets its derived array of transactions by asking the PolicyPeriod for all of its CPTransaction entities. The PolicyPeriod entity has an array key to CPTransaction.

CPCost

The CPCost entity defines a cost associated with the commercial property line. The CommercialPropertyLine entity has an array of CPCost entities.

CPBuildingCovCost

The CPBuildingCovCost entity is a subtype of the CPCost entity. for capturing CP building coverage costs. Building costs are calculated in four separate rates, modeled as subtypes: CPBuildingCovGrp1Cost, CPBuildingCovGrp2Cost, CPBuildingCovBroadCost, and CPBuildingCovSpecCost.

CpStateTaxCost

Captures the tax cost on the line per jurisdiction.

Cost and transaction model for general liability line

The following diagram illustrates how the various types of costs and transactions interact in the general liability line. The GeneralLiabilityLine is a subtype of PolicyLine. As you can see in the diagram, GeneralLiabilityLine connects directly to financial array GLCost. The GLTransaction entity has a foreign key to GLCost.

The GeneralLiabilityLine entity has a derived array to GLTransaction. The GeneralLiabilityLine gets its derived array of transactions by asking the PolicyPeriod for all of its GLTransaction entities. The PolicyPeriod entity has an array key to GLTransaction.

Sublines on costs

Rating for a general liability exposure is often based on two rates: one rate for premises and operations and another rate for products and completed operations.

For each GLExposure and the GeneralLiabilityLine, the rating engine generates two cost rows, one for premises and operations and the other for products and completed operations. The Subline field allows you to distinguish between these rows. You can add additional typecodes to the GLCostSubline typelist, if necessary.

Values for Subline are:

Premises – Premises and operations
Products – Products and completed operations

Costs for split bodily injury and physical damage limits

The user can chose to split bodily injury and physical damage limits for general liability coverages. If the limits are split, the rating engine must calculate separate costs for each exposure. The rating engine must also set the LiabilityLimitSplitType field on GLCost to:

BI – for Bodily Injury
PD – for Property Damage
CSL – for a Combined Single Limit

Cost examples for general liability

Depending upon choices made by the user, the rating engine creates two or four costs per exposure.

If the user selects not to split bodily injury and physical damage limits, the rating engine creates two costs for each exposure.

Combined single limit for the premises subline
Combined single limit for the product subline

If the user chooses to split bodily injury and physical damage limits, the rating engine creates four costs for each exposure.

Bodily injury for the premises subline
Physical damage for the premises subline
Bodily injury for the product subline
Physical damage for the product subline

Cost and transaction model for inland marine line

The following diagram illustrates how the various types of costs and transactions interact in the inland marine line. The InlandMarineLine is a subtype of PolicyLine. As you can see in the diagram, InlandMarineLine entity has an array key to the financial array IMCost. The IMTransaction entity has a foreign key to IMCost.

The InlandMarineLine entity has a derived array to IMTransaction. The InlandMarineLine gets its derived array of transactions by asking the PolicyPeriod for all of its IMTransaction entities. The PolicyPeriod entity has an array key to IMTransaction.

Cost and transaction model for personal auto line

The following diagram illustrates how the various types of costs and transactions interact in the personal auto line. The PersonalAutoLine is a subtype of PolicyLine. As you can see in the diagram, PersonalAutoLine connects directly to financial array PACost. The PATransaction entity has a foreign key to PACost.

The PersonalAutoLine entity has a derived array to PATransaction. The PersonalAutoLine gets its derived array of transactions by asking the PolicyPeriod for all of its PATransaction entities. The PolicyPeriod entity has an array key to PATransaction.

Although not shown on the diagram:

PersonalAutoCov delegates to Coverage.
PersonalVehicle delegates to Coverable.

Subtypes

The concrete Cost subtypes are:

PAMultiPolicyDiscCost
PAShortRatePenaltyCost
PersonalAutoCovCost
PersonalAutoTaxCost
PersonalVehicleCovCost

The abstract Cost subtypes are:

PACoveragePremium
PAGeneralPremium
PATaxable
PACost

The abstract cost subtypes extend one another in the hierarchy. This hierarchy makes it easy to get all costs of at different levels of the hierarchy. For example, if you get all PATaxable costs, you also get all PACoveragePremium and PAGeneralPremium costs. The cost supertype, PACost, includes costs of all abstract subtypes.

Cost and transaction model for workers’ compensation line

The following diagram illustrates how the various types of costs and transactions interact in the workers’ compensation line. The WorkersLine is a subtype of PolicyLine. As you can see in the diagram, WorkersCompLine connects to financial array WCCost. The WCTransaction entity has a foreign key to WCCost.

The WorkersCompLine entity has a derived array to WCTransaction. The WorkersCompLine gets its derived array of transactions by asking the PolicyPeriod for all of its WCTransaction entities. The PolicyPeriod entity has an array key to WCTransaction.

Calculating transactions

After the rating system creates the costs, the default application constructs transactions for the current policy transaction. Transactions represent changes in cost. Policy transactions coordinate all the work associated with creating a new policy period and modifying the policy. Transactions are sent to a billing system or used them for premium accounting. The base configuration provides demonstration code for rating and an integration with Guidewire BillingCenter. For more information, see Billing system integration.

This topic provides an example showing costs and transactions in a personal auto submission policy transaction followed by a policy change transaction. The policy period is six months. In the submission, the customer selects collision coverage with a $1000 deductible. Later, the customer calls and asks to lower the deductible to $250 at the beginning of the fourth month (halfway through the policy period). The agent submits a policy change.

Note: In PolicyCenter, the Policy Premium tab displays costs, and the Cost Change Detail tab displays transactions.

In a submission policy transaction effective August 13 to February 13, you create a six-month policy choosing Collision Coverage with a $1000 Collision Deductible.

The Policy Premium tab on the Quote screen, the cost for collision coverage is $21 and taxes are $49.

PolicyCenter creates a policy period branch with the cost for collision coverage as shown in the following diagram.

On the Summary screen, Total Cost shows the sum of all transactions for the submission as $722.

At a later time, the insured calls to request a decrease in the Collision Coverage deductible from $1000 to $250 beginning November 13, three months from the policy effective date. The agent starts a policy change. The Policy Premium tab on the Quote screen displays the Premium for Collision Coverage. For the whole term, collision coverage with $1000 deductible is $21, and with $250 deductible is $38. The prorated cost is $11 for the first three months, and $19 for second three months.

PolicyCenter creates a new branch for the policy change as shown in the following diagram. The new branch has two costs for collision coverage. Each cost has a prorated amount.

The database contains two costs as follows:

FixedID	ID	EffDate	ExpDate	Term amount	Amount	Car	Coverage
1	3	10/12/2000	01/12/2010	$21	$11	Chevrolet Suburban	Collision
1	4	01/12/2010	04/12/2010	$38	$19	Chevrolet Suburban	Collision

FixedID

EffDate

ExpDate

Term

amount

Amount

Car

Coverage

10/12/2000

01/12/2010

$21

$11

Chevrolet Suburban

Collision

01/12/2010

04/12/2010

$38

$19

Chevrolet Suburban

Collision

The transactions for this policy change appear on the Cost Change Detail tab of the Quote screen. The transactions are the two collision coverages and tax changes. For Collision Coverage with $1000 deductible, there is a ($10.00) offset transaction in the Premium column. For Collision Coverage with $250 deductible, there is a $19.00 onset transaction.

After the rating engine calculates the costs, PolicyCenter generates the transactions by comparing the costs in the previous and current policy period branches. In this example shown in the following diagram, the submission policy transaction created the previous, or first, branch, and the policy change created current, or second, branch.

PolicyCenter creates onset and offset transactions. In the following diagram, the onset and offset transactions on the right show that the customer owes $9 ($19 minus $10). If you have enabled the BillingCenter integration, these transactions are sent to BillingCenter. You can also configure the application to send these two transactions to another billing system. The default application calls the billing system when the policy is bound.

The transaction for the ($10) amount offsets the $21 amount. Both transactions point to the same cost. The transaction for $19 points to a new cost.

In the Policy Transactions section of the Summary screen for the policy change, each line shows the sum of all transactions for each policy transaction.

Internal tools for rating: financial transactions screen

Guidewire provide the Financial Transactions screen as an internal tool for use while developing your application. Users with the internaltools permission can access this screen. A link to access this screen appears in the Tools sidebar of the policy file.

Warning: Guidewire does not support the Internal Tools. Use these tools at your own risk.

The Financial Transactions screen for a policy provides links to view:

All Transactions
Transactions by Job
Transactions by Period

The following table describes the fields for each transaction.

Field	Description
Eff Date	The effective date.
Exp Date	The expiration date.
Amount	The amount.
Posted Date	The date the cost was posted.
Written	Whether cost is written in the policy. Values are Yes or No.
Charged	Whether the cost has been charged. Values are Yes or No.
ToBeAccrued	Whether there are amounts to be accrued for this cost. Values are Yes or No.
Job Type (Date)	The type of job (policy transaction) that created this cost.
Cost	The type of cost.

The Transactions by Period screen lists each period in the policy and allows you to view transactions in two ways: View by Cost Key and View by Cost.

The View by Cost Key choice displays these additional fields:

Field	Description
Cost	The type of cost
Total Charged	Amount that has been charged.
Total Written	Amount written in the policy.

The View by Cost choice displays these additional fields:

Field	Description
Cost	The type of cost.
Policy Transaction (job)	The type of policy transaction that created this cost.
Remaining Written Total	The sum of transactions where the `Written` property is `true`.
Remaining Charged Total	The sum of transactions where the `Charged` property is `true`.