What it does
Once configured, every renewal you commit is compared against the expiring term. When the increase exceeds your threshold, BriteCore generates a notice carrying that policy's own figures, files it against the policy and queues it to print with the renewal packet.
Nothing runs on a schedule and nobody has to decide which policies qualify. The comparison happens as part of rating.
The four pieces
| Piece | What it does | |
|---|---|---|
| 1 | A calculation item on the line | Works out the increase, and carries it only when it clears your threshold. Otherwise zero. |
| 2 | An Events rule | Reads that item when the policy is issued, and fires when it is above zero. |
| 3 | A Carbone custom document | The notice itself. |
| 4 | Two calculated fields | Put the dollar figure and the percentage on the page. |
The item decides whether a notice prints. The document decides what the page says. They work out their figures independently, which is deliberate: a stale value on the item cannot put a wrong number in front of a policyholder.
Why it needs a rate chain
New York requires the notice to state the increase, not merely mention that there was one. That rules out the simple approaches — a print flag can switch a document on and off but cannot express a threshold, and a static form cannot carry a calculated figure.
It also cannot be done with a rule alone, because rules have no access to the prior term. Rating does: previous_revision_value() reaches back across the term boundary into the expiring term. So the comparison has to happen during rating, and be left somewhere a rule can read it. That is the entire job of the calculation item.
A calculation item is used because it rates and stores a premium while being excluded from every roll-up — the revision total, the premium adjuster and commissions. It can carry a figure without changing a cent of what the policyholder is billed.
What you decide before you start
Two things are yours to decide.
- The threshold. From your filing. It is one number in one expression.
- Scope — which policy types are included. Each needs its own copy of the configuration. Remember any type closed to new business that still renews.
The others are not optional.
Days of notice is not set by this feature. It is the Renewal Invoice offset on each billing schedule — a number of days before the policy term expires. The renewal commits on that date and the notice carries it. Changing it moves renewal invoicing for your whole book, so it should not be adjusted to satisfy a notice requirement. The check is a single comparison: read the offset off your billing schedules and see whether your filing demands more. If it does, the issue is renewal timing rather than the notice.
Renewal timing needs nothing done. The notice and the declaration both carry the commit date, so they join the same print run automatically. They only separate if a renewal is committed far ahead of its term.
No agent or agency copy is created. The notice is generated once per recipient your site already sends declarations to, which in the ordinary case is the named insured alone. If you want an agency copy, that comes from your existing declaration-copy settings and is a separate change.
Renewals committed before you go live get nothing. The rule fires when a renewal is committed; one already committed never fires it again. There is no configuration that changes this — if the gap matters, raise it with BriteCore as a separate piece of work.
You will need Administrator access to Lines configuration, and a UAT site to test on.
