---
title: Expense status worklist
summary: Retrieves the EAIP expenses currently sitting in a given status, optionally narrowed to one specialist, through the EAIP integration API.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.EAIP
reference_type: package
operation_id: OP-EAIP-05
trigger: Caller calls clsExpenseByStatus.GetExpenseList(dpi, status, eaipUser)
---

# Expense status worklist

Supervisors and specialists work their queues by status: everything pending approval, everything ready to pay, everything in check status. This operation supplies those queues. Unlike the rest of the library it does not use the Oracle package or the data portal at all — it calls the EAIP integration REST API, deserializes the response into flat projection objects, and returns them as a read-only list. There is no save path, no rule set, and no concurrency handling, because nothing here is editable.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-EAIP-05 |
| **Trigger** | Caller invokes `clsExpenseByStatus.GetExpenseList(dataPortal, status)` or `GetExpenseList(dataPortal, status, eaipUser)`; the specialist argument defaults to `ALL` |
| **Inputs** | `IDataPortalInfo` (supplies the API access layer and the configured `EaipApi` client), an expense status code, and an optional EAIP specialist mail identifier |
| **Outputs** | A `clsExpenseByStatusList` of projections carrying expense identifier, claim number, worker name, specialist, expense type description, description, paid amount, status date, and credit-card date; an empty list when the API returns no records |
| **Primary components** | `clsExpenseByStatus` (`GetExpenseList`, `Criteria.ConfigureRoutes`), `clsExpenseByStatusList` (`AddToList`) |
| **Entry point** | `Business\SAIF.Business.Claim.EAIP\Period\clsExpenseByStatus.vb` |

## Steps

1. **Build the criteria.** `GetExpenseList` constructs an API criteria from the data portal. The criteria derives from the API criteria base rather than the database criteria base, which is what routes this operation away from the Oracle package.
2. **Configure the route.** `ConfigureRoutes` resolves the configured API client under the key `EaipApi` for the `Integration` controller and registers one retrieve route with the pattern `V1/Integration/SelectExpensesByStatus/?ExpenseStatus={0}&Specialist={1}`.
3. **Format the request.** The criteria formats that route with the requested status code and specialist, producing a fully-qualified query string. When the caller supplies no specialist, the literal `ALL` is substituted, which the service interprets as "every specialist" rather than as a user named `ALL`.*
4. **Call the service.** The data portal's API access layer processes the request and returns an array of `clsExpenseByStatus` instances deserialized from the response body. The underlying data is produced server-side by the EAIP integration service, which is the API face of the package routine that selects expenses by status ([Details](../procedures/pk82500_eaip.md#selectexpensesbystatus_gw)).
5. **Project into the list.** When the result array is non-empty, each record is appended to a `clsExpenseByStatusList` through `AddToList`. Every property on the projection is a plain read/write field with no change tracking, no smart-type wrapping, and no code-table resolution — the expense type and status arrive from the service already described in text.
6. **Return.** The populated list (or an empty one) is returned. The caller is expected to use the expense identifiers on the rows to open the underlying purchase or wage subsidy through [Expense lifecycle and payment approval](expense-lifecycle.md) when action is required; the worklist itself carries no behavior.

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([Caller requests a status queue]) --> Crit[Build API criteria<br>from the data portal]
	Crit --> Route[ConfigureRoutes resolves the<br>EaipApi client for Integration]
	Route --> Fmt[Format route with status<br>and specialist, defaulting to ALL]
	Fmt --> Call[API access layer processes<br>the retrieve request]
	Call --> Any{Any records returned?}
	Any -->|No| Empty([Empty list returned])
	Any -->|Yes| Add[Append each record<br>to the projection list]
	Add --> Done([Read-only worklist returned])
```

## Failure and edge-case behavior

- The operation registers no business rules — the rule-registration method is deliberately empty — and performs no validation on the status code it is given. An unrecognized status simply returns nothing rather than raising an error.*
- Nothing here writes. The projection has no criteria statements, no save path, and no update number, so a worklist row cannot be used to change an expense; the caller must load the real expense object to act.
- The list is a point-in-time snapshot taken from a remote service. Rows can be stale by the time the user acts on them, and the operation provides no refresh or change notification.*
- Failures of the remote service surface as whatever the API access layer raises; this class adds no try/catch, no retry, and no fallback to a database query, so an unavailable service means an unavailable worklist.*
- The specialist and status values are interpolated into a query string. Values containing reserved URL characters are passed through as-is by this code, so correctness depends on the API client's own encoding.*

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.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.EAIP\Period\clsExpenseByStatus.vb`
- `Business\SAIF.Business.Claim.EAIP\Period\clsExpense.vb`