State and federal award payment processing

This operation covers the clsAward family (clsAward, clsFatalAward, clsPPDAward, clsPTDAward, clsAwardCollection) that models a state permanent award and its Social Security offset (clsAwardSSOffset(Collection)), the clsAwardPayment family (clsFatalPayment, clsPPDPayment, clsPTDPayment) that generates and approves the individual monthly payment transactions against an award, clsAwardPayeeInfo for monthly-payee tracking, and the separate clsFederalAwardPayment/clsFederalPayment classes that issue a one-time federal-equivalent award payment outside the state award structure.

Field	Value
Operation ID	OP-CP-08
Trigger	Adjuster creates/edits an award (clsFatalAward/clsPPDAward/clsPTDAward), manages its Social Security offset, and approves generated award payments; or issues a clsFederalAwardPayment
Inputs	Claim type, award type, effective/order/closure dates, worker birthdate/death date, beneficiaries, average weekly wage, Social Security offset data, payee selections and reduction percentages
Outputs	CL_AWARD, CL_AWARD_SS_OFFSET, CL_STATE_AWARD_MONTHLY_PAYEE rows; posted award financial transactions (via Payment posting and totals management)
Primary components	clsAward, clsFatalAward, clsPPDAward, clsPTDAward, clsAwardCollection, clsAwardSSOffset(Collection), clsAwardPayeeInfo, clsFatalPayment, clsPPDPayment, clsPTDPayment, clsFederalAwardPayment, clsFederalPayment
Entry point	Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAward.vb

Steps

