Skip to content

Business function limit maintenance

A business function limit is a per-employee, per-business-function (adjuster, awards, CDA settlement, DCS settlement, federal settlement, penalty, TD payment, vocational), per-approval-type maximum dollar amount the employee is permitted to authorize. The collection is loaded as part of Claim authority initialization, scoped to either the reserves or payments business process, and edited/persisted as part of Claim authority save.

Field Value
Operation ID OP-003
Trigger clsClaimEmpBusFuncLimitCollection.GetReserveLimits / GetPaymentLimits (retrieve); Add(emplid, busProcessCode) (new row); collection or aggregate Save() (persist)
Inputs EmployeeEmplid, ClaimBusProcessCode, ClaimBusFunctionCode, ClaimAuthPurposeCode, MaxAmount, ExpDate, AuthorizedByEmplid
Outputs Populated clsClaimEmpBusFuncLimitCollection; persisted insert/update/delete of CL_CLAIM_EMP_BUS_FUNC_LIMIT rows; broken-rule errors on validation failure
Primary components clsClaimEmpBusFuncLimitCollection.GetReserveLimits, GetPaymentLimits, clsClaimEmpBusFuncLimit (CRUD lifecycle and business rules)
Entry point Business\SAIF.Business.Claim.Authority\clsClaimEmpBusFuncLimitCollection.vb, Business\SAIF.Business.Claim.Authority\clsClaimEmpBusFuncLimit.vb

Steps

  1. Retrieve the collection. GetReserveLimits(dpi, emplid) builds a Criteria fixed to the reserve business-process code and retrieves; GetPaymentLimits(dpi, emplid) does the same for the payments code. Both execute the same parameterized RetrieveSQL — filtered by EmployeeEmplid and BusinessProcessCode — and materialize one clsClaimEmpBusFuncLimit per row (SQL-015, CL_CLAIM_EMP_BUS_FUNC_LIMIT).
  2. Add a new limit row. Add(emplid, busProcessCode) calls clsClaimEmpBusFuncLimit.NewClaimEmpBusFuncLimit, which allocates a sequence value via CL_CLM_EMP_BUS_FUN_LIM_SEQ.NEXTVAL (SQL-001) and defaults the new row: the acting employee (from data-portal UserID) becomes AuthorizedByEmplid, MaxAmount is 0, and the business function/process/purpose codes default to Adjuster/Reserve/All for reserves or Awards/Payments/InitiateAndRelease for payments.
  3. Set the maximum amount. Editing MaxAmount marks the row dirty and, on the next IsValid check, runs ValidAmountMin — the amount must be greater than zero (BR-003).
  4. On failure: error "Maximum limit must be greater than zero."
  5. Set the expiration date. Editing ExpDate runs ValidExpDate — an empty expiration date is allowed, but a populated one may not be in the past (BR-004).
  6. On failure: error "Expiration date may not be in the past."
  7. Check the grantable amount against the acting employee's own ceiling. ValidAuthorizeAmount runs whenever the row is dirty and IsSecurityOverride is not set (BR-005):
  8. If ClaimBusProcessCode is the reserve code: delegate to the parent clsClaimAuthority.CanAuthorizeReserves(busFunctionCode, authPurposeCode, maxAmount).
  9. Otherwise: delegate to clsClaimAuthority.CanAuthorizePayment(busFunctionCode, authPurposeCode, maxAmount).
  10. See Authorization amount and approval-type checks for the inline scalar-query logic behind both calls.
  11. On failure: error "You are not authorized to grant this amount."
  12. Reject duplicate function/approval-type combinations. DuplicateFunctionCode runs whenever ClaimBusFunctionCode changes and the row is not deleted; it scans sibling (non-deleted, non-self) rows in the same collection for a matching ClaimBusFunctionCode + ClaimAuthPurposeCode pair (BR-006). This check is purely in-memory and issues no SQL.
  13. On failure: error "May not have multiple rows with the same Function and Approval Type."
  14. Check the approval type against the acting employee's own ceiling. ValidAuthorizeApprovalType runs whenever ClaimAuthPurposeCode changes and IsSecurityOverride is not set, delegating to clsClaimAuthority.CanAuthorizeApprovalType(busProcessCode, busFunctionCode, authPurposeCode) (BR-007). See Authorization amount and approval-type checks.
  15. On failure: error "You are not authorized to grant this Approval Type."
  16. Persist on save. Claim authority save step 5 first stamps AuthorizedByEmplid on every dirty row, then cascades Save():
  17. New row: insert binds all fields including the sequence-allocated key and default expiration date (SQL-004, CL_CLAIM_EMP_BUS_FUNC_LIMIT).
    • On a rows-affected value other than 1: error "Insert Failed".
  18. Changed row: update binds the same fields plus the key and UpdateNum (SQL-019, CL_CLAIM_EMP_BUS_FUNC_LIMIT).
    • On a rows-affected value other than 1: DB contention error.
  19. Removed row: delete binds the sequence key and UpdateNum (SQL-022, CL_CLAIM_EMP_BUS_FUNC_LIMIT).
    • On a rows-affected value other than 1: DB contention error.

Process flow

The following diagram visualizes retrieval, in-memory editing, and save for a business function limit row.

flowchart TD
    Start([Load or add a limit row]) --> Retrieve[Retrieve reserve or payment<br>limits for employee]
    Retrieve --> Edit[Caller edits MaxAmount,<br>ExpDate, function/purpose codes]
    Edit --> Rules{Rules pass?}
    Rules -->|Amount <= 0| ErrAmt([Amount error])
    Rules -->|Expired date| ErrExp([Expiration error])
    Rules -->|Amount exceeds own ceiling| ErrAuth([Own-ceiling error])
    Rules -->|Duplicate function/purpose| ErrDup([Duplicate error])
    Rules -->|Approval type exceeds own ceiling| ErrAppr([Approval-type error])
    Rules -->|All pass| Save[Save cascades from<br>Claim authority save]
    Save --> Rows{RowsAffected = 1?}
    Rows -->|Yes| Done([Row persisted])
    Rows -->|No| Contention([Insert/DB contention error added])

Failure and edge-case behavior

  • IsSecurityOverride bypasses both the amount ceiling (BR-005) and the approval-type ceiling (BR-007) checks, but is forced to False in production, so the bypass only takes effect in non-production environments.
  • The duplicate-function-code check (BR-006) only inspects rows currently in the same in-memory collection; it cannot detect duplicates against rows outside the loaded scope (for example, if only reserve limits were loaded, a payments-side duplicate would not be caught).*
  • IsValid on this object returns True whenever the row is not dirty, so an already-persisted row with stale data that has since become invalid (for example, an expiration date that has since passed) is not re-validated unless it is edited again.

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.Authority\clsClaimEmpBusFuncLimit.vb
  • Business\SAIF.Business.Claim.Authority\clsClaimEmpBusFuncLimitCollection.vb