Who can do what with operations and compliance
The last 89 of the CACFP module's 251 things PTRS can do: temperature logs, production records, meal service windows and site configuration, civil rights, poster compliance, staff and DDOE training, CACFP role assignments, food safety certification, corrective action plans, self-audits, site monitoring, the program calendar, review readiness, document storage, background job records and non-participant meals.
With this page the module is fully mapped. The other groups are on Who can do what with meals and claims (54, the money path), Who can do what with enrolment and records (41), Who can do what with menus and inventory (64) and Procurement analytics (3).
Who can do this
Staff members, site directors, regional directors, organisation administrators and super admins, for every one of the 89 things on this page. Across all 251 things PTRS can do in CACFP, exactly one group narrows that further, and it is Procurement analytics, not here.
A front-line staff member's account is authorized to review and approve a production record, verify and close a corrective action plan, certify the annual civil rights complaint log, forward a discrimination complaint to USDA, assign and authorize CACFP roles and submit self-audit results, every supervisory control in the module's compliance chain.
Four of those controls are hidden from staff members by the menu. That is a menu choice, not a real control: PTRS accepts the request from a staff member's own account regardless of what the screen shows.
This is recorded for the PTRS team and is not being changed by this documentation.
How to read "Reachable" below
A screen means a page or dialog calls it in normal use.
No screen reaches it means the plumbing a screen would need exists, and nothing uses it.
No screen was ever built for it means nothing in PTRS points toward a screen at all.
Called, always fails means a screen calls it every time, and the request can never succeed. The reason is given in the row.
Temperature logs, 4 things
| Action | What it does | Reachable |
|---|---|---|
| Create a temperature log | The temperature form, shown on both Temperature Logs and Production Records. Succeeds for one of the five log types the form offers | |
| Add a reading to a log | No screen reaches it | |
| Complete a log | No screen reaches it | |
| List a site's temperature logs | Temperature Logs |
Creating a log needs a site, a log date and a log type, all filled in. Adding a reading needs the log, a food item name, a reading type and who took it, all filled in; the temperature itself has no rule at all, so any number, including a negative one, is accepted. Completing a log needs the log and who is completing it.
The log type must be one PTRS recognises: Receiving or Meal Service. The form offers Receiving, Cooking, Holding, Cooling and Reheating, so four of its five options are refused. A reading's type must also be one PTRS recognises; the safe-range table behind it is on Temperature and production fields.
Completing a log can fail hard rather than cleanly. PTRS refuses to complete one whose corrective actions are not fully documented, and does so as a raw failure rather than a clear message. Not reachable today anyway, since nothing calls the complete action.
Production records, 5 things
| Action | What it does | Reachable |
|---|---|---|
| Create a production record | The form on Production Records, called, always fails | |
| Add a line item to a record | No screen was ever built for it | |
| Review a production record | No screen reaches it | |
| List a site's production records | Production Records | |
| Look up one production record | No screen reaches it |
Why creating one always fails. The form sends an all-zero id for the meal record it documents, and PTRS requires a real one. The form has no meal record picker, so there is no value you could type instead. A second problem sits behind it: the free-text Staff ID box is sent straight through as if it were a real staff record's id, so anything that is not shaped like one fails before PTRS even checks it.
Creating a record needs a site, the meal record, a production date, a meal type, which USDA components were met, and who prepared it, all filled in; meals prepared greater than 0. Meals served has no rule at all, so it may exceed meals prepared and may be negative. Adding a line item needs the record, an item name, its USDA component and a unit, all filled in; none of its four quantity fields has any rule at all.
Review status. PTRS recognises Pending Review, Approved and Needs Correction. The screen piece built for reviewing sends "Rejected," which is not one PTRS recognises, and a blank reviewer, which PTRS refuses. Neither button on it is reachable.
Meal service windows and site configuration, 5 things
These are the two records the Vended Meal Management screen exists to configure.
| Action | What it does | Reachable |
|---|---|---|
| Create a meal service window | Vended Meal Management, called, always fails (sends "every site" where PTRS needs one real site) | |
| List a site's meal service windows | Vended Meal Management, called, always fails, same reason | |
| Update a meal service window | No screen reaches it | |
| Look up a site's CACFP configuration | Vended Meal Management, called, always fails, same reason | |
| Update a site's CACFP configuration | No screen reaches it |
These actions themselves are sound. Creating a window refuses a second active window for the same site and meal type, refuses a start time at or after the end time, and records the action. Updating the configuration is an upsert: it creates the setting on first use and updates it after, and also records the action. Both lookups are kept in memory for 30 minutes.
Nothing checks a meal count against a service window. The five meal-period cards on Meal Records carry the same fixed times for every site. A site's CACFP configuration is read by nothing either, except one of the twenty claim checks, which names it in a placeholder comment and passes without checking anything, waiting for this configuration to be wired in. It never was.
So a configured service window governs no meal count, a configured approved site capacity limits nothing, and a configured correction window changes no correction window, the correction window used elsewhere is fixed at 60 days, written directly into those actions.
And there is no vended meal delivery action at all. PTRS can hold a vended meal agreement and a delivery against it, contract dates, hub and satellite sites, ordered, delivered and served counts, a receiving temperature and a rejection reason, and neither is used by any action, screen or service anywhere in PTRS. The screen named "Vended Meal Management" manages service windows only.
Civil rights, 15 things
| Action | What it does | Reachable |
|---|---|---|
| Record a demographic | No screen was ever built for it | |
| List demographics | No screen reaches it | |
| Look up the FNS-101 summary | Civil Rights Compliance, called, and the page reads a figure the response does not carry | |
| Record a complaint | No screen was ever built for it | |
| List complaints | Civil Rights Compliance | |
| Look up one complaint | No screen reaches it | |
| Forward a complaint to USDA | No screen was ever built for it | |
| Resolve a complaint | No screen was ever built for it | |
| Look up the annual complaint log | No screen reaches it | |
| Certify the annual complaint log | No screen was ever built for it | |
| Record a poster display | No screen was ever built for it | |
| List poster records | Civil Rights Compliance, and the page reads the wrong name for the display location | |
| Re-verify a poster | No screen was ever built for it | |
| Record civil rights training | No screen was ever built for it | |
| List civil rights training | Civil Rights Compliance, and the page reads the wrong name for the delivery method |
Four reads, eleven writes, and not one write can be reached. Every create, forward, resolve, verify and certify action in this group has no screen. Civil Rights Compliance is a four-tab read-only screen with no form on any tab.
Recording a complaint needs a site, the complainant's relationship, the alleged bases, a description, who received it and how, all filled in. Recording a poster needs a site, form number, version date, display location, condition and who verified it. Recording training adds a duration greater than 0. Recording a demographic checks five fields, and PTRS additionally verifies the child exists and refuses a duplicate for the same child and program year.
A program-year comparison that cannot match. Certifying the log selects complaints by matching a four-character calendar year. Every other CACFP screen uses the nine-character federal form, and Civil Rights Compliance works out the current calendar year pair. Certifying a log for 2026-2027 therefore counts zero complaints, whatever is on file.
Poster compliance, 3 things
This is a second, unrelated poster record, with its own table and its own actions.
| Action | What it does | Reachable |
|---|---|---|
| Record a poster compliance check | No screen reaches it | |
| List poster compliance checks | No screen reaches it | |
| Look up poster compliance status | No screen reaches it |
The two poster records share no key and no reconciliation. Looking up status groups this record and marks a site compliant when every one of its rows reads Good; the review-readiness check and the compliance score both read the other record. A poster recorded through this group therefore counts for nothing anywhere else.
Nothing checks what recording one is sent. Whatever is given for condition and verified date is checked; every other field is stored exactly as sent.
No poster form number is named anywhere in PTRS. It is free text on both records. PTRS states no required poster, no required version and no required display location; the only structured field is the condition, Good, Damaged, Faded, Covered or Missing.
Staff and DDOE training, 8 things
| Action | What it does | Reachable |
|---|---|---|
| Create a training record | No screen was ever built for it | |
| List training records | CACFP Training & Staff Management and Annual Training Calendar | |
| Look up one training record | No screen was ever built for it | |
| Mark a training record complete | No screen was ever built for it | |
| Create a DDOE training record | No screen was ever built for it | |
| List DDOE training records | No screen was ever built for it | |
| Look up training compliance for a program year | CACFP Training & Staff Management and Annual Training Calendar | |
| Refresh the compliance snapshot | No screen was ever built for it |
A training record cannot be created, read individually, or marked complete from the interface. Both training screens are read-only over a list nothing can add to.
Creating a record needs the staff member, the site, training type, date, method, provider and program year, all filled in; hours greater than 0. That is the only rule PTRS applies to training hours anywhere. There is no minimum, no per-role hour requirement, and the table listing what each role requires has no hours column at all, see what a CACFP review asks for.
Expiry is worked out, not entered. It is set to 30 September of the program year's end year.
What the compliance rate measures. Looking up training compliance returns a stored snapshot if one exists, and otherwise works it out fresh. Either way, the count of compliant staff is the count of role assignments marked Authorized. No training record is consulted at all. The table listing what training each role requires is read only by its own listing.
Civil rights training certifications, 2 things
A third training record, separate from both the CACFP staff training record and the civil rights training record above.
| Action | What it does | Reachable |
|---|---|---|
| Create a civil rights training certification | No screen reaches it | |
| List civil rights training certifications | No screen reaches it |
Nothing checks what creating one is sent. This record is read by nothing else, the readiness check and the compliance score both read the civil rights training record instead.
CACFP role assignments, 6 things
| Action | What it does | Reachable |
|---|---|---|
| Create a role assignment | No screen was ever built for it | |
| List role assignments | CACFP Training & Staff Management | |
| End a role assignment | No screen was ever built for it | |
| Change a role assignment's authorization | No screen was ever built for it | |
| List role requirements | No screen was ever built for it | |
| Create a role requirement | No screen was ever built for it |
None of the four writes in this group checks what it is sent, and five of the six have no screen at all.
Every new role assignment starts Unauthorized. The only action that changes it takes the new status exactly as sent, working nothing out for itself, and has no screen. With no screen for either creating or authorizing an assignment, no CACFP role assignment can be created or authorized from the interface, which is why the training compliance rate above is 0.00 in a copy of PTRS whose assignments were not entered by hand.
PTRS defines seven CACFP programme roles: Authorized Representative, Site Coordinator, Meal Preparer, Meal Recorder, Eligibility Determiner, Monitor Reviewer and Backup Site Coordinator. These are unrelated to the roles that govern the rest of PTRS.
Food safety certifications, 5 things
| Action | What it does | Reachable |
|---|---|---|
| Create a certification | No screen was ever built for it | |
| List certifications | CACFP Training & Staff Management | |
| Look up one certification | No screen was ever built for it | |
| Recompute a certification's renewal status | No screen was ever built for it | |
| Look up site coverage | CACFP Training & Staff Management, called, and the page reads three figures the response does not carry |
Nothing checks what either write is sent. PTRS recognises five certification types: ServSafe Manager, ServSafe Food Handler, Delaware Food Handler, ANSI Food Safety and State-Certified Other.
A certification's renewal status is worked out as Expired past the expiry date, Expiring Soon within 90 days, Current otherwise. The 90 is a fixed number with no citation. The fourth status, Pending Renewal, is set only by an action nothing calls.
A table meant to let one certification cover several sites has no writer anywhere, so a certification marked as covering multiple sites covers exactly the one site on its own row.
Food safety certs, 4 things
A second, unrelated food safety certification record, with a free-text certification type, no manager level, no renewal status and no way to cover more than one site.
| Action | What it does | Reachable |
|---|---|---|
| Create a food safety cert | No screen reaches it | |
| List food safety certs | No screen reaches it | |
| Look up one food safety cert | No screen was ever built for it | |
| Remove a food safety cert | No screen was ever built for it |
Nothing else in PTRS reads this record. The training dashboard, the site-coverage lookup, the readiness check and the compliance score all read the certification record above instead. A certificate recorded here would satisfy no check.
Corrective action plans, 5 things
| Action | What it does | Reachable |
|---|---|---|
| Create a corrective action plan | Corrective Action Plans, called, always fails | |
| List corrective action plans | Corrective Action Plans | |
| Look up one plan | No screen reaches it | |
| Add an update to a plan | No screen reaches it | |
| Verify a plan | No screen reaches it |
Why creating one always fails, five separate reasons, in the order PTRS hits them. The form sends a blank site and a blank responsible staff member, neither has an input. Past those, PTRS requires a source type, and the form's default is an unselected option. Past that, three values the form offers do not match what PTRS recognises:
| 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 | 1 of 4 |
| Severity | Minor, Major, Critical | Observation, Finding, Serious Deficiency | 0 of 3 |
| 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 status filter silently returns everything. The status filter applies only when PTRS recognises the value. It offers Completed, which PTRS does not define, so choosing it returns every plan rather than none. The three statuses PTRS does define and the filter does not offer, Pending Verification, Verified, Closed, cannot be filtered at all.
Adding an update and verifying a plan both write correctly. The update records the previous and new status, adds a record of the change, and moves the plan. Verifying sets the verification date, verifier and status Verified, and escalates to Closed when closure notes are given. Neither is reachable.
Self-audits, 4 things
| Action | What it does | Reachable |
|---|---|---|
| Create a self-audit check | Self-Audit Dashboard, called, always fails (sends a blank site) | |
| List self-audit checks | Self-Audit Dashboard | |
| Look up one self-audit check | No screen reaches it | |
| Submit self-audit results | No screen reaches it |
Submitting results is a real write. It checks every area and result against what PTRS recognises, records one result per area, marks it complete and timestamps it, and honestly works out the overall result: Critical Issues if any check failed, Needs Attention if any was not reviewed, otherwise Ready for Review. It is one of the few "submit" actions in this module that does what its name says.
Because nothing calls it, a self-audit created from the screen stays Needs Attention and not complete forever, those are the values creating one assigns, and no other path changes them. The seven check areas, meal count accuracy, meal pattern compliance, enrolment records, attendance records, the food service agreement, prior findings, civil rights compliance, have no surface at all.
Who conducted it is recorded using your own signed-in account's identity, in a field named for a staff record. Same pattern as the meal-record staff-id findings in Who can do what with meals and claims.
Site monitoring, 7 things
Every one of these seven has the plumbing a screen would need, and not one has a screen. There is no site monitoring screen at all.
| Action | What it does | Reachable |
|---|---|---|
| Create a site monitoring review | No screen reaches it | |
| List site monitoring reviews | No screen reaches it | |
| Look up one review | No screen reaches it | |
| Update a review | No screen reaches it | |
| Add a meal observation to a review | No screen was ever built for it | |
| Look up claim accuracy for a fiscal year | No screen reaches it | |
| Look up overclaim detection for a site | No screen reaches it |
PTRS recognises three review types: Announced, Unannounced and Follow-Up; four count methods: Roster, Tally, Direct Count and Pre-Approved; and five review statuses. The screen pieces built for a monitoring review table and a site compliance card are both used by no page.
Claim accuracy counts statuses no claim can hold. 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, so this returns zeros across the board.
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, and is returned under a field named for attendance. A separate weekend flag raises whenever a meal record falls on a weekend, regardless of whether the site is actually approved for weekend service, which is what the flag is meant to check.
Program calendar, 5 things
All five have the plumbing a screen would need, and none has one. There is no program calendar screen, and the screen pieces built for editing, viewing and a transition alert are all used by no page.
| Action | What it does | Reachable |
|---|---|---|
| Create a program calendar entry | No screen reaches it | |
| List program calendar entries | No screen reaches it | |
| Look up one entry | No screen reaches it | |
| Update an entry | No screen reaches it | |
| Check a program transition | No screen reaches it |
Creating one refuses an overlapping entry for the same site, programme and fiscal year. Checking a transition finds the entry covering a date, and once a transition date has passed, moves ARAS to SFSP or SFSP back to ARAS. With no calendar entry it reports no active programme at all.
Review readiness, 3 things
| Action | What it does | Reachable |
|---|---|---|
| Look up review readiness | Review Readiness, called, always fails (sends "every site" where PTRS needs one) | |
| Look up the document checklist | No screen reaches it | |
| Look up the compliance score | Review Readiness, called, always fails, same reason |
These three are the best-built reporting work in the subset, and none of them can be reached. Both readiness and the compliance score are described in full on what a CACFP review asks for.
Two mismatches sit behind the failures and would surface if the site were fixed: the document checklist's screen piece expects a different shape of answer than PTRS sends, and the compliance score card expects a figure under a name that does not match what PTRS actually sends for category scores, and shows the site's own id, a long code, where a site name belongs.
The DENARS package button on this screen fails the same way as the recordkeeping one. It sends "every site" as the site and a comma-joined list of eight category labels as the package type. Generating a package itself is documented on Who can do what with enrolment and records.
Document storage, 4 things
No screen reaches any of the four, so nothing in PTRS can upload, list, download or delete a document attachment.
| Action | What it does | Reachable |
|---|---|---|
| Upload a document | No screen was ever built for it | |
| List documents for a record | No screen was ever built for it | |
| Download a document | No screen was ever built for it | |
| Delete a document | A gentle removal that hides rather than erases | No screen was ever built for it |
All four keep their work inside your organisation, and uploading and deleting both record the action in the audit trail. Uploading a document reads several values sent with it directly as record ids, so a malformed value fails in an uncontrolled way rather than with a clear message.
This matters for readiness. Administrative Records is one of the eight readiness categories, and its one check is whether any document attachment exists for the site. With no way to upload one, that category scores 0 of 1 in every copy of PTRS.
Background job records, 2 things
| Action | What it does | Reachable |
|---|---|---|
| List background job records | Real-Time Feed | |
| Look up one background job record | No screen reaches it |
This record has two readers and no writer, the same shape found elsewhere in the eligibility and records group, and unchanged here.
Listing background job records does not filter by organisation at all, because this record does not carry PTRS's usual automatic organisation boundary, and nothing adds the check by hand here either.
So this action would return every organisation's job history. It is harmless today only because nothing ever writes a row. This is structurally the same defect as looking up approved substitution items, covered in Who can do what with menus and inventory.
Non-participant meals, 2 things
Adult staff and visitor meal counts, which are not reimbursable and must be recorded separately from participant counts.
| Action | What it does | Reachable |
|---|---|---|
| Record a non-participant meal | Updates an existing row for the same site, date and meal type rather than duplicating it | No screen was ever built for it |
| List non-participant meals for a site | No screen was ever built for it |
Both branches of recording one are captured in the audit trail. No screen in PTRS records a non-participant meal.
Allergy alerts, 1 thing
Looking up allergy alerts for a site belongs to this feature area and is documented on Who can do what with meals and claims, where the four screens that use it are listed. It is counted there, not here.
Summary
| Group | Things PTRS can do | Reachable from a screen |
|---|---|---|
| Temperature logs | 4 | 2 |
| Production records | 5 | 2 |
| Meal service windows and site configuration | 5 | 3 |
| Civil rights | 15 | 4 |
| Poster compliance | 3 | 0 |
| Staff and DDOE training | 8 | 2 |
| Civil rights training certifications | 2 | 0 |
| Role assignments | 6 | 1 |
| Food safety certifications | 5 | 2 |
| Food safety certs | 4 | 0 |
| Corrective action plans | 5 | 2 |
| Self-audits | 4 | 2 |
| Site monitoring | 7 | 0 |
| Program calendar | 5 | 0 |
| Review readiness | 3 | 2 |
| Document storage | 4 | 0 |
| Background job records | 2 | 1 |
| Non-participant meals | 2 | 0 |
| Total | 89 | 23 |
66 of the 89 have no screen, and 8 of the 23 that do can never succeed:
| Action | Called from | Fails because |
|---|---|---|
| Create a production record | Production Records | The meal record id is blank, which PTRS refuses |
| Create a meal service window | Vended Meal Management | Sends "every site" where PTRS needs one |
| List a site's meal service windows | Vended Meal Management | Same |
| Look up a site's CACFP configuration | Vended Meal Management | Same |
| Create a corrective action plan | Corrective Action Plans | Blank site and blank responsible staff member, before three mismatched choices |
| Create a self-audit check | Self-Audit Dashboard | Sends a blank site |
| Look up review readiness | Review Readiness | Sends "every site" where PTRS needs one |
| Look up the compliance score | Review Readiness | Same |
Across all four groups the module stands at 78 of 251 things with a screen, and 173 without.
Validators
There are 31 checks across this group's actions, and not one sets a maximum length on anything, the same gap found in the menu and inventory group. PTRS's own storage limits are therefore the only length limits there are, so an overly long value reaches PTRS and comes back as a raw failure rather than a clear message.
Ten write actions in this group have no check at all: all four in role assignments, both writes in food safety certifications, both in food safety certs, recording a poster compliance check, and creating a civil rights training certification. For those, whatever PTRS's own parsing does not catch is stored exactly as sent.
Messages PTRS can give
| What you did | What PTRS says |
|---|---|
| Your account has no organisation | "Organization context is required." Every action on this page checks this first |
| Picked one of the four log types PTRS refuses | A message naming the type as invalid |
| Sent a reading type PTRS does not recognise | A message naming it as invalid |
| Sent "Rejected" as a production record's review status | A message naming it as invalid |
| Sent a corrective-action source, category or severity PTRS does not recognise | A message naming it as invalid |
| Sent a production line item's component PTRS does not recognise | A message naming it as invalid |
| Sent a meal type PTRS does not recognise, on a service window or observation | A message naming it as invalid |
| Set a service window's start time at or after its end time | A message saying so |
| Tried to create a second active service window for the same site and meal type | A message saying one already exists |
| Asked for a site's CACFP configuration before one was ever set | "Not found," until the first update creates it |
| Asked about a site that does not exist | "Not found," on the complaint, poster, civil-rights training and food safety cert actions |
| Tried to create a duplicate demographic record | A message saying one already exists |
| Sent "every site" where a real site is required | A bare "not found," with no further detail, on any of the four affected reads |
Related
Checked against PTRS on 7 September 2026.