Skip to content

Benefit schedule payment processing

When a claim change invalidates an in-flight benefit payment schedule — a date of injury, date of death, disability date, work status, weekly wage, support order, CDA, claim status, jurisdiction, claim decision, or a cancelled check — the calling application asks this operation to stop the schedule. The operation walks every schedule row on the claim that still has payments owed, decides per row whether the pending payment has already been released to the payment system, and either truncates the schedule to a single remaining payment or deletes the scheduled payment outright. It then records an adjuster task describing what changed and what remains to be reviewed.

Three near-identical business objects implement this behavior against the same CL_BENEFIT_SCHEDULE table and are documented together because they share one Criteria contract, one set of SQL statements, and one control flow: clsBenefitSchedule (time-loss and federal schedules, with task posting), clsActiveBenefitSchedule (the same flow extended for claim-adjustment cancel-check callers), and clsFederalBenefitSchedule (retrieve, update, and delete only, without the stop-payment routine).

Field Value
Operation ID OP-BC-01
Trigger clsBenefitSchedule.ProcessBenefitPayment(claimID, mailID, callingApplication, callingFunction, postTaskForReleased) or clsActiveBenefitSchedule.ProcessBenefitPayment(claimID, callingApplication, callingFunction); the CRUD path is entered through GetBenefitSchedule / NewBenefitSchedule followed by Save()
Inputs ClaimID; BenefitPaymentSeqNum; the calling application and calling function enumerations; the adjuster mail ID for task assignment; a flag stating whether the caller posts its own task for released payments; RemainingPaymentCount, NextIssueDate, ReleasedPaymentCount, and UpdateNum for the CRUD path
Outputs Boolean indicating that at least one schedule row was processed; truncated or deleted schedule and payment rows; a claim task for the adjuster; error messages #PAYUPD#, #PAYDEL#, UpdateError, DeleteError
Primary components clsBenefitSchedule.ProcessBenefitPayment, clsBenefitSchedule.RetrieveBenefitPayments, clsBenefitSchedule.ReturnTask, clsActiveBenefitSchedule.ProcessBenefitPayment, clsFederalBenefitSchedule
Entry point Business\SAIF.Business.Claim\clsBenefitSchedule.vb

Steps

  1. Record the caller context. ProcessBenefitPayment stores the calling application (Overpayments, Claim Maintenance, Claim Payment, or — in clsActiveBenefitSchedule only — Claim Adjustments) and the calling function (date of death, date of injury, date of disability, support order, work status, weekly wage, CDA, claim status, jurisdiction, and in clsActiveBenefitSchedule also claim decision and cancel check). These two values drive only the wording of the task text produced in step 8.
  2. Prepare the task generator. clsBenefitSchedule immediately constructs a claim task generator for the claim so a task can be added later; clsActiveBenefitSchedule skips this because it never posts a task.
  3. Read the claim's outstanding schedules. RetrieveBenefitPayments opens its own portal request and runs the schedule query for the claim, restricted to rows whose remaining payment count is greater than zero, returning zero to many rows (CL_BENEFIT_SCHEDULE). This filtered variant of the schedule select is not catalogued separately from the keyed retrieve (SQL-017, SQL-013).*
  4. If the result set is empty: the operation returns False without touching any data.
  5. Loop the schedule rows. For each row returned, load the benefit payment sequence number, claim identifier, released payment count, remaining payment count, and update number into the object.
  6. Ask whether the pending payment was already released. The claim service counts financial transactions for the claim and benefit payment sequence number whose transaction status is released.
  7. Sub-step: build a scalar request against the financial transaction table filtered by claim identifier, benefit payment sub-number, and a financial transaction status code of 1.
  8. Sub-step: execute the request and return True when the count is greater than zero.

Origin: The released-payment check is implemented by ClaimServices.hasReleasedScheduledPayment in SAIF.Business and executed on behalf of this operation; see Claim information and authorization support. 6. Released branch — truncate the schedule. When a released payment exists, set the remaining payment count to 1, capture the current portal user as the update user, and run the partial schedule update that writes only the remaining payment count, SYSDATE, an incremented update number, and the update user, keyed on claim, sequence number, and the prior update number (BR-009, SQL-031, CL_BENEFIT_SCHEDULE). - If the affected row count is 0: add error #PAYUPD# — "The Payment Records for this Schedule were NOT succesfully updated." — and return False immediately, leaving any remaining schedule rows unprocessed (BR-008). - Otherwise: record the stop status as released, meaning a payment will still be issued unless the adjuster deletes it. 7. Unreleased branch — delete the scheduled payment. When no released payment exists, run the payment delete keyed on claim identifier and benefit payment sequence number; removal of the payment cascades to the schedule (BR-009, CL_BENEFIT_PAYMENT). This delete uses the same statement shape catalogued for the award benefit payment object (SQL-041).* - If the affected row count is 0: add error #PAYDEL# — "The Payment Records for this Schedule were NOT succesfully deleted." — and return False immediately (BR-008). - Otherwise: record the stop status as deleted. 8. Compose the task text. ReturnTask builds a sentence starting with "TD Payment Schedule stopped - ", appends the phrase matching the calling application and function (for example "date of injury ", "support order ", or "weekly wage "), appends "updated. ", then appends either "This schedule has been deleted. " or "There is a released payment that will be issued unless you delete it. " depending on the stop status, and closes with "Please review. ". - In clsActiveBenefitSchedule, a claim-adjustment caller contributes "check cancelled " or "claim decision " and the word "updated. " is suppressed. 9. Post the adjuster task. Unless the caller declared that it posts the task itself and the stop status is released, add a task for the claim addressed to the supplied mail ID with the composed text, due today with a zero day offset, and save it (BR-010). - Sub-step: the task generator rejects a claim identifier of zero with an application exception. - Sub-step: it creates a new claim task for the claim and acting user, resolving the responsible adjuster when no mail ID was supplied. - Sub-step: it shifts the due date forward by the supplied day offset, falling back to the previous working day when the offset lands on a non-working day. - Sub-step: saving the generator saves the underlying claim task collection.

