Premium change notice for New York -- Testing and verifying

Testing and verifying

Testing without sending anything to policyholders

Test on your UAT site, not production. UAT sites do not send outbound mail to policyholders — confirm this with BriteCore before you begin if you are unsure, since it is a site-level setting rather than anything you can see in the Lines configuration.

Three further things stand between a generated notice and a policyholder, and they are worth understanding because they explain what you are looking at:

• A notice is generated into the print queue, not the email queue. An emailed copy is a separate file, created only for recipients your site is set to email. A policyholder set to paper never has one.
• Emails only go out if your nightly processing is set to automatic. Otherwise nothing leaves until someone sends it.
• Committing a revision generates the notice. It does not send it.

A notice showing print state To Be Determined means it is queued to print. It does not mean an email is about to go out.

Do not do a trial run on production. On a live site the only thing standing between a generated notice and a policyholder is whether that contact happens to be set to email delivery — which is a per-contact setting, not a feature switch.

Proving it works

You cannot test this by browsing. The flag only rates on an uncommitted first revision of a renewal term, and renewals commit as they are created — so you have to create one.

Pick the right policy. This is where the time goes if you get it wrong. A renewal that moves from an older lines effective date to a newer one takes the whole rate change at once, and those are the renewals that exceed the threshold. A policy already on the newest effective date renews on inflation alone and will never exercise the positive branch.

So choose a policy whose current term is still on an older effective date and which has not renewed yet. Do not choose on last year's increase — a policy that rose sharply last year has already taken its rate change.

Then:

1. Create the renewal revision. Creating one does not rate it.
2. Resolve Persistent Builder before rating, if it appears. A renewal that crosses to a newer effective date holds both policy types' items. Rate it in that state and the flag is pinned to the wrong totals permanently, because an item already carrying a premium is not re-rated. Resolve first and the totals reconcile exactly.
3. Check the three evaluations. The current total should match the revision's annual premium; the prior total should match the expiring term. If the prior total is zero, the comparison is not reaching back and that is the thing to fix.
4. Test both sides of the threshold — one policy over it and one under. A flag that is always zero proves nothing on its own, because zero is also what a correctly declining policy produces.
5. Commit and issue. Committing is what runs the rule. Simulation is not enough.
6. Check the print queue. The notice must show print state To Be Determined. A notice at Do Not Print is filed against the policy and never mailed.
7. Open the PDF and check the figures against the policy's actual prior and current premium.

Generation is not instant. The file does not exist the moment the commit returns — it appears seconds later. Checking immediately gives a false negative.

If a renewal does not produce a notice you expected, BriteCore records every rule run, whether the rule matched, and whether its effect applied. Support can retrieve that record.

What a correct result looks like

Run a spread of renewals across the threshold. At a 10% threshold:

The row just under the threshold is the one that proves it. It is not that the flag fires; it is that it declines to fire just below the line. Capture one.

Checking the configuration with SQL

If you have access to the SQL Editor, these read-only checks confirm the configuration on any site, including production. If you do not have access, BriteCore can run them for you.

Check 1 — the item. One row per lines effective date it exists on.

SELECT pt.policy_type, pt.lines_effective_date,

       i.item_type, i.item_category, i.item_is_mandatory, i.item_order,

       i.term_availability, i.loss_free_obj, i.has_rate,

       CHAR_LENGTH(i.rate_chain_obj) AS rate_chain_chars,

       i.decimal_places, i.item_visibility, i.item_system_tags

  FROM v_policy_type_items i

  JOIN v_policy_types pt ON pt.policy_type_id = i.policy_type_id

 WHERE i.item_name = 'Premium Change Notice Flag'

 ORDER BY pt.lines_effective_date DESC;

Expect calculation, policy, mandatory, term_availability = Renewals, has_rate = 1, a non-zero rate chain and no system tags. A newly published effective date with no row is a line that has gone quiet.

Check 2 — anything that rates after the flag. Expect no rows.

SELECT pt.policy_type, pt.lines_effective_date,

       other.item_name AS rates_after_the_flag, other.item_order,

       flag.item_order AS flag_order

  FROM v_policy_type_items flag

  JOIN v_policy_types pt ON pt.policy_type_id = flag.policy_type_id

  JOIN v_policy_type_items other

       ON other.policy_type_id = flag.policy_type_id

      AND other.policy_type_item_id <> flag.policy_type_item_id

 WHERE flag.item_name = 'Premium Change Notice Flag'

   AND (other.item_order IS NULL OR other.item_order >= flag.item_order)

 ORDER BY other.item_order DESC;

Check 3 — the rule. Edit both filters and run once per policy type and effective date.

SELECT policy_type_name, effective_date,

       JSON_EXTRACT(

           policy_type_json,

           SUBSTRING_INDEX(

               JSON_UNQUOTE(

                   JSON_SEARCH(policy_type_json, 'one', 'Premium Change Notice%', '|',

                               '$.underwriting_rules[*].name')),

               '.name', 1)

       ) AS rule_json

  FROM v_json_policy_type_complete

 WHERE policy_type_name = '<policy type>'

   AND effective_date   = '<lines effective date>';

In the result check the module is events, the category is policy, the event is policy issued, renewal transactions are enabled with new business and endorsement disabled, the effect is Generate Deliverable, and the trigger points at the item from check 1.

That cell can hold a couple of kilobytes, which some result grids show as blank. An empty cell is not evidence the rule is missing — click into it.

What SQL cannot tell you: whether the rate chain computes correctly, whether the template carries both merge tags, or whether a renewal actually produces a notice. The wiring is checkable this way; the behavior is not. The Carbone document and its calculated fields are also not covered — check those under Documents.