SAIF.Business.Payment operations and processes¶

This page is the operation catalog and cross-operation hub for SAIF.Business.Payment. The library defines the IBankAccount and iPaymentPreference contracts and hosts three in-memory operations built on the claim-payee-eligibility business objects (clsEligPayeeClaim, clsEligPayeeClaimCollection): assembling the eligible-payee list for a claim, filtering that list by EFT payment channel, and creating a single bare payee record. None of the three operations executes live SQL — all persistence-shaped work is delegated to business objects and services in SAIF.Business.Claim.Person and SAIF.Business. Each operation's detailed, step-by-step logic lives in its own page under operations/.

Operation catalog¶

Operation	Intent	Trigger	Inputs	Outputs	Rules	Tables	SQL
Get eligible claim payees	Assemble a populated collection of eligible payees for a claim, applying worker death and beneficiary eligibility rules	`clsEligPayeeClaimCollection.getEligClaimPayees(inDataportal, inWorkerID, inIncludeForeignAddresses, inIncludeNonEligiblePayees, inClaimID)`	`IDataPortalInfo`, `inWorkerID`, `inIncludeForeignAddresses`, optional `inIncludeNonEligiblePayees`, optional `inClaimID`	Populated `clsEligPayeeClaimCollection`	BR-PAY-01, BR-PAY-03, BR-PAY-04, BR-PAY-05, BR-PAY-06, BR-PAY-07	None	SQL-001, SQL-002
EFT payment channel eligibility filtering	Filter an already-assembled payee collection into direct-deposit-eligible and debit-card-eligible subsets	Caller reads `DirectDepositEligible(inClaimID)` or `DebitCardEligible(inClaimID)` on a populated `clsEligPayeeClaimCollection`	Populated `clsEligPayeeClaimCollection`, `inClaimID`	Filtered `clsEligPayeeClaimCollection` (channel-specific subset)	BR-PAY-02	None	None
New eligible payee claim	Create a single in-memory eligible-payee record for a given person	`clsEligPayeeClaim.NewEligPayeeClaim(inDataportal, inPersonID)`	`IDataPortalInfo`, `inPersonID`	New `clsEligPayeeClaim` with `PersonID` populated	None	None	SQL-001

IBankAccount and iPaymentPreference are interface contracts, not operations — see API reference for their member signatures and Architecture for their role as component boundaries.

Process flow diagram¶

The following diagram shows how the three operations relate: a caller assembles the eligible-payee collection for a claim, optionally narrows it by payment channel, and the worker-record creation step is itself reused internally by the assembly operation.

flowchart TD
    Start([Caller needs claim payees]) --> Get[Get eligible claim payees]
    Get --> Worker[Retrieve worker via SAIF.Business.Claim.Person]
    Get --> Benes[Retrieve beneficiaries via SAIF.Business.Claim.Person]
    Get --> Addrs[Retrieve addresses via SAIF.Business.Claim.Person]
    Worker --> NewPayee[New eligible payee claim<br>worker payee record]
    Benes --> NewPayee2[New eligible payee claim<br>beneficiary payee records]
    NewPayee --> Assembled[Populated collection returned]
    NewPayee2 --> Assembled
    Assembled --> Filter{Caller needs channel-specific subset?}
    Filter -->|Yes| EFT[EFT payment channel eligibility filtering]
    EFT --> Lookup[GetEFTAuthorizationType via SAIF.Business]
    Lookup --> Filtered([Direct-deposit or debit-card eligible subset])
    Filter -->|No| Done([Full collection used as-is])

Inherited operations and processes¶

Operations in this section originate from base classes or services provided by dependency framework libraries. They are delegated to, not implemented in this library.

From `clsWorker`, `clsBeneficiaryCollection`, `clsClaimPersonAddressCollection` (`SAIF.Business.Claim.Person`)¶

Operation	Intent	Provided by	Origin	Embedded in
Worker profile management	Retrieve and persist the injured-worker profile via `CCClaimDataApi`†	`clsWorker`	`SAIF.Business.Claim.Person`	Get eligible claim payees
Beneficiary management	Retrieve beneficiary contacts for a worker and lazy-load eligibility/address/guardian data†	`clsBeneficiaryCollection`	`SAIF.Business.Claim.Person`	Get eligible claim payees
Claim-person address management	Retrieve and persist home, mailing, and payment addresses via the worker-address API†	`clsClaimPersonAddressCollection`	`SAIF.Business.Claim.Person`	Get eligible claim payees

Origin: These operations are defined in SAIF.Business.Claim.Person and consumed by this library. Their step-by-step logic is embedded inline (with > Origin callouts) in Get eligible claim payees.

From `EFTServices` (`SAIF.Business`)¶

Operation	Intent	Provided by	Origin	Embedded in
EFT authorization support	Resolve the current EFT authorization type (direct deposit, debit card, or not authorized) for a person†	`EFTServices`	`SAIF.Business`	EFT payment channel eligibility filtering

Origin: This operation is defined in SAIF.Business / EFTServices and consumed by this library. Its step-by-step logic is embedded inline (with an > Origin callout) in EFT payment channel eligibility filtering.

Database interactions¶

The following table summarizes which operations read from or write to the database. Per-step SQL and table citations live in each operation's detail page under operations/.

Operation	SQL	Tables	Type
Get eligible claim payees	SQL-002	None	Stub (never executed)
New eligible payee claim	SQL-001	None	Stub (never executed)

Neither SQL ID represents an executable statement: both are non-throwing RetrieveSQL property stubs that return a single-space string literal and are never sent to the database by any code path in this library. See SQL catalog and Database tables for details.

Failure and edge-case behavior¶

Get eligible claim payees returns only the blank placeholder payee when the worker ID does not resolve to an existing worker record.
Get eligible claim payees's inIncludeNonEligiblePayees flag overrides the worker death-date exclusion and every beneficiary eligibility check documented in Business rules.
EFT payment channel eligibility filtering always passes the blank placeholder payee (PersonID <= 0) through both filters unconditionally.
New eligible payee claim never populates any field besides PersonID; callers are responsible for setting all other display and eligibility fields.
Calling CreateSQL, DeleteSQL, InsertSQL, or UpdateSQL on either clsEligPayeeClaim.Criteria or clsEligPayeeClaimCollection.Criteria throws ApplicationException with the InvalidSQLProperty message; these operations are intentionally unsupported.

Note: Statements marked with † are derived from dependency library documentation via the Legends CLI. They describe inherited behavior from the indicated origin library and should be verified if the dependency version changes.

Sources¶

Business\SAIF.Business.Payment\clsEligPayeeClaim.vb
Business\SAIF.Business.Payment\clsEligPayeeClaimCollection.vb
Business\SAIF.Business.Payment\IBankAccount.vb
Business\SAIF.Business.Payment\IPaymentPreference.vb