1. Create the award for the claim's type. Fatal awards require the claim type to be PTD or Fatal (BR-CP-028); PTD awards require the claim type to be PTD.
2. Enforce type-specific prerequisites (BR-CP-029). A Fatal award requires a worker date of death and at least one beneficiary; a PTD award requires a valid worker birthdate and non-zero average weekly wage.
3. Distinguish advance vs. scheduled awards (BR-CP-030). An advance Fatal or PPD award carries no effective date and zero total monthly payment; a non-advance award's effective date must be on/after the injury date, with PTD additionally bounded by the closure-order date and PPD bounded to not be in the future.
4. Insert or update the award (SQL-011/SQL-039/SQL-094, CL_AWARD) and load related closure-order and financial-transaction context (SQL-040, SQL-041, SQL-042, SQL-043, CL_BENEFIT_PAYMENT, CL_CLAIM_CLOSURE_ORDER, CL_FINANCIAL_TRANS).
5. Assign the next award number (SQL-003, SAIF_AWARD_NUM_NEXTVAL sequence, DUAL) when a new award is created via clsAwardCollection.
6. Track the Social Security offset if granted (BR-CP-034). A Granted offset requires a positive monthly amount, effective/order dates on or after the injury date, and an expiration date on or after the effective date; offset date ranges on the same award may not overlap. A Denied status bypasses all of these checks. Persisted via SQL-013/SQL-046/SQL-096/SQL-119 (CL_AWARD_SS_OFFSET).
7. Generate the monthly award payment. clsFatalPayment/clsPPDPayment/clsPTDPayment.OnInstantiationComplete caps the total payment (and every individual payee's share) at $250,000 (BR-CP-033).
8. Apply lump-sum guidance for first PPD awards (BR-CP-033). A first-time PPD award of $6,000 or less should be paid as a lump sum; one over $6,000 should not be paid entirely as a lump sum — enforced as an approval warning/error, not a hard block.
9. Generate award payees restricted by award type (BR-CP-036). clsAwardPayment.GenerateNewPayee allows only Attorney/Beneficiary/Other/Recovery for Fatal awards and Attorney/Worker/Other/Recovery/Support for PPD/PTD; any other requested payee type is silently downgraded to Other with no error. Monthly payee state persisted through clsAwardPayeeInfo (SQL-012/SQL-045/SQL-095/SQL-118, CL_STATE_AWARD_MONTHLY_PAYEE).
10. Cap support-order and attorney/other-payee reductions by issue date (BR-CP-032). Support-order reductions are capped at 25% of the base amount for issue dates on/after January 1, 2012 (50% before); attorney/other-payee reductions are capped at 44%/63% under the same cutover.
11. Validate the cash card format for award payees (BR-CP-035) — 10 to 16 digits.
12. Guard against double-payment. GetPreviouslyPaidPayees/PreviouslyPaidPayeeList block an award payment approval that overlaps a prior payment to the same payee/provider/reduction for the same payment category and date range on the same award (BR-CP-037).
13. Post the approved award payment through Payment posting and totals management and record the financial transaction through Financial transaction and remark management.
14. Guard award deletion and status changes (BR-CP-031). An award cannot be deleted once a payment transaction has been made against it; its status cannot be set to Active while checks against it are still in progress (financial transaction status codes 1-3).
15. Issue a federal award payment independently.* clsFederalAwardPayment/clsFederalPayment issue a one-time federal-equivalent award payment outside the clsAward structure — no dedicated SQL catalog entries were found for these classes, indicating they likely reuse the common posting/financial-transaction persistence path documented in Payment posting and totals management and Financial transaction and remark management rather than award-specific tables.

Process flow

flowchart TD
    Start([Adjuster creates/edits award]) --> TypeCheck{Claim type matches<br>award type?}
    TypeCheck -->|No| Blocked1([Blocked: award type mismatch])
    TypeCheck -->|Yes| Prereq{Type-specific<br>prerequisites met?}
    Prereq -->|No| Blocked2([Blocked: missing prerequisite data])
    Prereq -->|Yes| Advance{Advance award?}
    Advance -->|Yes| NoEffDate[No effective date;<br>zero monthly payment]
    Advance -->|No| EffDate{Effective date<br>within bounds?}
    EffDate -->|No| Blocked3([Blocked: invalid effective date])
    EffDate -->|Yes| SaveAward[Insert/update CL_AWARD;<br>assign award number]
    NoEffDate --> SaveAward
    SaveAward --> SSO{Social Security<br>offset granted?}
    SSO -->|Yes| SSOValidate{Complete date/amount<br>data, no overlap?}
    SSOValidate -->|No| BlockedSSO([Blocked: incomplete offset data])
    SSOValidate -->|Yes| SSOSave[Save CL_AWARD_SS_OFFSET]
    SSO -->|No, Denied| SSOSave2[Save with no additional checks]
    SSOSave --> GenPayment[Generate monthly award payment]
    SSOSave2 --> GenPayment
    GenPayment --> Cap{Amount within<br>$250,000 cap?}
    Cap -->|No| BlockedCap([Blocked: exceeds cap])
    Cap -->|Yes| Payees[Generate restricted<br>award payees]
    Payees --> Reduction[Apply reduction ceilings<br>by payee class/issue date]
    Reduction --> DupCheck{Overlaps a prior<br>payment on this award?}
    DupCheck -->|Yes| BlockedDup([Blocked: previously-paid<br>payee overlap])
    DupCheck -->|No| Post[Post via Payment posting<br>and totals management]
    Post --> Done([Award payment released])

Failure and edge-case behavior

• Award reduction ceilings and PPD lump-sum guidance are enforced with a January 1, 2012 date cutover baked directly into the class code (PercentLimitChangeDate), not a configurable table — a future policy change would require a code change.
• The double-payment guard (GetPreviouslyPaidPayees) is scoped per award; it does not detect duplicate payments across different awards on the same claim.
• Payee-type downgrading to Other happens silently with no error or warning surfaced to the caller (BR-CP-036), which could mask a data-entry mistake if not caught downstream in the UI.
• No dedicated SQL catalog entries were found for clsFederalAwardPayment/clsFederalPayment; their persistence path is inferred* rather than directly traced to a catalogued statement.
• Active-status changes are blocked while payments are "in progress" (financial transaction status codes 1-3), but the award record itself does not expose which specific payment is blocking the transition.

Related documentation

• Operations and processes
• Business rules
• SQL catalog
• Database tables

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAward.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardCollection.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsFatalAward.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPPDAward.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPTDAward.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardSSOffset.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardSSOffsetCollection.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsAwardPayment.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsFatalPayment.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPPDPayment.vb
• Business\SAIF.Business.Claim.Payment\Payments\StateAwardPayments\clsPTDPayment.vb
• Business\SAIF.Business.Claim.Payment\Payees\clsAwardPayeeInfo.vb
• Business\SAIF.Business.Claim.Payment\Payments\clsFederalAwardPayment.vb
• Business\SAIF.Business.Claim.Payment\Payments\clsFederalPayment.vb