---
title: New eligible payee claim
summary: Creates a single in-memory eligible-payee record for a given person ID through the BOF factory pathway, without executing any live SQL.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Payment
reference_type: package
operation_id: OP-PAY-03
trigger: Caller invokes clsEligPayeeClaim.NewEligPayeeClaim with a person ID
---

# 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](get-eligible-claim-payees.md) 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](../sql/SQL-001-saif-business-payment.md)).
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.

```mermaid
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](get-eligible-claim-payees.md), which populates these fields from the retrieved worker or beneficiary object after calling this factory).

## Related documentation
- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

> **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`