Skip to content

Claim adjustment — void, combine, transfer, restore

Claim adjustment is a single business object with four mutually exclusive modes. The caller selects one adjustment action, populates the context that action needs, lets the action-specific rule set validate the request, and then calls Save(), which dispatches to the matching Oracle stored function in PK82140_CLAIM_ADJUSTMENTS. Void, combine, and restore each issue one call; transfer loops over a collection of claims and stops at the first failure.

Field Value
Operation ID OP-CM-03
Trigger Caller sets AdjustmentAction (or the SetAdjustmentProperty shortcut V, C, T, R), populates the associated context objects, and calls Save() after confirming IsValid
Inputs Adjustment action selector; current claim (ClaimID, ClaimUpdateNum, WorkerID, ClaimStatus); combine claim number and resolved claim for combine; transfer-to worker and claim collection for transfer; the claim's own worker for restore; acting user from the data-portal info
Outputs Boolean success (ErrorCount = 0); rows-affected return value from each stored function; broken rules, error messages, and warnings; persisted state changes executed inside the Oracle package
Primary components clsClaimAdjustment.Save, clsClaimAdjustment.IsValid, clsClaimAdjustment.AddBusinessRules, clsClaimAdjustment.RetrieveWorker, clsClaimAdjustment.NearbyClaimExists
Entry point Business\SAIF.Business.Claim.Maintenance\clsClaimAdjustment.vb

Steps

  1. Select the adjustment type. The caller assigns AdjustmentAction — Void, Combine, Transfer, or Restore. Because the action is a single enum field, only one flow can ever run per call (BR-CM-007).
  2. Initialize the object. Create() seeds the current claim from the criteria and clears the combine claim and transfer collection for a fresh instance.
  3. Dispatch validation (IsValid). The broken-rule collection is cleared and CheckRules is invoked with the rule-set key matching the selected action — the void rule set alone for Void, void plus combine for Combine, transfer-worker plus transfer-claim for Transfer, and restore for Restore — so only the relevant rules run (BR-CM-007).
  4. Return the validation verdict. IsValid returns ErrorCount = 0. Callers are expected to check it before calling Save(); Save() does not call IsValid itself.*
  5. Set up the save. Save() calls AcceptChanges(), obtains a fresh portal request and data request from the data-portal info, and branches on the selected action.
  6. Void — validate. The void rule set requires an active claim status, no legal case for the claim, no incurred costs, and no released or unposted payment; each check delegates to a claim service and adds an error message when it fails.
  7. Sub-step: the claim services resolve legal-case existence, incurred costs, and non-posted payments for the claim identifier and return booleans consumed directly by the rules.

Origin: The legal-case, incurred-cost, and payment existence checks are implemented by the claim service classes in SAIF.Business.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.Claim documentation set. 7. Void — execute. The request is configured as a scalar stored-procedure call to PK82140_CLAIM_ADJUSTMENTS.VoidClaim, binding the claim identifier, current update number, acting user, and a rows-affected return parameter (SQL-085, CL_INJURY_CLAIM) (BR-PROC-001). - On a rows-affected value of 0: add UpdateError with the DB contention message (step 14). 8. Combine — resolve the target claim. Setting CombineClaimNum immediately loads the target claim through the claim-data factory so the combine rules can inspect it. - Sub-step: the claim-data factory (clsClaimData.GetData) retrieves the claim identified by the given claim number and returns the populated claim data used by the combine validation in step 9.

