Skip to content

Timeloss payment issuance

This operation covers clsTimelossPaymentBase and its concrete clsTimelossPayment (and clsFederalTimelossPayment), which validate and approve timeloss benefit payments against a claim's benefit periods, including duplicate-payment protection, the statutory three-day waiting period, supplemental-TD eligibility, reserve sufficiency, reduction ceilings, and automatic support/recovery payee maintenance.

Field Value
Operation ID OP-CP-09
Trigger Adjuster creates and saves a clsTimelossPayment (or schedules one), or approves it for release
Inputs Claim ID, benefit period(s), payment category (regular/supplemental TD), payee list, issue date
Outputs Approved/released TD financial transaction (via Payment posting and totals management); updated benefit period/schedule state (via Benefit period and schedule management)
Primary components clsTimelossPaymentBase, clsTimelossPayment, clsFederalTimelossPayment
Entry point Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsTimelossPayment.vb

Steps

  1. Select the benefit period(s) to pay. The payment draws its from/thru dates and TD day counts from one or more benefit periods already on the claim.
  2. Select a payment category. PaymentCategoryList offers regular TD and Supplemental TD; Supplemental TD is only offered when the injury/disability date is on or after January 1, 2002, secondary-employer average weekly wages are greater than zero, and at least one secondary employer exists (BR-CP-042).
  3. Enforce the statutory three-day wait (BR-CP-041). Rule_CheckPeriodDatesOverlap3DayWait blocks a benefit period overlapping the wait unless the claim is payment-eligible, with exceptions for supplemental TD and a zero-amount TD accompanying period.
  4. Restrict TD days on a supplemental period once it leaves in-progress status (BR-CP-042) via Rule_CheckSupplementalTdDays.
  5. Check payment schedule eligibility if scheduling (BR-CP-041). CanSchedule/Rule_CheckValidSchedule require exactly one 14-day benefit period (or period pair) in a single category, no supplemental-TD period, and no previously-paid amounts or days; Rule_CheckNoPreviouslyPaidWithSchedule reinforces the last condition.
  6. Validate the issue date (BR-CP-045). Rule_CheckValidIssueDate blocks a past date or one more than 28 days in the future; Rule_CheckIssueDateIsWorkingDay requires a working day.
  7. Split benefit periods crossing the fiscal-year boundary (BR-CP-045). UpdatePeriodsCrossingSplitDate/GetSplitDates divide a period spanning July 1 into two periods, one on each side.
  8. Maintain support and recovery payees automatically (BR-CP-044). HandleChangeInSupportOrder adds a support payee when the claim gains a support order and removes it when the order clears; HandleChangeInRecoveryStatus adds a recovery payee when the overpayment non-deferred balance is positive and removes it once cleared.
  9. Allocate the benefit amount across payees (BR-CP-044). RecalculatePayeeBenefitPercentages/GetPayeeBenefitAmountLessInterest round each non-worker payee's percentage share to the cent; the worker payee absorbs the remainder, so rounding differences and unallocated percentage always land on the worker.
  10. Validate minimum releasable amount (BR-CP-039). The payment total must be at least $1.00 (or exactly zero); individual payee amounts under $1.00 raise a warning; the sum of benefit-period amounts must equal the sum of payee payment amounts.
  11. Check reserve sufficiency (BR-CP-040). A schedule's remaining payment count times the payment amount may not exceed the applicable TD/vocational-TD reserve, unless the claim is own-motion reimbursable.
  12. Check reduction ceilings on approval (BR-CP-043). CheckApprovalWarnings/SupportMaxPct warn when support deductions exceed 25%/50% (by closure-order type and issue-date cutover), combined non-worker deductions exceed 44%/63%, an individual attorney/other payee exceeds 25%, or a support payee's monthly total exceeds the support order's configured maximum.
  13. Reject duplicate payments (BR-CP-038). TranExists blocks saving an approved, non-deleted payment (not loaded by payment ID) that matches an existing TD transaction on claim, benefit from/thru dates, issue date, total amount, and entry date, with "Error: Duplicate payment can not be saved."
  14. Post the approved payment through Payment posting and totals management and record the financial transaction through Financial transaction and remark management.
  15. Issue a federal timeloss payment independently.* clsFederalTimelossPayment follows the same benefit-period/payee model as clsTimelossPayment but represents the federal-equivalent TD payment; no distinct SQL catalog entries were found for it, consistent with reuse of the common posting/financial-transaction path.

Process flow

flowchart TD
    Start([Adjuster enters TD payment]) --> SelectPeriod[Select benefit period(s)]
    SelectPeriod --> Category{Category = Supplemental TD?}
    Category -->|Yes| SuppCheck{Eligibility met?}
    SuppCheck -->|No| BlockedSupp([Supplemental TD unavailable])
    SuppCheck -->|Yes| WaitCheck
    Category -->|No, regular| WaitCheck
    WaitCheck{Overlaps 3-day wait?} -->|Yes, not exempt| BlockedWait([Blocked: 3-day wait])
    WaitCheck -->|No or exempt| IssueDate{Issue date valid<br>and working day?}
    IssueDate -->|No| BlockedIssue([Blocked: invalid issue date])
    IssueDate -->|Yes| SplitFY[Split periods crossing<br>July 1 fiscal boundary]
    SplitFY --> AutoPayee[Auto-add/remove support<br>and recovery payees]
    AutoPayee --> Allocate[Allocate benefit amount;<br>worker absorbs remainder]
    Allocate --> MinAmt{Total >= $1.00<br>or exactly $0?}
    MinAmt -->|No| BlockedMin([Blocked: below minimum])
    MinAmt -->|Yes| Reserve{Within reserve limits?}
    Reserve -->|No| BlockedReserve([Blocked: reserve exceeded])
    Reserve -->|Yes| Dup{Matches existing<br>TD transaction?}
    Dup -->|Yes| BlockedDup([Blocked: duplicate payment])
    Dup -->|No| Approve[Approval warnings for<br>reduction ceilings]
    Approve --> Post[Post via Payment posting<br>and totals management]
    Post --> Done([TD payment released])

Failure and edge-case behavior

  • The reserve check exempts own-motion reimbursable claims entirely — a schedule for such a claim can be created even without sufficient reserve balance.
  • Rounding of non-worker payee percentages always favors making the worker's share absorb residual cents, which is intentional but means the worker payee amount is not simply "percentage times total" — it is always the true remainder.
  • Automatic support/recovery payee maintenance runs during retrieval validation, so payee lists can change on a claim between one screen load and the next without any explicit user action, purely as a side effect of the claim's support-order or overpayment state changing elsewhere.
  • The duplicate-payment guard (TranExists) only applies to payments not loaded by payment ID — a payment being edited in place bypasses the check, which is consistent with editing an existing record rather than creating a new duplicate.
  • No dedicated SQL catalog entries were found for clsFederalTimelossPayment; its persistence path is inferred* rather than directly traced to a catalogued statement.

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\TimelossPayments\clsTimelossPaymentBase.vb
  • Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsTimelossPayment.vb
  • Business\SAIF.Business.Claim.Payment\Payments\TimelossPayments\clsFederalTimelossPayment.vb