Skip to content

Work release management

A state-jurisdiction claim carries a work-release-status child object whose lifecycle must track the claim's own WorkReleaseCode and WorkReleaseDate header fields. This operation is the reconciliation logic in clsStateClaimEntry that decides, on every save, whether the child record needs to be created, updated, or removed to stay consistent with those header fields — the actual CRUD and validation for the child record itself is implemented by clsClaimWorkReleaseStatus in SAIF.Business.Claim.

Field Value
Operation ID OP-CE-08
Trigger clsStateClaimEntry.IsValid invokes UpdateWorkReleaseStatus as part of validating a state claim before save
Inputs WorkReleaseCode, WorkReleaseDate, the claim's deletion state, the existing work-release-status child object (if any)
Outputs A created, updated, or deleted clsClaimWorkReleaseStatus child object
Primary components clsStateClaimEntry.UpdateWorkReleaseStatus
Entry point Business\SAIF.Business.Claim.Entry\clsStateClaimEntry.vb

Steps

  1. Require presence when either field is set. If WorkReleaseCode or WorkReleaseDate is populated on the claim but no work-release-status child object exists yet, a broken rule is raised requiring the child record to be created before the claim can be considered valid (BR-CE-005).
  2. Reconcile the child record's lifecycle against the header fields (BR-CE-015):
  3. If the claim itself is being deleted: mark the work-release-status child object for deletion as well, so it does not outlive its parent claim.
  4. If both WorkReleaseCode and WorkReleaseDate are now blank and a child object exists: mark the child object for deletion, since there is no longer any work-release data to track.
  5. If a child object does not yet exist and either field is populated: create a new work-release-status child object and populate it from the claim's WorkReleaseCode/WorkReleaseDate.
  6. If a child object already exists and either field has changed: update the child object's code/date to match the claim header.
  7. Delegate the actual create/update/delete of the child row.

    Origin: clsClaimWorkReleaseStatus is implemented in SAIF.Business.Claim, which has been migrated to the current documentation format. Its sequence-number reservation, date validation, and insert/update/delete lifecycle are documented as Work status and work release tracking; this operation only reconciles when to invoke that lifecycle, not how the row itself is persisted.

  8. Persist the reconciled child object as part of the same Save() call that persists the claim header (see State insert extensions).

Process flow

flowchart TD
    Start([IsValid runs during<br>state claim save]) --> Presence{Code or date set<br>but no child object?}
    Presence -->|Yes| Broken([Raise broken rule:<br>child record required])
    Presence -->|No| DeleteCheck{Claim being deleted?}
    DeleteCheck -->|Yes| MarkDelete[Mark child object<br>for deletion]
    DeleteCheck -->|No| BlankCheck{Code and date<br>both now blank?}
    BlankCheck -->|Yes, child exists| MarkDelete2[Mark child object<br>for deletion]
    BlankCheck -->|No| ExistCheck{Child object exists?}
    ExistCheck -->|No| Create[Create new child object<br>from code/date]
    ExistCheck -->|Yes| Update[Update child object<br>code/date]
    MarkDelete --> Persist([Persist reconciled<br>child object])
    MarkDelete2 --> Persist
    Create --> Persist
    Update --> Persist

Failure and edge-case behavior

  • The requirement in step 1 is enforced only as a broken rule during validation, not as a database constraint — a caller that bypasses IsValid could still attempt a save with inconsistent header/child state.*
  • Deleting the parent claim cascades a delete to the work-release-status child object, but the underlying persistence of that delete depends on clsClaimWorkReleaseStatus's own optimistic-concurrency check (Rows affected = 1), documented in the Work status and work release tracking operation.
  • No orphan work-release-status rows are expected to be created directly against the database outside of this reconciliation path, since the child object's own sequence-number reservation only runs when this logic creates it.*

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.Entry\clsStateClaimEntry.vb