Origin: The target-claim retrieval is implemented by clsClaimData.GetData in SAIF.Business.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.Claim documentation set. 9. Combine — validate. The combine rule set requires the target claim to be found and valid, to have an active status, to belong to the same worker, and to carry the same policy number as the current claim. 10. Combine — execute. The request calls PK82140_CLAIM_ADJUSTMENTS.CombineClaim, binding the current claim, the combine claim, the update number, the acting user, and the rows-affected return parameter (SQL-082, CL_INJURY_CLAIM) (BR-PROC-002). - On a rows-affected value of 0: add UpdateError with the DB contention message (step 14). 11. Transfer — resolve the target worker and claims. RetrieveWorker looks the worker up by worker identifier (SQL-030, CL_CLAIM_PERSON) or by primary tax identifier (SQL-031, CL_CLAIM_PERSON) and populates the worker structure; the caller populates the collection of claims to move. 12. Transfer — validate. The transfer rule sets require a target worker that differs from the current claim's worker and a worker identifier greater than zero. The per-claim rule then walks the transfer collection: - If a claim does not have an active status: add an error naming that claim. - If a support order exists for a claim: add an error naming that claim. - If another claim for the target worker falls within a fourteen-day window of the injury date: add a warning only, using an inline scalar query (SQL-029, CL_INJURY_CLAIM). 13. Transfer — execute per claim. Save() loops the transfer collection and, for each claim, calls PK82140_CLAIM_ADJUSTMENTS.TransferClaim with that claim's identifier and update number, the target worker, the acting user, and the rows-affected return parameter (SQL-084, CL_INJURY_CLAIM) (BR-PROC-003). - If the rows-affected value for a claim is 0: add UpdateError with the DB contention message and exit the loop immediately, leaving the remaining claims untransferred. 14. Restore — validate and execute. The restore rule set requires the current claim to be in void status — the inverse of the void precondition. The request then calls PK82140_CLAIM_ADJUSTMENTS.RestoreClaim with the claim identifier, the claim's own current worker, the update number, the acting user, and the rows-affected return parameter (SQL-083, CL_INJURY_CLAIM) (BR-PROC-003). - On a rows-affected value of 0: add UpdateError with the DB contention message. 15. Shared post-processing. For every action except Transfer, Save() reads the rows-affected parameter once after the single stored-function call and adds a DB contention error when it is 0; Transfer is excluded because it already performed the check per iteration. 16. Return the outcome. Save() returns ErrorCount = 0 as the overall success indicator.

Process flow

The following diagram visualizes this operation's control flow across the four mutually exclusive adjustment actions.

flowchart TD
    Start([Caller sets AdjustmentAction<br>and context objects]) --> Which{Which adjustment action?}
    Which -->|Void| VRules[Validate: active status,<br>no legal case, no incurred costs,<br>no released payment]
    VRules --> VOk{Rules pass?}
    VOk -->|No| Fail([Broken rules returned;<br>no package call])
    VOk -->|Yes| VCall[Call VoidClaim]
    Which -->|Combine| CLoad[Load combine claim]
    CLoad --> CRules[Validate: found, active,<br>same worker, same policy]
    CRules --> COk{Rules pass?}
    COk -->|No| Fail
    COk -->|Yes| CCall[Call CombineClaim]
    Which -->|Transfer| TLoad[Retrieve target worker<br>and transfer claims]
    TLoad --> TRules[Validate: different worker,<br>worker entered, each claim active,<br>no support order; nearby claim warns]
    TRules --> TOk{Rules pass?}
    TOk -->|No| Fail
    TOk -->|Yes| TLoop[For each claim:<br>call TransferClaim]
    TLoop --> TRows{RowsAffected = 0?}
    TRows -->|Yes| TAbort([Contention error added;<br>loop exits, partial transfer])
    TRows -->|No| TNext{More claims?}
    TNext -->|Yes| TLoop
    TNext -->|No| Done([Save returns ErrorCount = 0])
    Which -->|Restore| RRules[Validate: claim is in void status]
    RRules --> ROk{Rules pass?}
    ROk -->|No| Fail
    ROk -->|Yes| RCall[Call RestoreClaim]
    VCall --> Rows{RowsAffected = 0?}
    CCall --> Rows
    RCall --> Rows
    Rows -->|Yes| Contention([DB contention error added])
    Rows -->|No| Done

Failure and edge-case behavior

  • Mutual exclusivity is structural: the single enum plus the branch in Save() and the rule-set dispatch in IsValid make it impossible to run two adjustment types in one call (BR-CM-007).
  • If the adjustment action is left unset, no branch matches, no stored function runs, and the subsequent rows-affected read fails or returns a stale value; this path is not explicitly guarded.*
  • A rows-affected value of 0 is treated uniformly as a DB contention error across all four actions, but only Transfer has remaining work to abort.
  • The transfer per-claim rule adds error and warning messages directly instead of returning a boolean, so blocking depends entirely on whether errors were added; the fourteen-day nearby-claim check is explicitly a warning.
  • The combine rule flags a missing or invalid target claim as an error but does not prevent Save() from dereferencing it later, so callers must respect IsValid before saving.*
  • A duplicate transfer-worker rule function exists in source but is never registered, so it has no runtime effect.*
  • The factory requires valid claim data to construct the criteria; without claim context the object cannot be created at all.

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.Maintenance\clsClaimAdjustment.vb