---
title: Claim list generation
summary: Executes a caller-supplied query and turns its rows into a reusable, sortable collection of claim identifiers and SAIF claim numbers.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim
reference_type: package
operation_id: OP-BC-10
trigger: A caller supplies a SQL statement and a bind value and requests the resulting claim list through GetClaimListCollection
---

# Claim list generation

Many claim screens and batch processes need the same thing: a list of claims produced by some caller-specific query, presented as claim identifiers and formatted SAIF claim numbers. Rather than each caller writing its own collection plumbing, this operation accepts the caller's own SQL statement and a single bind value, executes it, and hydrates a sortable, searchable collection of claim list items whose column names the caller may also override.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-BC-10 |
| **Trigger** | `clsClaimListGenerator.GetClaimListCollection(dataPortalInfo, sqlStatement, id, requestID)` or the overload accepting a fully populated Criteria |
| **Inputs** | The SQL statement to execute; the single bind value named `ID`; an optional request identifier; optional column-name overrides for the claim identifier, claim number, check character, and worker identifier columns |
| **Outputs** | A `clsClaimListCollection` of claim list items, each exposing a claim identifier, claim number, check character, worker identifier, and the concatenated SAIF claim number |
| **Primary components** | `clsClaimListGenerator.Criteria`, `clsClaimListGenerator.BeforeRetrieve`, `clsClaimListGenerator.AfterRetrieve`, `clsClaimListCollection`, `clsClaimListItem` |
| **Entry point** | `Business\SAIF.Business.Claim\clsClaimListGenerator.vb` |

## Steps

1. **Capture the caller's query.** The factory builds a Criteria holding the SQL statement text, the bind value, and an optional request identifier; a second overload accepts a Criteria the caller has already populated, which is the route used when column names need overriding.
2. **Configure the request.** `BeforeRetrieve` sets the data request identifier from the criteria — defaulting to the generator's own name when the caller supplied none — installs the caller's SQL statement as the statement text, and binds the single parameter named `ID` to the caller's value. No statement is catalogued for this operation because the text originates entirely with the caller.*
3. **Hydrate the collection.** `AfterRetrieve` walks the data reader and, for each row, constructs a claim list item populated from four columns whose names come from the criteria: the claim identifier, claim number, claim check character, and worker identifier columns, defaulting to those same names when the caller did not override them.
4. **Build the SAIF claim number.** Each item concatenates its claim number and check character value into the displayable SAIF claim number so callers never assemble it themselves.
5. **Use the collection.** The resulting collection supports adding, removing, sorting, and finding items, so callers can filter or reorder the list in memory without returning to the database.
6. **All persistence is refused.** The Criteria raises an application exception from its create, insert, update, delete, and retrieve SQL properties — the retrieve statement is supplied at runtime instead — so a claim list can never be written back.

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([Caller supplies a SQL statement<br>and a bind value]) --> Cfg[Set the request id and install<br>the caller's statement text]
	Cfg --> Bind[Bind the single ID parameter]
	Bind --> Exec[Execute the query]
	Exec --> Loop{More reader rows?}
	Loop -->|Yes| Item[Read the four configured columns<br>into a claim list item]
	Item --> Num[Concatenate claim number<br>and check character]
	Num --> Loop
	Loop -->|No| Done([Return the sortable<br>claim list collection])
```

## Failure and edge-case behavior

- The statement text is supplied entirely by the caller and is neither validated nor parameterized beyond the single `ID` bind, so statement correctness and injection safety rest with the caller.
- A statement whose result set does not expose the four expected column names fails inside the reader loop; the operation performs no column-presence check first.*
- Only one bind value is supported, so any query needing several filters must inline the remaining criteria into the statement text.
- An empty result set yields an empty collection with no error, so callers must distinguish "no claims" from "query wrong".
- The default request identifier is shared by every caller that does not supply one, which limits the usefulness of request-level diagnostics.*
- Sorting and filtering happen in memory after the full result set has been materialized, so a broad statement can produce a large in-memory collection.*

## 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.Claim\clsClaimListGenerator.vb`
- `Business\SAIF.Business.Claim\clsClaimListCollection.vb`
- `Business\SAIF.Business.Claim\clsClaimListItem.vb`