Skip to content

Manage liens and settlements

Liens (clsThrdpartyLien), lien categories (clsThrdpartyLienCategory), settlements (clsThrdpartySettlement), and settlement detail rows (clsThrdpartySettlementDetail) together model how recovery money is claimed against and distributed. Settlement validation is the most rule-rich of the four, reconciling the settlement total against the sum of its detail rows before allowing a save.

Field Value
Operation ID OP-TP-04
Trigger Retrieval or creation of a lien, lien category, settlement, or settlement detail object, followed by property edits and Save()
Inputs CaseSeqNum, lien date/amount, lien category fields, settlement amount/code/date, settlement detail category amount/code
Outputs Persisted THRDPARTY_LIEN, THRDPARTY_LIEN_CATEGORY, and settlement/settlement-detail rows scoped to THRDPARTY_CASE
Primary components clsThrdpartyLien.AddBusinessRules, clsThrdpartySettlement.AddBusinessRules, clsThrdpartySettlementDetail.AddBusinessRules
Entry point Business\SAIF.Business.Claim.ThirdParty\clsThrdpartyLien.vb

Steps

  1. Create or retrieve a lien. Retrieval reads a lien by case and sequence (SQL-058/SQL-057, THRDPARTY_LIEN).
  2. Validate the lien. Lien date is required (BR-021); an expense-amount-required rule exists in source but is commented out and is not registered, so it has no runtime effect.*
  3. Persist the lien via insert (SQL-003), update, or delete against THRDPARTY_LIEN.
  4. On a rows-affected value other than 1: an insert/update/delete error message is added.
  5. Create or retrieve a lien category. Retrieval reads categories by case (SQL-056, THRDPARTY_LIEN_CATEGORY). No business rules are registered for lien categories in source — validation, if any, is enforced entirely at the package level.*
  6. Persist the lien category via insert (SQL-027) or update (SQL-081).
  7. Create or retrieve a settlement. Retrieval reads a settlement by case and sequence (SQL-066, THRDPARTY_CASE).
  8. Validate the settlement (IsValid):
  9. The settlement amount must equal the sum of its own settlement detail rows (SettlementDtlTotal) (BR-022).
  10. While the settlement is dirty, the settlement amount must be greater than zero (BR-022).
  11. While the settlement is dirty, a settlement type code is required (BR-023).
  12. Settlement date is required, cannot be in the future, and must be a reasonable date (delegated to shared CommonBusinessRules.IsTTodayOrFutureDate / IsReasonableDate checks) (BR-023).
  13. Persist the settlement via insert (SQL-030) or update (SQL-084) against THRDPARTY_CASE.
  14. On a rows-affected value other than 1: an insert/update error message is added.
  15. Create or retrieve settlement detail rows scoped to a settlement (SQL-065).
  16. Validate settlement detail rows:
    • Category amount cannot be less than zero (BR-024).
    • Fund category code is required (BR-024).
  17. Persist settlement detail rows via insert (SQL-029) or update (SQL-083) against THRDPARTY_CASE.
    • When a caller adds, edits, or deletes a settlement detail row, the settlement total validation in step 7 re-runs the next time the settlement's IsValid is checked, so a detail-total mismatch blocks the settlement save even if each individual detail row is itself valid.

Process flow

The following diagram visualizes settlement-to-detail reconciliation, the most rule-driven path in this operation.

flowchart TD
    Start([Caller edits settlement<br>and detail rows]) --> DetailRules[Validate each detail row:<br>amount >= 0, category code required]
    DetailRules --> DetailOk{Detail rows valid?}
    DetailOk -->|No| Fail([Broken rules returned])
    DetailOk -->|Yes| Recalc[Recompute SettlementDtlTotal]
    Recalc --> SettleRules[Validate settlement:<br>amount = detail total,<br>amount > 0, type + date required]
    SettleRules --> SettleOk{Valid?}
    SettleOk -->|No| Fail
    SettleOk -->|Yes| Save[Insert or update settlement<br>and detail rows]
    Save --> Rows{RowsAffected = 1?}
    Rows -->|No| Contention([Insert/Update error added])
    Rows -->|Yes| Done([Changes persisted])

Failure and edge-case behavior

  • Because the settlement-total rule compares against the live detail total, editing a detail row after the settlement has already validated can invalidate the settlement on the next check without an explicit re-save trigger from the caller.*
  • The lien's expense-amount-required rule is fully commented out in source and never registered — the corresponding validation described in the class's TODO comments does not run.*
  • Lien categories have no BOF-level business rules registered; any category-level validation is enforced by the PK82033_THIRDPARTY package rather than the BOF class.*
  • A rows-affected value other than 1 on any insert/update/delete is treated as a DB contention failure rather than an exception (BR-005).

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.ThirdParty\clsThrdpartyLien.vb
  • Business\SAIF.Business.Claim.ThirdParty\clsThrdpartyLienCategory.vb
  • Business\SAIF.Business.Claim.ThirdParty\clsThrdpartySettlement.vb
  • Business\SAIF.Business.Claim.ThirdParty\clsThrdpartySettlementDetail.vb
  • Business\SAIF.Business.Claim.ThirdParty\clsThirdpartySettlDtlType.vb