Who can do what with enrolment and records
Forty-one things PTRS can do around enrolment, eligibility, the older compliance record, offline sync, DENARS packages and closing a program year. PTRS can do 251 things in CACFP in total; the other two groups are on Who can do what with meals and claims (54, meal counting and the claim) and in the more advanced screens not yet documented in this portal.
Who can do this
Identical to the rest of the module: staff members, site directors, regional directors, organisation administrators and super admins, for every one of the forty-one things below. Nothing on this page narrows that further.
Approving a household income application, marking a site DDOE-approved, and closing a fiscal program year are all allowed for the front-line Staff role, because the module has exactly one rule covering everyone.
This is the same gap described on the module landing page. It is not being fixed as part of this documentation.
How to read "Reachable" below
A screen means a component or page calls it in normal use.
No screen reaches it means PTRS has the plumbing built for a screen to use this, and no screen does.
No screen was ever built for it means PTRS has no plumbing at all pointing toward a screen, nothing in the product can call it, even in principle, without someone with direct system access.
Eight of the forty-one have a screen. Thirty-three do not.
Enrolments
| Action | Reachable |
|---|---|
| Create an enrolment | The enrolment form |
| List enrolments | The enrolment list and its summary panel |
| Look up one enrolment | An enrolment's own detail page, reachable by nothing that links to it |
| Change an enrolment's tier or status | No screen was ever built for it |
| Withdraw a participant | No screen reaches it, it is built, and nothing calls it |
| List a site's enrolments a different way | No screen was ever built for it |
Filters on the list. Site, program year, status, and which page you are on. An unrecognised status is silently ignored rather than refused, so asking for a status PTRS does not have simply returns everything.
The by-site lookup is not a duplicate of the ordinary list filtered by site. It checks the site belongs to your organisation and refuses if not, narrows to Active only, and orders by the child's name rather than by creation date, the more useful of the two for a site roster, and the one with no screen.
Consequence of the four unreachable actions. An enrolment created through the interface can never have its tier corrected, can never be withdrawn, and cannot be deleted at all. See Enrol a participant.
Income applications
| Action | Reachable |
|---|---|
| Submit a household income application | No screen reaches it |
| List income applications | No screen reaches it |
| Look up one application | No screen was ever built for it |
| Approve an application | No screen reaches it |
| Deny an application | No screen reaches it |
All five of these are built completely, four of the five have the plumbing a screen would need, and not one has a screen using it.
Approving an application even quietly refreshes the enrolment list, as if anticipating a link between an approved application and an enrolment, a link that does not exist in PTRS.
So the household income application, the CACFP eligibility determination, can be created, approved and denied only by someone with direct system access.
Filters on the list. Site, program year, status, and which page you are on. Same silent-ignore behaviour on an unrecognised status.
Income guidelines
| Action | Reachable |
|---|---|
| Look up a fiscal year's income guidelines | No screen was ever built for it |
| Replace a fiscal year's income guidelines | No screen was ever built for it |
Replacing them is the only way anything is ever written to this table, there is no built-in starting set and no screen. The table is therefore empty in every copy of PTRS, and every eligibility tier PTRS has ever computed came from the fallback figures built into the code. See the thresholds.
Looking them up returns the free and reduced thresholds worked out alongside the stored base figure.
Income verifications
| Action | Reachable |
|---|---|
| Draw the verification sample | No screen was ever built for it |
| Request a verification | No screen was ever built for it |
| Complete a verification | No screen was ever built for it |
| List verifications still outstanding | No screen was ever built for it |
The whole verification cycle, draw the sample, request it, complete it, list what is outstanding, exists inside PTRS and has no screen and no plumbing toward one at all. There is nothing named for verification anywhere in the CACFP screens.
Listing what is outstanding returns verifications marked Pending or In Progress; nothing ever writes In Progress, so the second half of that search never matches anything.
The 3% sample rule, the outcome PTRS cannot record, and the two follow-up notice dates nothing ever writes are on How a participant becomes eligible.
Area eligibility
| Action | Reachable |
|---|---|
| Record a site's area eligibility | No screen was ever built for it |
| Look up a site's area eligibility | The Area Eligibility card on the enrolment screen |
| Update a record | No screen was ever built for it |
| List sites about to lose eligibility | No screen was ever built for it |
| Organisation-wide area eligibility summary | No screen was ever built for it |
One of five has a screen, and it is the lookup.
The lookup returns whichever record was certified most recently, with no check for whether it has lapsed, so an expired certification comes back exactly like a current one, and the card that shows it does not display the expiry date at all.
The "about to lose eligibility" list takes how many days ahead to look (90 by default) and works out how many days remain for each. It is the one that would answer "which of my sites is about to lose area eligibility?", and nothing calls it.
The organisation-wide summary returns nine counts: total, active, expired, expiring within 30 and 90 days, DDOE-approved, pending approval, meets-threshold and below-threshold. The below-threshold count can only be non-zero for a record created above the threshold and later updated below it, because creating one below the threshold is refused outright.
CACFP compliance records
The older, simpler compliance record PTRS carried before this module was built out.
| Action | Reachable |
|---|---|
| Create a record | No screen was ever built for it |
| List records | No screen was ever built for it |
| Look up one record | No screen was ever built for it |
| Update a record | No screen was ever built for it |
| Change a record's status | No screen was ever built for it |
| Delete a record | No screen was ever built for it |
| Change many records' status at once | No screen was ever built for it |
| Summarise a site's records | No screen was ever built for it |
Eight of eight have no screen at all. Nothing in PTRS creates, edits, changes the status of, or deletes one of these records.
The record is nevertheless shown: the CACFP Compliance card on the Compliance Radar reads it through the Compliance module. So the card shows real data that no one using PTRS can put there, the rows can only arrive through someone with direct system access.
Two things worth knowing about two of these actions:
- Deleting one hides it rather than erasing it, a genuine soft removal, unlike deleting a meal record.
- Changing many records' status at once reports how many it updated and how many it could not find. Sending the same record twice in one request inflates the "not found" count rather than the "updated" count. There is no rule about which status can follow which: any status can move to any other, in bulk, with one audit line per record.
Offline sync
| Action | Reachable |
|---|---|
| Upload a batch of offline entries | No screen reaches it, it is built, and nothing calls it |
| Look up sync status | Offline Mode & Sync |
| Resolve a sync conflict | No screen reaches it, the screen piece built for it is used by no page |
| List the sync queue | Offline Mode & Sync |
The two lookups have a screen and the two writes do not, so the queue is permanently empty and the page is a viewer with nothing feeding it. Resolving a conflict additionally requires the entry to already be marked Failed or Conflict, and neither status is ever written, so it could not succeed even if something called it.
Figures worth knowing. Looking up sync status returns the site, the queue depth, when it last synced, an error count and a status per device. What the page reads does not match most of those names, only the queue depth lines up, and the per-device breakdown is not read at all. The consequences on screen are on Read the records and offline screens.
DENARS packages
| Action | Reachable |
|---|---|
| Generate a package | Recordkeeping & Document Retention and Review Readiness, both send a request PTRS cannot read |
| List packages | Recordkeeping & Document Retention |
| Look up one package | No screen reaches it, it is built, and nothing calls it |
| Download a package | No screen was ever built for it |
Both places that generate a package ask for "every site" where PTRS needs one site, so the request fails before PTRS reads the rest of it. The recordkeeping page additionally sends the programme year as a number where PTRS expects text, and two of its three buttons name a package type PTRS does not have.
Downloading a package would return blank for every one of them, because nothing in PTRS ever stores a document against a package.
Program year
| Action | Reachable |
|---|---|
| Reconcile a fiscal year | No screen was ever built for it |
| Close a fiscal program year | No screen was ever built for it |
| Final audit report for a fiscal year | No screen was ever built for it |
Three of three have no screen at all. Three things are worth recording about them anyway, because these are the fiscal-year close controls.
Closing a program year loads the fiscal year's draft claims, counts open corrective action plans, and returns a message saying the year is "Closed," with a count of claims it says were frozen.
No claim is frozen. No claim's status changes, nothing is flagged, no row is written. The count reported as "frozen" is simply the count of drafts it found.
Whoever asked gets "Closed" back and nothing has happened.
The close, reconciliation and final-report actions all work out the CACFP fiscal year correctly, 1 October to 30 September, and then select claims by comparing a calendar year field against it, which matches claims from both the prior fiscal year and this one. Meal records in the same reports are filtered correctly by their actual date.
So the reconciliation report compares twelve months of meals against twenty-four months of claims, and a claim from January through September of the prior fiscal year is counted in both fiscal years.
The final audit report carries four figures fixed at zero or a stand-in value, because nothing in PTRS tracks food service costs. The overall compliance rate reads 100% whenever there are no open corrective actions at all. The count of amended claims counts a status nothing in PTRS ever assigns.
The two automatic findings it produces are real, though: a warning when a month in the fiscal year has no claim, and a serious finding when corrective actions remain open.
Paging
Six of these actions return a page of results at a time. The default page size is 25 everywhere, with no maximum enforced on any of them.
PTRS sends back the total number of pages and whether there is a previous or next one, and no screen reads any of that, every paging control in the module works the page count out for itself from the total count instead.
Related
- Who can do what with meals and claims, the other 54, meal counting and the claim
- Enrolment and eligibility fields, every field and its rule
- How a participant becomes eligible
- Roles and permissions
Checked against PTRS on 7 September 2026.