Track requests
The Spend list — finding a request, filtering it down, and working several at once.
The Spend list at /payment-requests is where every request the business has raised can be found, filtered and worked. It is the surface administrators live on.
Rows are lines, not requests
A request with three lines shows as three rows. That is deliberate: reviewing, approving, declining and posting all happen per line, so the list is drawn at the grain decisions are made at.
| Column | Shows |
|---|---|
| Request Date | When the request was raised. Always shown. |
| Request No | The reference. |
| Employee | Who raised it. |
| Type | Payment, Requisition or Advance. |
| Status | Where this line has got to. |
| Purpose | What it is for. Long text is trimmed; hover for the whole of it. |
| Amount | The line amount, right-aligned. |
Clicking anywhere on a row opens the request page. Columns hides any column except Request Date.
Narrowing it down
Three controls sit above the table, and the rest live in the Filter drawer.
| Control | Where | Notes |
|---|---|---|
| Period | Above the table | The primary filter for a dated list. Defaults to All time. |
| Workflow | Above the table | All workflows · Payment Requests · Requisitions · Advances, each carrying how many rows match your current filters. |
| Status | Above the table | One status at a time. It also drives the address bar, so a filtered list can be bookmarked and shared. |
| Employee | Filter drawer | Pick one or more requesters. |
| Amount | Filter drawer | A minimum, a maximum, or both. |
| Search | The toolbar | Purpose, beneficiary name, request number and requester. It waits for you to stop typing before it queries. |
The drawer carries a control for every filterable column, and the promoted controls above the table are the same filters — change one and the other follows. Nothing is filtered in your browser: the server does the filtering, the counting and the paging, so what the header says is genuinely how many there are.
The Employee facet offers the requesters visible on the page you are on, plus anyone you have already picked — so a chosen name never disappears when you turn the page. If the person you want is not offered, widen the period or search for their name instead.
Page size is yours to choose and is remembered between visits. Paging is numbered, with the first and last page always one click away.
Working several at once
Tick rows and a bar appears above the table: Review · Approve · Decline · Post · Delete. It is shown to administrators only.
| Action | Notes |
|---|---|
| Review · Approve · Decline | Opens a confirmation listing exactly what you are deciding, with one optional note visible to the requester. See Approve a request. |
| Post | Only approved rows can be posted. Anything else in the selection and you are told, rather than half the selection posting. See Post a payment. |
| Delete | Confirmed first, and permanent. A request with several selected lines is deleted once, not once per line. |
Selections survive turning the page, so you can gather rows across several pages before acting.
Exporting
Export produces the list as a PDF (a formatted, print-ready report) or Excel (a workbook with every request line). Both follow the status filter you have set, so what you export is what you were looking at.
The other two destinations
| Tab | Who sees it | Shows |
|---|---|---|
| Requests | Everyone with Spend | The list itself. Status is a filter on it, never a separate tab. |
| Insights | Administrators | The Spend report — see Spend insights. |
| Payment Team | Administrators | Who reviews, approves and posts, plus the approval rules. |
If you only raise requests
Someone whose only reach into the app is Spend does not get this table at all. They land on Spend home: a greeting, their own totals — waiting on approval, approved, paid — one-tap shortcuts to raise each kind of request, their outstanding advances, a six-month trend of what they have raised, and their recent requests.
Both landings read the same data, scoped on the server to what the person is allowed to see.
A Staff user sees only their own requests, wherever they look. That is enforced when the data is read, not by the screen.
When it will not load
An error shows Couldn't load requests with the reason and a Try again button — the list never silently shows an empty table in place of a failure. An empty result tells you which it is: No requests match these filters when something is filtered, No requests yet when nothing has been raised.
Related
- The request page — where a row takes you
- Approve a request · Post a payment
- Spend insights — the same data as a report
- Spend — the whole module