Work the review and corrective action screens Tom is trying to get ahead of a state review before it happens. This page is
how to read Corrective Action Plans , the Self-Audit Dashboard and
Review Readiness , and between them they hold the chain a state review
runs on: self-audit, then a finding, then a corrective action, then a readiness
score, then a DENARS package.
Who can do this Front-line staff Site director Regional director Organisation admin Super admin Create New CAP, New Audit and Generate DENARS Package are hidden from staff members. That is a menu choice only, PTRS itself accepts the same requests from a staff member's account. The lists and dashboards on all three screens apply no check at all.
Corrective Action Plans
A status filter, a Create New CAP button, the form it opens, and a list
of plan cards.
The list and the cards
Each card shows the finding category, a severity chip, a status badge, the
finding description, the assigned date and the due date, with
"(Overdue)" in red when the due date has passed and the status is
neither Closed nor Verified.
Two problems with the chips:
The severity chip is always grey. The chip only has colours for Low,
Medium, High and Critical. PTRS's own three severities are named
Observation, Finding and Serious Deficiency. There is no overlap , so
every severity falls through to grey.
Two statuses are grey too. The badge only has colours for five of
PTRS's six statuses, spelled to match an older naming, so Pending
Verification and Overdue render grey, and the coloured Completed status
is not one PTRS actually has.
And the card is a dead link. The whole card links to a page for that
plan's own id, and that page does not exist. Clicking a plan leads
nowhere.
The status filter returns everything when you pick Completed
The filter only applies when the value it is given is one PTRS
recognises. The filter offers All Statuses, Open, In Progress, Completed
and Overdue.
Filter option Result All Statuses Every plan Open Filters correctly In Progress Filters correctly Completed Not a status PTRS has. The filter is silently skipped, and you get every plan , the opposite of what the label impliesOverdue Filters correctly
Pending Verification, Verified and Closed are real statuses and are not
offered, so the three states at the end of a plan's life cannot be
filtered at all.
Create New CAP fails five different ways
A corrective action plan cannot be created from this form In the order PTRS hits them:
1 and 2, two blank fields, before anything else is checked. The form
sends a blank site and a blank responsible staff member, and has no input
for either. Both fail before PTRS runs its usual checks.
3, source type. The dropdown's default is an unselected
option, which PTRS refuses.
4, 5 and 6, three choices PTRS does not recognise.
Field The form offers Recognised by PTRS Valid Source Type State Review, Self-Audit, Site Monitoring, Complaint Sponsor Monitoring Review, DDOE Admin Review, Self-Audit, Claim Edit Check, Complaint Investigation Only Self-Audit Severity Minor, Major, Critical Observation, Finding, Serious Deficiency None Finding Category free text, suggesting "Meal Pattern, Recordkeeping" Meal Pattern (no space), Meal Count, Enrollment, Attendance, Civil Rights, Training, Recordkeeping, Financial Management, Food Safety, Food Service Agreement, Other The suggested example is itself rejected
The toast reads "Failed to create corrective action plan" and names
none of it.
The severity mismatch is the worst of the six , because PTRS's three
severities are the three USDA finding classes a reviewer actually uses,
and the form offers a generic scale that maps onto none of them.
You cannot update or close a plan either
Three of the five corrective-action actions have the plumbing for a screen and no screen using it Looking up one plan, adding an update to it, and verifying it are all
built with the plumbing a screen would need, and none has a screen.
The screen pieces built for a plan's timeline and its update form both
exist and are used by no page, and the page they would live on does not
exist either.
The actions themselves are sound. Adding an update records the previous
and new status, writes a record of the change and moves the plan forward.
Verifying sets the verification date and verifier, moves the plan to
Verified, and escalates it to Closed when closure notes are given.
The consequence: every corrective action plan that exists is
permanently Open. Nothing that would need a link to who updated it has
any writer that a person can reach, including a recurrence count, the
review it came from, supporting documents, the closure date and closure
notes, and whether DDOE needs to be told.
And nothing acts on whether DDOE needs to be told. That flag is on the
create form and is read by no code. No CACFP path sends an email at all;
see
what a CACFP review asks for .
Self-Audit Dashboard
A New Audit button, the form it opens, and a table: Date, Program
Year, Result, Complete, Notes.
New Audit fails on every submit
A self-audit cannot be created from this form The form sends a blank site, and collects Audit Date, Program Year,
Period Start and Period End, no site. A blank value where PTRS needs a
real site fails before PTRS's usual checks even run.
The toast reads "Failed to create self-audit."
Selecting a site in the header does not help. This page never reads it.
An audit that could be created could never be completed
Nothing in the interface can submit self-audit results Every new check starts marked Needs Attention and not complete. The only
action that changes either is submitting the audit's results, and no
screen calls it. The two screen pieces built for it exist and are used
by no page, and there is no page for one either.
So the table's Result column reads Needs Attention on every row and
its Complete column reads No on every row, forever.
The action itself is one of the better ones in the module. It checks
each area and each result against what PTRS recognises, records one
result per area, marks it complete, and honestly works out the overall
result: Critical Issues if any check failed, Needs Attention if any was
not reviewed, otherwise Ready for Review.
The seven areas it would score, meal count accuracy, meal pattern
compliance, enrolment records, attendance records, the food service
agreement, prior findings and civil rights compliance, have no surface in
the product at all.
A third screen piece in this area, meant to show a history of audit runs,
also exists and is used by no page.
And there is no site monitoring screen at all
Seven site-monitoring actions, all built, none reachable Recording a sponsor's own monitoring review of a site, along with per-meal
observations, and two analysis lookups for claim accuracy and possible
overclaims, are all built, and there is no site monitoring screen at
all. The screen pieces built for it are used by no page.
A sponsor's own review of a site, announced, unannounced or a follow-up,
with a point-of-service count method and per-meal observations, cannot be
recorded, scheduled or read anywhere in PTRS.
Two notes on the analysis lookups, for whoever wires them up:
Claim accuracy returns all zeros. It counts Approved and Paid
claims as accurate and Amended claims as underclaims. Nothing ever
marks a claim Paid or Amended, and
no claim can be created at all .
Overclaim detection's attendance figure is not attendance. It is
worked out as the count of distinct dates with a meal record, then
flags an overclaim when meals served exceed that count times three. It
is returned under a field named for attendance.
Review Readiness
A readiness dashboard, a site compliance score card and a DENARS package
generator.
Every panel on this screen is empty
Both of this page's requests send 'every site' where PTRS needs one real site The page asks for readiness and the compliance score across "every
site," and PTRS needs one real site for both, so it refuses both requests
outright.
What you see:
Panel What it shows Failure banner "Failed to load review readiness data. Please try again later." Review Readiness Dashboard "No readiness data available." Site compliance score "No compliance data available."
The page never reads the header's site picker, so there is no selection
that changes this.
A second problem sits behind that one and would surface the moment the
site were fixed. The page expects a figure under a name that does not
match what PTRS actually sends for category scores, so it would fail the
moment it tried to show them. The card also shows the site's own id, a
long code, where a site name belongs.
Looking up the document checklist, the third action in this group, is
built with the plumbing a screen would need and has no screen. Its own
screen piece also expects a different shape of answer than PTRS sends.
What the two working checks would show, if reached, is on
what a CACFP review asks for .
They are the most substantial reporting work in the subset, eight
categories, nineteen checks, a weighted score whose weights sum to exactly
1.00, and no screen has ever shown either of them.
Generate DENARS Package fails as the recordkeeping one does
The DENARS package button sends an invalid site and an invalid package type The page sends "every site" as its site, and it sends the eight selected
category labels, joined together with commas and other punctuation, as
the package type. Neither is something PTRS can use.
This is the same action Recordkeeping & Document Retention calls, and
it fails there for the same reason. What it does when it succeeds, write
a row marked Generated and produce no document, because nothing in PTRS
ever assembles the file, is documented on
Who can do what with enrolment and records .
The Program Year box on the generator defaults to the current
calendar year, not the federal program year.
There is no reviewer workflow
The screen piece built for an external reviewer has no page and no data behind it A screen piece built to show a table of a reviewer's own name, action,
timestamp and details, the record a site would show a state reviewer of
what that reviewer looked at, exists in PTRS. No page uses it , it
takes its rows from whatever it is handed rather than asking PTRS for
them, and nothing anywhere in PTRS actually returns reviewer access
events. There is no record for one.
More broadly, there is no OCCL auditor workflow to document here. That
role satisfies none of the rules the CACFP module checks, so an OCCL
auditor reaches none of these screens. A visiting reviewer would have to
be given one of the five working roles instead, which grants the whole
module, including claim approval.
What to do instead
You need to Today Record a finding and the action taken on it Keep it outside PTRS. The form fails for five independent reasons Classify a finding by USDA severity Not possible, none of the three offered values is one PTRS recognises Move a corrective action to verified or closed Not possible from any screen Filter corrective actions by Completed Do not, it returns every plan, not the completed ones Run a self-audit before a state review The header can be created only through direct system access, and the seven check areas have no surface See how ready a site is for a DENARS review Not possible. Both readiness requests fail on every load Produce a DENARS package Not possible from either button, and the action produces no document when it does run Give a state reviewer scoped access Not possible. The OCCL auditor role reaches nothing here; any workable role grants the whole module
Checked against PTRS on 7 September 2026.