Renewals in BriteCore are intended to renew automatically year after year.


BriteCore Processing

Standard Process

  • BriteCore will automatically renew the policy by creating and committing the renewal revision. This will occur when the renewal invoice is scheduled to print. For example, if the renewal invoice is scheduled to print 33 days in advance of the renewal then the system will renew the policy 33 days in advance of the renewal effective date
  • The renewal will reflect any applicable changes to the policy including
    • Adding inflation guard
    • The addition of a mandatory coverage
    • Updating categories (e.g., age of dwelling)
    • Updating claim history for claim surcharging/crediting
  • A renewal Declaration and invoice will print reflecting any changes to the policy
  • No forms should print unless
    • A new policy form has been added to the policy at renewal
    • A form is setup to print at every renewal
    • A form’s code or edition number has been updated
  • Vendor data will process as it typically does

Secondary Process

BriteCore may not auto-renew a policy for various reasons. If a renewal does not process, you will be alerted via email, examples of which are just below. The emails will provide a reason for the failure and, at times, suggestions for addressing the issue. Recipients added to the Processing Errors section of Administrative Alerts in Settings > System Wide > Administrative Alerts > Processing will receive the email notification.

When a renewal fails due to a change to lines, the Persistent Builder tool will help you process the renewal. See the Use Persistent Builder how-to below.

BriteCore: Renewal Commit Failures: [carrier name]
Renewal revision (YYYY-MM-DD) for policy 10-2017-1 couldn't be created. System message:
System Renewal Revision was not created because of the existence of an uncommitted, manually-created Renewal Revision. You must manually commit this revision.
Persistent Builder: Failed Renewal Processing: [carrier name]
Persistent Builder encountered an error while trying to renew policy 10-2016-1. To prevent damage to the policy's integrity, the new revision (YYYY-MM-DD) has been removed.
Please submit a ticket with the appropriate priority level and include the following information:
Policy Number: 10-2016-1
Error Date and Time: 2016-11-15 07:38:16.053643

Crossing a New Lines Effective Date

Your site may have a new lines effective date. As policies renew, they will renew onto that new effective date and pick up any associated changes. If there are no conflicts, BriteCore will follow the Standard Process above; if there are conflicts, BriteCore will follow the Secondary Process.

Late Term Endorsements

If an endorsement occurs after the renewal has been issued, BriteCore will attempt to carry forward any changes.

Automatically

If the change can be carried forward BriteCore will automatically apply the changes, commit the revision, update the accounting (if necessary), and generate applicable deliverables.

Manually

If the change cannot be automatically carried forward, a popup will generate indicating the change must be manually completed on the renewal revision.

Leftover Debits/Credits from the Previous Term

Outstanding Debit

When the next payment is received, it will apply to the term 1 outstanding debit first. At present, the renewal invoice does not pick up the outstanding debit for term 1, so term 2 may also be underpaid once the payment is received.

Outstanding Credit

Any outstanding credits will be carried forward on the renewal effective date. Since the credit is not carried forward until the renewal effective date, term 2 may also end up with a credit.


How-Tos

Use Persistent Builder

Persistent Builder is a tool to update policies when renewed onto a new lines effective date.

Line Item Statuses

Rejected (Red)

A line item BriteCore was unable to find in the new policy type.

Incomplete (Orange)

A line item that failed to copy but is mandatory for the new policy type, or a line item that partially copied. These line items need to be reviewed and will likely require the input of new information.

Pending Review (Green)

A line item that copied successfully but should be reviewed.

Complete (White)

A line item that has been reviewed.

Workflow

Using the Conflict Resolver toolbar at the top of the page,

  • Resolve rejected line items (red). If needed, readd the appropriate line item. To resolve a line item, check the box next to the line item then select Mark As Resolved on the Conflict Resolver toolbar
  • Resolve incomplete line items (orange). Review the line item and complete any missing limit, category or supplemental question information
  • Resolve pending line items (green). Review the line item

FAQs

Can I renew a policy before BriteCore does?
Yes, a policy can be manually renewed by creating an revision with a date equal to the renewal effective date. However, it is not recommended that renewals be manually processed.

If I manually create the renewal revision but do not commit it, will BriteCore commit it?
No, BriteCore will not auto commit the revision. When the renewal date comes to pass, the uncommitted policy will appear in the email referenced in the Secondary Process section above.

Are there any reports that are useful with renewing policies?

  • Policy Renewals Policies renewing in the next X days
  • Policy Term Expirations Expiring policies over a date range

More Information

Persistent Builder

Possible Issues

The policy type on the revision doesn't match the items.

Diagnostic Query

When researching PB, always run the below query and set the revisionId:

