Skip to content

New eligible payee claim

New eligible payee claim is the factory entry point that constructs a bare clsEligPayeeClaim object for a given person. It is used both directly by callers that already know a person ID and internally by Get eligible claim payees when it materializes the worker payee record. The object carries no independent persistence: every IBusinessCriteria write operation on it is intentionally disabled, and its declared RetrieveSQL is a non-executing stub.

Field Value
Operation ID OP-PAY-03
Trigger Caller invokes clsEligPayeeClaim.NewEligPayeeClaim(inDataportal, inPersonID)
Inputs IDataPortalInfo; inPersonID As Decimal
Outputs A new clsEligPayeeClaim object whose PersonID is populated; all other properties remain at their type defaults until the caller sets them
Primary components clsEligPayeeClaim.NewEligPayeeClaim, clsEligPayeeClaim.Create, clsEligPayeeClaim.Criteria
Entry point Business\SAIF.Business.Payment\clsEligPayeeClaim.vb

Steps

  1. Caller invokes the factory. NewEligPayeeClaim(inDataportal, inPersonID) is called with the data-portal context and the target person's identifier.
  2. Build the criteria. The factory constructs a Criteria(inDataportal, inPersonID) instance, which stores the data-portal info and the person ID on the nested Criteria class.
  3. Dispatch through the BOF factory scaffolding. The factory calls inDataportal.DataAccessLayer.CreateObject(New Criteria(...)), which routes to the Create() lifecycle rather than a database Retrieve() — no SQL statement is sent to the database for this call (SQL-001).
  4. Copy the person ID into the new object. The Create() override sets PersonID = MyCriteria.PersonID, so the only field populated by the factory itself is PersonID; every other property (Name, Address, dates, TaxID, etc.) remains at its class-level default until the caller sets it explicitly.
  5. Register business rules. The object's constructor calls AddBusinessRules(), but the override is empty in this class — no rule instances are actually registered.*
  6. Return the new object. The populated (person-ID-only) clsEligPayeeClaim is returned to the caller.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([NewEligPayeeClaim called<br>with PersonID]) --> Criteria[Construct Criteria with<br>DataPortalInfo and PersonID]
    Criteria --> Factory[DataAccessLayer.CreateObject]
    Factory --> Create[Create lifecycle:<br>PersonID = MyCriteria.PersonID]
    Create --> Rules[AddBusinessRules<br>no-op in this class]
    Rules --> Done([Return new clsEligPayeeClaim])

Failure and edge-case behavior

  • Criteria.CreateSQL, Criteria.InsertSQL, Criteria.UpdateSQL, and Criteria.DeleteSQL all throw ApplicationException(clsConstants.Messages.InvalidSQLProperty) if invoked; this object is not designed to be independently created, updated, or deleted against the database through the BOF SQL lifecycle.
  • Criteria.RetrieveSQL returns a single-space string literal rather than throwing, but no code path in this library or its callers issues a fetch/retrieve request against this criteria, so the stub is never exercised.
  • Because AddBusinessRules() is empty, IsValid on a freshly created object reduces to MyBase.IsValid with no local rule checks — validity is effectively determined by BOF base-class state alone, not by any payment-specific rule in this class.*
  • Callers must populate Name, Address, TaxID, and other display/eligibility fields themselves; the factory does not look up person data from any source — that responsibility belongs to the caller (as seen in Get eligible claim payees, which populates these fields from the retrieved worker or beneficiary object after calling this factory).

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.Payment\clsEligPayeeClaim.vb