Procurement analytics
Three things PTRS can do, and they are the exception to everything else in this module.
Looking up procurement analytics is the only one of the CACFP module's 251 things PTRS can do that narrows the rest of the module's rule to a smaller set of roles.
Who can do this
Reaching any of the three reports needs both the module's usual rule and a second, narrower one layered on top.
| Rule | Roles it admits |
|---|---|
| The module's usual rule | Staff, site director, regional director, organisation administrator, super admin |
| The narrower rule on these three reports | Site director, regional director, organisation administrator, super admin |
| Who can actually reach these three | Site director, regional director, organisation administrator, super admin |
A staff member reaches every other action in this module, including creating and approving a purchase order and approving a claim. See the module overview.
The one place this module draws a line is on three reporting reads. A staff member may create and approve a purchase order and may not see the spend report about it.
No screen, dialog or menu entry anywhere in PTRS reaches procurement analytics, vendor performance, or the spend report.
So the best-built reporting surface in the CACFP module, real arithmetic, kept warm for five minutes at a time so it does not have to be worked out fresh on every request, has never returned a figure to anybody, and the narrower rule has never actually excluded anybody either.
Procurement analytics for one site
| Figure | How it is worked out |
|---|---|
| Total spend | The total of orders marked Received |
| Total orders | The count of every order at the site, any status |
| Distinct vendors | Counted across every order, any status |
| Buy American rate | Compliant received orders divided by received orders, or 0 when there are none |
| Spend by category | Grouped by procurement method, over every order that is not Cancelled; each carries an amount, a count and a share of total spend |
| Monthly trend | Grouped by year and month of the order date, received orders only |
| Top vendors | The top 10 by received spend, each with a share of total spend |
| Site name | Always blank. Nothing fills it in |
Note the mismatch: spend by category adds up every order that is not cancelled, and divides by a total spend that counts only received orders. At a site with orders still pending, the percentages shown would add up to more than 100%.
Kept for five minutes at a time before being worked out again, with hits and misses on that five-minute memory counted for PTRS's own monitoring.
Vendor performance
Covers every vendor in the organisation, optionally narrowed to one site. Vendors with no orders are included, at zero.
| Figure | How it is worked out |
|---|---|
| Total vendors, active vendors | Counted directly; active means not deactivated |
| Share small-business, minority-owned, women-owned | Each flag's count divided by total vendors, as a percentage |
| Per-vendor total spend | The total of that vendor's received orders |
| Per-vendor total, received and cancelled order counts | Counted by status |
| Per-vendor on-time delivery rate | See below |
| Per-vendor Buy American rate | Compliant received orders divided by received orders |
On-time delivery is a fixed 14 days
An order counts as on time when it was received, has a delivery date, and that date is no later than 14 days after the order date.
The 14 days is a fixed number written into PTRS. It is not a per-vendor lead time, not a contract term, not something set anywhere, and it is not shown on any screen. The bottom of the fraction is the count of received orders that have a delivery date at all.
Two things make the resulting figure meaningless even if this report were connected to a screen:
- The delivery date is not the delivery date. Receiving an order stamps it as the day someone pressed Receive, not the day the food actually arrived. There is no field anywhere for when the delivery actually came, and the date a screen would send for it is thrown away.
- Nothing can press Receive. No screen calls the action that marks an order received, so no order ever reaches that status, and every figure here that depends on it is zero.
Also kept for five minutes at a time.
The spend report
Covers the whole organisation, optionally bounded by a start and end date against the order date, and received orders only.
| Figure | How it is worked out |
|---|---|
| Grand total | The total of every included order |
| Buy American total | The total of orders marked Buy American compliant |
| Non-Buy-American total | Grand total minus the Buy American total |
| Buy American percentage | The Buy American total divided by the grand total, to one decimal place, zero when the total is zero |
| Spend by site | Grouped by site, with a share of the grand total. Site ids only, no names |
| Spend by method | Grouped by procurement method, with a share of the grand total |
| Monthly trend | Grouped by year and month of the order date |
The Buy American percentage here reads a different flag from the one Buy American Compliance reads. The one this report uses is set by the New Order form's own checkbox, which defaults to checked. The one Buy American Compliance reads is a separate flag that is false on every row. The two Buy American percentages in the module are worked out from two different records and cannot be reconciled with each other.
The date filter compares against the order date, not the delivery date, so a report for a period reflects when orders were placed rather than when food was actually received or paid for.
Also kept for five minutes at a time.
What would have to be true for these to mean anything
All three read the same purchase-order records. Working back from the arithmetic, the chain is:
- A vendor must exist. Creating one is reachable and always fails, because the page sends a blank site.
- A purchase order must exist with a real amount. Creating one is reachable and always fails for the same reason, and the form collects no amount at all, so the page sends zero regardless.
- The order must be approved, then received. Neither action has a screen.
- Only then does a single figure on any of these three reports become non-zero, and no screen calls any of them anyway.
See Work the inventory and procurement screens for each of those steps in detail.
Where to go next
- Who can do what with menus and inventory, the other 64 things in this subset
- Work the inventory and procurement screens
- Roles and permissions, the full role-to-rule matrix
Checked against PTRS on 7 September 2026.