SET @rev = '565e1a36-e576-4118-a71d-3543816f5b7a';
SELECT tmp.* FROM (
SELECT revision_items.id , revision_items.itemId, revision_items.subLineInstanceId, policy_type_items.subLineId AS Item Subline, 'None' AS property_id, sub_lines.name AS Sub Line Name, policy_type_items.name AS Item Name, revision_items.persistStatus,
revision_items.statusReason, revision_items.deleted, revision_items.writtenPremium, revision_items.deductible, revision_items.limit, revision_items.builderObj, policy_type_items.policyTypeId,
revision_items.resolved, policy_types.name AS 'Type Name', effective_dates.effectiveDate, revision_items.revisionId, 'revision_items' AS Table, revision_items.dateAdded, revision_items.dateAddedMicro
FROM revision_items
LEFT JOIN policy_type_items
ON policy_type_items.id = revision_items.itemId
LEFT JOIN revision_sub_lines
ON revision_sub_lines.id = revision_items.subLineInstanceId
LEFT JOIN sub_lines
ON revision_sub_lines.subLineId = sub_lines.id
LEFT JOIN policy_types
ON policy_types.id = policy_type_items.policyTypeId
LEFT JOIN effective_dates
ON effective_dates.id = policy_types.effectiveId
WHERE revision_items.revisionId = @rev
UNION
SELECT property_items.id, property_items.itemId, property_items.subLineInstanceId, policy_type_items.subLineId AS Item Subline, property_items.propertyId AS property_id, sub_lines.name AS Sub Line Name, policy_type_items.name AS Item Name, property_items.persistStatus,
property_items.statusReason, property_items.deleted, property_items.writtenPremium, property_items.deductible, property_items.limit, property_items.builderObj, policy_type_items.policyTypeId,
property_items.resolved, policy_types.name AS 'Type Name', effective_dates.effectiveDate, properties.revisionId, 'property_items' AS Table,
property_items.dateAdded, property_items.dateAddedMicro
FROM property_items
LEFT JOIN properties
ON properties.id = property_items.propertyId
LEFT JOIN policy_type_items
ON policy_type_items.id = property_items.itemId
LEFT JOIN property_sub_lines
ON property_sub_lines.id = property_items.subLineInstanceId
LEFT JOIN sub_lines
ON property_sub_lines.subLineId = sub_lines.id
LEFT JOIN policy_types
ON policy_types.id = policy_type_items.policyTypeId
LEFT JOIN effective_dates
ON effective_dates.id = policy_types.effectiveId
WHERE properties.revisionId = @rev
UNION
SELECT property_sub_lines.id, property_sub_lines.subLineId, 'N/A - Is a Subline' AS subLineInstanceId, 'N/A - Is a Subline' AS Item Subline, property_sub_lines.propertyId AS property_id, sub_lines.name AS Sub Line Name, sub_lines.name AS Item Name,
property_sub_lines.persistStatus, property_sub_lines.statusReason, property_sub_lines.deleted, 'N/A' AS writtenPremium, 'N/A' AS deductible, 'N/A' AS limit, 'N/A' AS builderObj, sub_lines.policyTypeId,
property_sub_lines.resolved, policy_types.name AS 'Type Name', effective_dates.effectiveDate, properties.revisionId, 'property_sub_lines' AS Table, property_sub_lines.dateAdded, property_sub_lines.dateAddedMicro
FROM property_sub_lines
LEFT JOIN properties
ON properties.id = property_sub_lines.propertyId
LEFT JOIN sub_lines
ON sub_lines.id = property_sub_lines.subLineId
LEFT JOIN policy_types
ON policy_types.id = sub_lines.policyTypeId
LEFT JOIN effective_dates
ON effective_dates.id = policy_types.effectiveId
WHERE properties.revisionId = @rev
UNION
SELECT revision_sub_lines.id, revision_sub_lines.subLineId, 'N/A - Is A Subline' AS subLineInstanceId, 'N/A - Is a Subline' AS Item Subline, 'None' AS property_id, sub_lines.name AS Sub Line Name, sub_lines.name AS Item Name, revision_sub_lines.persistStatus,
revision_sub_lines.statusReason, revision_sub_lines.deleted, 'N/A' AS writtenPremium, 'N/A' AS deductible, 'N/A' AS limit, 'N/A' AS builderObj, sub_lines.policyTypeId,
revision_sub_lines.resolved, policy_types.name AS 'Type Name', effective_dates.effectiveDate, revision_sub_lines.revisionId, 'revision_sub_lines' AS TABLE,
revision_sub_lines.dateAdded, revision_sub_lines.dateAddedMicro
FROM revision_sub_lines
LEFT JOIN sub_lines
ON sub_lines.id = revision_sub_lines.subLineId
LEFT JOIN policy_types
ON policy_types.id = sub_lines.policyTypeId
LEFT JOIN effective_dates
ON effective_dates.id = policy_types.effectiveId
WHERE revision_sub_lines.revisionId = @rev) AS tmp
ORDER BY tmp.revisionId, tmp.Item Name, tmp.dateAdded, tmp.dateAddedMicro;


Feedback

Report unclear or missing documentation.