Voluntary Life

Bottom line

Per-class handling

Single representative class — fallback chain picks "all" → "1" → first class.

Voluntary Life uses a single-class model rather than per-class. The parser finds one representative class via a fallback chain (lines 477–510): first class containing "all" (case-insensitive), or first class containing "1", or just the first class. All subsequent fields are keyed by that class name alone. Age bands are mapped to composite key names like voluntaryLifeLess19Employee, voluntaryLife2024Employee, etc.

What's mapped

Plan Facts fields → Quote fields. $allClass is the resolved class.

Plan-level / not mapped

Plan Facts fields the parser doesn't read.

• Spouse-specific guarantee issue conditions (underwriting windows, participation requirements)
• Child age limits and dependent definitions (biological vs. adopted, domestic partner)
• Spouse / child rate increments (e.g., $5K / $10K / $25K step increments available)
• Minimum / maximum purchase amounts per employee or dependent (only Benefit Maximum)
• Portability / conversion exclusion windows
• Evidence of insurability (EOI) requirements or waivers
• Premium payment frequency or collection method

Potentially mapped incorrectly

Four items. The first is a confirmed-looking bug; the rest are semantic concerns worth a verify.

In app/Services/PlanfactService.php at line 805, inside parseQuoteVoluntaryLife(), there's a path-concatenation bug.

The current code is:
'Voluntary Dependent Life.Spouse Death Benefit.' . $allClass . 'Spouse Benefit Amount'

It should be:
'Voluntary Dependent Life.Spouse Death Benefit.' . $allClass . '.Spouse Benefit Amount'

(Missing dot before 'Spouse Benefit Amount'.)

This bug means the lookup never matches the Plan Facts response, and $benefitAmount ends up null. The voluntaryLifeSpouseBenefitsDesc Quote field is silently empty for every voluntary life parse.

Please:
1. Fix the path string.
2. Then grep this entire file for any other path concatenations like '$variable . \"...\"' (without a dot before the suffix) — there may be similar bugs elsewhere. Report any you find.

In app/Services/PlanfactService.php inside parseQuoteVoluntaryLife() (around lines 841–880), Child Benefit Amount values are being assigned to fields named voluntaryLifeDependentTier{1..3}Reduction.

The "Reduction" suffix suggests a percentage reduction, but the values stored are dollar benefit amounts.

Please:
1. Find the form template that renders these Tier{1..3}Reduction fields. Confirm whether the form is treating them as benefit amounts (in which case the field name is misleading) or as reductions (in which case the assignment is wrong).
2. Show me the change you'd recommend — either rename the fields to voluntaryLifeChildTier{1..3}Benefit (or similar) end-to-end, OR fix the assignment to extract a reduction percentage rather than the dollar amount.
3. Don't change anything yet — show the diff and the impact.

In app/Services/PlanfactService.php at lines 849–851, inside parseQuoteVoluntaryLife(), the same Child Benefit Maximum value is being written to both voluntaryLifeMaxGuaranteeIssueChild AND voluntaryLifeDependentTier3Reduction.

Please:
1. Confirm the dual-assignment by showing me the lines.
2. Check the form templates that consume each field to determine which (or both) of those Quote fields actually need this value.
3. Show me a draft change that removes whichever assignment isn't needed. If both are needed, add a comment explaining why.

In app/Services/PlanfactService.php at around line 714, inside parseQuoteVoluntaryLife(), the rate parsing reads:
$rates = $data['Voluntary Life']['Rates'][$allClass]['Employee Uni-smoker Rates'] ?? null;

This only handles uni-smoker (combined) rates. If Plan Facts ever returns separate "Smoker" and "Non-Smoker" rate tables for Voluntary Life, those would be dropped silently.

Please:
1. Search this codebase for any reference to "Non-Smoker" or "Tobacco" rate fields on the Quote model.
2. If smoker-specific rate fields exist on the Quote, draft a change that detects whether the Plan Facts response has uni-smoker OR split smoker/non-smoker, and parses accordingly.
3. If smoker-specific fields don't exist, recommend whether to add them or to log a warning when split rates are encountered.
4. Don't make changes yet — show the proposed approach.

Manual-entry-only fields

• Spouse / Child voluntary participation rules (e.g., can employee purchase spouse without employee coverage?)
• Portability / conversion premium basis (guaranteed vs. self-rated)
• Dependent age-at-entry maximums
• Rate guarantee period
• Underwriting / medical questionnaire requirements at high benefit amounts

Recommendations

1. Fix line 805 path bug 5 minutes

   Add the missing dot. Verify Spouse Benefit Amount populates after the fix.

2. Resolve the Tier-Reduction naming question Hour

   Either rename the fields to …ChildTier{N}Benefit end-to-end, or fix the assignment to extract reduction percentages.

3. Remove the dual-assignment at lines 849–851 15 minutes

   One field, one value.

4. Confirm smoker-rate handling Quick check

   If carriers ever return split smoker/non-smoker rates, today's parse drops them. Check whether this matters in practice before adding code.

Code references