Claim authority initialization¶
Claim authority initialization is the read path that assembles the full authorization picture for one employee within one business process (reserves or payments): the employee's own grant authority level, and the collections of business-function and category-change dollar limits that authority level allows them to grant to others. If the employee has never been granted an authority level, Create() seeds a default, in-memory CanNotAuthorizeOthers row rather than failing.
| Field | Value |
|---|---|
| Operation ID | OP-001 |
| Trigger | clsClaimAuthority.GetByMailID(dpi, mailId, busProcessCode) or GetByEmplID(dpi, emplId, busProcessCode) (also overloaded to accept the BusinessProcesses enum) |
| Inputs | EmplID or MailID, BusinessProcessCode ("1" reserves / "2" payments) or BusinessProcesses enum value |
| Outputs | Populated clsClaimAuthority with Employee, AuthorizingEmployee, GrantAuthority, AuthorizingGrantAuthority, BusinessFunctionLimits, and CategoryChangeLimits |
| Primary components | clsClaimAuthority.Create, clsClaimAuthority.GetByMailID, clsClaimAuthority.GetByEmplID |
| Entry point | Business\SAIF.Business.Claim.Authority\clsClaimAuthority.vb |
Steps¶
- Resolve the criteria.
GetByMailIDfirst resolves the mail ID to an employee record and builds aCriteriafrom the resolvedEmplIDand the business-process code (or enum);GetByEmplIDbuilds theCriteriadirectly from the supplied employee ID. Both overloads hand the criteria to the data portal, which invokesCreate().* - The employee lookup used by
GetByMailIDis provided byclsEmployeeDatain theSAIF.BOF.Businesspackage dependency; this library does not document that lookup's own operations.* - Load the subject employee.
Create()setsEmplIDfrom the criteria and retrieves the employee record viaclsEmployeeData.GetDataByEmployeeID, then derives the employee's mail ID (trimmed, upper-cased) for later use.* - Load the acting (authorizing) employee.
Create()resolves the caller's own employee record viaclsEmployeeData.GetDataByMailID, using the trimmed, upper-casedUserIDfrom the data-portal info. This is the employee whose own authority ceiling will later gate any changes (BR-002). - Load the acting employee's grant authority.
AuthorizingGrantAuthorityis populated viaclsClaimEmpAuthType.GetClaimEmpAuthType(dpi, businessProcessCode, authorizingEmployee.ID)(CL_CLAIM_EMP_AUTH_TYPE). - Load the subject employee's grant authority.
GrantAuthorityis populated the same way, keyed by the subject employee's ID (CL_CLAIM_EMP_AUTH_TYPE). - If the retrieved
GrantAuthorityis not valid (no row exists for this employee and business process):clsClaimEmpAuthType.NewClaimEmpAuthTypecreates a new, in-memory grant-authority object defaulted toCAN_NOT_AUTHORIZE_OTHERS. It is not persisted until Claim authority save runs. - Load the business function limits collection. If the resolved
ClaimBusProcessCode.IsReserveis true,clsClaimEmpBusFuncLimitCollection.GetReserveLimitsretrieves the reserve-scoped rows; otherwiseGetPaymentLimitsretrieves the payment-scoped rows for the same employee. Either call issues the same parameterized retrieve keyed by employee and business-process code. See Business function limit maintenance for the retrieval and per-row validation detail. - Load the category change limits collection.
clsClaimEmpCatChangeLimitCollection.GetClaimEmpCatChangeLimitsretrieves all category-change-limit rows for the employee, independent of business process. See Category change limit maintenance for the retrieval and per-row validation detail. - Register children and mark clean.
AddChildObjectregisters the business function limits, category change limits, and grant authority as children of the authority aggregate, thenMarkClean()andMarkOld()reset dirty/new state so the freshly loaded object reports as unmodified until the caller edits it.
Process flow¶
The following diagram visualizes the initialization sequence.
flowchart TD
Start([Caller requests authority<br>by mail ID or employee ID]) --> ResolveEmp[Load subject employee]
ResolveEmp --> ResolveAuth[Load acting/authorizing employee]
ResolveAuth --> LoadAuthGrant[Load acting employee's<br>grant authority]
LoadAuthGrant --> LoadGrant[Load subject employee's<br>grant authority]
LoadGrant --> GrantExists{Grant authority row exists?}
GrantExists -->|No| NewGrant[Create in-memory default:<br>CanNotAuthorizeOthers]
GrantExists -->|Yes| Limits
NewGrant --> Limits[Determine business process]
Limits --> Reserve{IsReserve?}
Reserve -->|Yes| ResLimits[Load reserve<br>business function limits]
Reserve -->|No| PayLimits[Load payment<br>business function limits]
ResLimits --> CatLimits[Load category<br>change limits]
PayLimits --> CatLimits
CatLimits --> Clean[Register children;<br>MarkClean, MarkOld]
Clean --> Done([Populated clsClaimAuthority<br>returned to caller])
Failure and edge-case behavior¶
- A missing grant-authority row is not an error: the object is initialized in-memory with the most restrictive authority (
CanNotAuthorizeOthers) rather than raising an exception. - If the acting employee cannot be resolved from the data-portal's
UserID(for example, the caller's mail ID does not match any employee), the subsequentAuthorizingGrantAuthoritylookup would operate against an invalid employee ID; this path is not explicitly guarded inCreate().* BusinessProcessCodeand theBusinessProcessesenum are two representations of the same value; passing an inconsistent pair across the twoGetBy*overloads is not defended against beyond the code-map lookup performed in theCriteriaconstructor.
Related documentation¶
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\clsClaimAuthority.vbBusiness\SAIF.Business.Claim.Authority\clsClaimEmpAuthType.vbBusiness\SAIF.Business.Claim.Authority\clsClaimEmpBusFuncLimitCollection.vbBusiness\SAIF.Business.Claim.Authority\clsClaimEmpCatChangeLimitCollection.vbBusiness\SAIF.Business.Claim.Authority\clsClaimBusProcessCode.vb