Origin: Steps 9.1–9.4 are implemented by clsClaimTaskGenerator.AddTask and clsClaimTaskGenerator.Save in SAIF.Business.Tasks.Claim and executed on behalf of this operation. That library is documented in the previous format, so no per-operation page exists; see Operations and processes in the SAIF.Business.Tasks.Claim documentation set. 10. Return the outcome. After the loop, the function returns True when at least one schedule row was processed, otherwise False. 11. CRUD path — retrieve a single schedule. GetBenefitSchedule (or the federal equivalent) fetches one schedule row by benefit payment sequence number and claim identifier and fills the object; nothing is reported when no row matches (SQL-013, SQL-017, SQL-022, CL_BENEFIT_SCHEDULE). 12. CRUD path — update a schedule. Save() accepts changes and runs the full schedule update, writing the next issue date, released and remaining payment counts, SYSDATE, an incremented update number, and the update user, keyed on the prior update number (SQL-029, SQL-031, SQL-036, CL_BENEFIT_SCHEDULE). - If exactly one row is not affected: add UpdateError carrying the framework database contention message (BR-008). 13. CRUD path — delete a schedule. The delete removes the schedule row by benefit payment sequence number and claim identifier (SQL-040, SQL-042, SQL-046, CL_BENEFIT_SCHEDULE). - If exactly one row is not affected: add DeleteError with the message "Delete Failed" (BR-008). - Otherwise the object is marked new so it is treated as unsaved from that point on. 14. Create and insert are refused. All three objects raise an application exception from their create and insert SQL properties, so a benefit schedule can never be originated through this library.

Process flow

The following diagram visualizes this operation's control flow for one claim.

flowchart TD
    Start([Caller stops the payment schedule<br>after a claim change]) --> Read[Read schedules for the claim<br>with remaining payments above zero]
    Read --> Any{Any rows?}
    Any -->|No| NoRows([Return False;<br>nothing changed])
    Any -->|Yes| Row[Load next schedule row]
    Row --> Rel{Released financial<br>transaction exists?}
    Rel -->|Yes| Trunc[Set remaining count to 1<br>and update the schedule]
    Rel -->|No| Del[Delete the scheduled<br>benefit payment]
    Trunc --> URows{Rows affected = 0?}
    Del --> DRows{Rows affected = 0?}
    URows -->|Yes| PayUpd([Add PAYUPD error;<br>return False])
    DRows -->|Yes| PayDel([Add PAYDEL error;<br>return False])
    URows -->|No| StatusR[Stop status = released]
    DRows -->|No| StatusD[Stop status = deleted]
    StatusR --> Task{Caller posts its own task<br>for released payments?}
    StatusD --> Compose[Compose task text from<br>calling application and function]
    Task -->|Yes| Next{More schedule rows?}
    Task -->|No| Compose
    Compose --> Add[Add and save adjuster task]
    Add --> Next
    Next -->|Yes| Row
    Next -->|No| Done([Return True])

Failure and edge-case behavior

  • A zero row count on either the truncate or the delete aborts the whole loop, so schedules later in the result set are left untouched and the claim can be left partially stopped.
  • The stop-payment path validates nothing before writing: neither object registers a business rule, so the caller alone decides that the schedule should be stopped.
  • clsActiveBenefitSchedule performs the same data changes as clsBenefitSchedule but posts no adjuster task at all, so a claim-adjustment caller must create its own follow-up.
  • Task suppression applies only when the payment was released; a deleted schedule always produces a task regardless of the caller's preference.
  • The Save() override on all three objects returns True unconditionally and discards the framework save result, so callers must inspect the error collection rather than the return value.*
  • Retrieval returns an unfilled object rather than an error when no schedule matches the supplied keys, so callers must check the populated state themselves.
  • The task text is assembled from a fixed phrase table, so a calling application or function outside the enumerated set contributes no descriptive fragment and the adjuster receives a generic sentence.
  • clsFederalBenefitSchedule shares the schedule table and statement shapes but has no stop-payment routine, no released-payment check, and no task generation, so federal schedules stopped through that object leave no adjuster trail.

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\clsBenefitSchedule.vb
  • Business\SAIF.Business.Claim\clsActiveBenefitSchedule.vb
  • Business\SAIF.Business.Claim\clsFederalBenefitSchedule.vb
  • Business\SAIF.Business\ClaimServices.vb
  • Business\SAIF.Business.Tasks.Claim\clsClaimTaskGenerator.vb