CACFP

It is the first week of the month and Tom Bradley has last month's meal counts for Claymont on his desk. He opens PTRS to turn them into the claim that brings the federal money in. This page is what he will find, and it is not what the screens promise.

Read this before anything else on this page

A CACFP claim cannot be created in PTRS. The Create New Claim button sends PTRS a programme name it does not recognise, and that button is the only way a claim starts. Every other claim screen and button acts on a claim that cannot exist. The claims list reads "No claims found." in every organisation.

A meal count cannot be recorded from any of the three CACFP screens that offer to record one. Two send the organisation's id where a staff member's id belongs; the third sends an email address where a record id belongs. One way of recording a count works, and it is in the header, not in this part of PTRS: Record a meal count.

The reimbursement arithmetic, the twenty claim checks and the rate table are real and readable. They are on The reimbursement arithmetic and How a claim moves through its lifecycle, because the defect that blocks them is small and what sits behind it matters.

What CACFP is for

CACFP is a federal programme. A club that serves a qualifying meal to a qualifying child on a day it operated is owed money for that meal, at a rate the USDA publishes each year. Nobody pays it unless the club claims it, and the claim has to survive a state review.

The arithmetic is the easy part. The hard part is that the arithmetic is only as good as a count taken by Denise Okafor standing at the serving line with children in front of her, and that a state reviewer arriving eighteen months later will ask for her records to prove a number nobody remembers. A club loses money two ways: by not claiming meals it served, and by claiming meals it cannot document. The second is worse, because the money is taken back with interest.

PTRS is designed for the whole of this. It has a meal record, a participant, an eligibility tier, a rate table with its Federal Register citation, a claim with its 60-day deadline and its certification statement, twenty named claim checks each carrying its own regulation reference, a rule that the person who approves a claim is not the person who submitted it, an amendment chain, a 60-day correction window on meal records, and a Delaware daily limit counted across every site a child might attend in one day. The design is unusually complete. Almost none of it can be reached from a screen.

Who uses it

Staff members, site directors, regional directors, organisation administrators and super admins can use every CACFP screen. Guardians, read-only accounts and OCCL auditors see the CACFP entries in their menu, because the menu hides nothing from anyone, and then every screen fails to load for them.

Who can do this

• Front-line staff
• Site director
• Regional director
• Organisation admin
• Super admin

The menu hides Create New Claim, Approve and Reject from staff members. PTRS itself does not: a staff member's account is allowed to do all three.

There is no line between reading and approving

One permission covers everything in CACFP, from looking at a meal count to approving a federal reimbursement claim, and it admits staff members. Creating a claim, submitting one with a signed certification, approving it, rejecting it, adjusting it, creating or amending a rate, creating a vendor and approving a purchase order are all allowed for the most junior working role in PTRS.

The one exception is the three procurement reports, which are refused to staff members. So a staff member's account may approve a purchase order and may not see the spend report about it. See Procurement analytics.

The screens hide Create New Claim, Approve and Reject from staff members. That is a menu choice, not a permission. PTRS accepts the same actions from a staff member's account. This is recorded for the PTRS team and is not changed by this guide.

The one real control is between people, not roles: PTRS refuses to let the person who submitted a claim approve it, with the message "Approver must differ from submitter (separation of duties)."

A day in the life

Denise serves breakfast at Claymont and takes her count on paper at the line. At her desk she presses + in the header, then Meal Count, chooses Claymont, Breakfast, her own name under Recorded By, types the counts by age band and the menu, and saves. She repeats it for lunch and the afternoon snack. That is the whole of what PTRS can hold about a meal, and it holds it well: the site, date, meal, counts, menu, who counted, when it was entered, and an entry in the tamper-evident audit log.

At the end of the month Tom opens Claims and presses Create New Claim. The message reads "Invalid program type: CACFP." He cannot get past it. The CACFP Monthly Claim panel on the overview shows him the month's meal days and total served correctly, and beside them Valid Rate at 0% and the estimated reimbursement, labelled "Est. Reimbursement", at $0.00. Both figures are fixed at zero for every site in every organisation. Tom prepares the claim outside PTRS, from Denise's paper records and the totals on Meal Records.

When Carla Reyes brings in a household income form for Maya, Tom finds that PTRS has a complete income application with the right arithmetic, and no screen to enter it on. He enrols Maya on Enrollment, choosing her tier from a dropdown that starts on Free, and keeps Carla's form in the filing cabinet, because nothing in PTRS connects the two.

What PTRS does for you

Four things, and they work.

• The 60-day correction window. A meal record can be edited or deleted until 60 days after the meal date, and refused after. See Correct or remove a meal count.
• The audit trail. Every meal count, every correction, every deletion and every claim step is written to the tamper-evident audit log.
• The separation of duties between one person and another on a claim.
• The Meal Count dialog in the header, which records a count against the member of staff who took it.

And one thing that half works. Enrolment completes and is stored correctly. PTRS does not check the tier you choose, cannot change it afterwards, and cannot withdraw the participant. See Enrol a participant.

What stays your job

Most of it. Stated plainly, because this is the part that costs money:

• Take the count at the serving line, on paper, at the time. PTRS records a total for the site and the meal, not who ate.
• Keep the paper point-of-service record, the production record and the household income forms. PTRS holds none of the documentation a CACFP review asks for.
• Work out the claim outside PTRS. No claim can be created, no meal is ever priced, and the rate table is empty in every installation.
• Do your own daily-limit check for a child who attends more than one site in a day. PTRS has the rule and never applies it.
• Do your own comparison of meals against attendance before the claim period closes. PTRS builds that comparison twice and reaches it neither time.
• Keep the paper determination behind each child's tier. PTRS stores the tier you type and nothing that supports it.

The risk here is not a missing feature. It is a screen that reports federal money in a shape that looks right and is not. Open the overview with a month of meals recorded and it reads Valid Rate 0% in amber and an estimated reimbursement of $0.00. Open a claim, if one could exist, and the check panel reads "0 rules checked" above a Grand Total of $0.00 over no lines. In a development copy of PTRS, where the twenty checks are present, the same claim fails one of them every time and can never be submitted. In an installed copy, where the checks are absent, no claim can ever be blocked.

Numbers this page does not carry

"Reimbursement recovered", "meals claimed per month", "claim acceptance rate" and "hours saved per claim" are the figures an evaluator asks for. They are not here, and they are not unknown. They are undefined, because no claim has ever been created and no meal record has ever been marked valid.

The rate figures on The reimbursement arithmetic are quoted as what PTRS contains, not as the published federal rates. PTRS holds two rate tables citing the same Federal Register notice that disagree in every shared cell. Take the rates from the notice itself.

What has been built

Every CACFP screen was checked. There are thirty-three, in four groups. Each loads. What each can do is below.

Meal counting and the monthly claim

Screen	What it is	What it can do today
CACFP Meal Service (the overview)	Allergy alerts, a meal count form, the monthly claim panel, the meal record list	Loads. The form cannot save. Two of the four claim figures are fixed at zero
Meal Records	Date arrows, five meal period cards, the history in three tabs	Loads. Validated always reads 0. Needs Attention always holds every record
A meal record's detail page	Counts by age group, menu, check results	Loads. The check results block never appears, because no check result is ever stored
Point of Service Entry	Daily limits, a count form, a daily roster	Loads. The form fails on every save. The roster lists meal types, not children
Claims Management	Status filter, claim cards, Create New Claim	Loads. Empty for ever; the button always fails
A claim's detail page	Status timeline, check panel, line items, adjustments, certification form	Cannot be reached, because no claim exists
Claim History & Analytics	Revenue forecast tiles, monthly trends	Loads its empty state. The first real row would break the page
Consolidated Claims	Multi-site totals	Empty for ever. Nothing can create one. Not in the menu
Reimbursement Rates	The fiscal year's rate schedule	Reads "No rates configured." for ever
Attendance-Meal Reconciliation	Meals against attendance, day by day	Reads "Failed to load reconciliation data." for ever. Not in the menu

Enrolment, eligibility and records

Screen	What it is	What it can do today
CACFP Enrollment	Summary tiles, the area eligibility card, the participant list, Enroll	Works. The one eligibility screen that completes. The tier is typed by hand
An enrolment's detail page	The participant's enrolment	Works, and nothing links to it. Always shows four fields
Recordkeeping & Document Retention	Three package buttons, a package list	Loads. All three buttons fail. The list is empty for ever. Not in the menu
Offline Mode & Sync	A connection pill, sync tiles, queued entries	Loads. Nothing ever enters the queue. The pill reads backwards. Not in the menu
Real-Time Feed	Live events, recent background jobs	Loads and connects. Can never show a meal count

Menus, food and inventory

Screen	What it is	What it can do today
Food Item Catalog	Search, filter, a paged list	Reads "No food items found." for ever. Nothing in PTRS can add a food item
Meal Pattern Rules	Rule set grid, age group mapping	Reads "No meal pattern rule sets configured." for ever. The mapping shows in development copies only
Cycle Menu Planning	Menu cards, New Cycle Menu	Loads. The button always fails, and a cycle menu can hold no meals
Menu Template Library	Template cards, New Template	Loads. The button always fails. The green tick is a value somebody typed
Inventory Management	Four tiles, low stock strip, lot list, FIFO queue	Loads without its tiles. Shows codes where a food name belongs. Record Transaction always fails
Multi-Site Inventory	Four tiles, a per-site list	Works. Every figure is zero, because no lot can be created
Procurement & Vendors	Budget tiles, order list, Vendor, New Order	Loads with two of three tiles. Both buttons always fail
Buy American Compliance	Four tiles, a record list, New Record	Loads. Compliance rate reads 0.0% for ever. The button always fails. Not in the menu
Special Dietary Accommodations	Substitution form, allergen cross-reference, history	Loads. The cross-reference works. Every value the form's basis dropdown offers is refused

Operations and compliance

Screen	What it is	What it can do today
Temperature Logs	A new log form, a flat list of readings	Loads. The form saves for one of its five log types. No reading can be added
Production Records	Date range, new record form, list, a second temperature form	Loads. The form always fails. The date range is never sent
Vended Meal Management	Configuration tiles, service window form and list	Every request fails. Reads "No service windows configured." for ever. Not in the menu
Civil Rights Compliance	FNS-101, complaints, poster records, training	Loads, read-only. The FNS-101 breakdown never appears; two columns are always blank
CACFP Training & Staff Management	Four tiles, four tabs	Loads, read-only. The compliance rate does not count training; every site card is red
Annual Training Calendar	Four tiles, a record list	Loads, read-only. There is no calendar; the staff column shows a code
Corrective Action Plans	Status filter, Create New CAP, plan cards	Loads. The form fails five ways; Completed shows everything; every card links to a page that does not exist
Self-Audit Dashboard	New Audit, an audit list	Loads. The form always fails, and no audit can be completed
Review Readiness	Readiness dashboard, compliance score, DENARS generator	Loads its three empty states. Both figures fail to load; the generator always fails

What happens on its own

Nothing. No CACFP task runs on a schedule. PTRS has a nightly reconciliation of meals against attendance, built and ready, that is never scheduled, and the manual Run Reconciliation button that would start it fails.

A development copy of PTRS is given twenty claim checks, five meal pattern rule sets with 70 rules, 84 serving requirements and 6 age group mappings when it is first created, for one organisation only. An installed copy is given none of them. Neither copy is given a single food item, and that is the omission that matters, because the meal pattern check matches menu items against the food catalogue and never reads the rules. See What makes a meal reimbursable.

What it connects to

Part of PTRS	How
Attendance	PTRS can compare a day's meals against its check-ins. The comparison is reachable from no screen. The claim check that would do the same comparison, CLM-002, passes without looking
Members	An enrolment links a child to a site, a programme and a year. The form takes the child's record id as typed text; there is no picker. Two claim checks count active enrolments and can genuinely fail. See Enrol a participant
Staff	Every meal record must name a real staff member, which is why two of the three CACFP count screens fail. CACFP keeps its own staff training, role and food safety certificate records, unconnected to the Staff module's credentials. See Work the civil rights and training screens
Health and Safety	Not connected. The temperature safe-range check lives in CACFP and nothing in Health and Safety reads it
Documents	CACFP has its own attachment store. No screen can put anything in it. It is unrelated to staff personnel files and site documents
Compliance	One compliance check compares the days with a meal record against the days with an attendance session over 30 days. It is part of a check that fails before it saves anything. The CACFP Compliance card on the Compliance Radar reads real CACFP compliance records; the Meals vs Present bar under it is invented as 85% of the headcount and should be quoted by nobody
Notifications	Not connected. Nothing in CACFP creates a notification, and PTRS has never sent one by any path
Audit	Connected and real. Every meal count, correction, deletion and claim step is written to the tamper-evident audit log

Not yet available

A claim cannot be created, so the whole claim process is out of reach

The Create New Claim button on Claims Management sends the programme name "CACFP". PTRS knows two programmes, ARAS and SFSP, and refuses with "Invalid program type: CACFP." That button is the only thing in PTRS that starts a claim. Because no claim exists, the claims list is empty, the claim detail page cannot be opened, and checking, submitting, approving, rejecting, amending and adjusting a claim are all out of reach. The status filter offers six statuses over an empty list. The process as designed is on How a claim moves through its lifecycle.

A meal record is never marked valid, so no meal can be reimbursed

Every way of saving a meal record marks it not valid, and nothing in PTRS marks one valid. The meal pattern check runs when you press Validate on the two count forms that cannot save, shows its verdict, and stores nothing. Two things follow. The reimbursement estimate adds up only valid meals, so the estimated reimbursement is $0.00 and Valid Rate is 0% for ever. And the claim check CLM-005 counts days with a valid meal record, finds none, and blocks the claim. In a development copy, the only place that check exists, no claim can pass.

The claim checks run zero rules outside a development copy

The twenty claim checks are given to a development copy of PTRS when it is first created, for one organisation only. There is no screen, no setting and no other way to give them to an installed copy. So in an installed copy the check panel reads "0 rules checked" and reports that the claim can be submitted, and the submission gate passes everything. That is the same shape as the Compliance Radar's FULL PASS over zero checks.

Eleven of the twenty checks do not test what their name says

Only nine kinds of check are built. The twenty rules are mapped onto them, so eleven rules run a different rule's test. CLM-010 (60-day deadline), CLM-012 (meal pattern), CLM-013 (production record), CLM-014 (temperature log), CLM-018 (vended meal documentation) and CLM-019 (non-programme food) all run the meals-against-enrolment test. CLM-011 (certification) runs the enrolment test. CLM-016 runs the daily limit test. CLM-020 runs the rate test. CLM-015 and CLM-017 run the attendance test. So a claim can fail "Temperature Log Documentation" with the message "Total meals (N) may exceed enrollment capacity across the claim period." and pass "Production Record Documentation" with no production record anywhere. Two of the nine built checks pass without looking, and between them cover four rules including CLM-002, which is federally required and blocking. The rule-by-rule list is on How a claim moves through its lifecycle.

The Delaware daily meal limit is never applied

PTRS holds the rule correctly: two meals, two snacks, three events a day per child, counted across every site in the organisation, with the meal recorded either way for the audit trail. Nothing ever runs it. So the per-child meal log it would write is empty, the two claim checks that read it (CLM-004 and CLM-016, both blocking) report zero violations on every claim, and the Daily Meal Roster on Point of Service Entry lists meal types rather than children. The rule is written out on The reimbursement arithmetic.

The rate table cannot be loaded from any screen

PTRS can hold a rate for each programme, meal and tier, and no screen can create, amend or load one. Reimbursement Rates reads "No rates configured." in every installation, followed by an instruction to load the USDA rates, and there is no control anywhere that loads them. Two consequences for whoever fixes that. PTRS would let a rate be changed after a submitted claim used it, because the guard against that looks at claim lines that nothing writes. And the page works out the fiscal year as October to October, so from 1 October 2026 it asks for a year neither built-in table is labelled with.

PTRS holds two rate tables for the same year that disagree

Two built-in FY 2025-2026 rate tables both cite Federal Register notice 89 FR 70890 and differ in every shared cell. Free-tier lunch is 3.92 in one and 4.53 in the other. Only the first can reach a database today, and only by a route no screen offers. Both are printed side by side on The reimbursement arithmetic. Neither is presented as the published rate.

Claim History & Analytics reads eight figures PTRS does not send

The monthly trends list and the revenue forecast tiles both look for names PTRS does not use. Both are empty today because no claim exists, so both show their empty state correctly. The first trend row that ever exists will take the page to an error. The forecast's third tile is labelled as a percentage and the nearest real figure is a count of months.

Reconciliation cannot be loaded or run

Attendance-Meal Reconciliation asks for "all" sites where PTRS needs one site, so both requests fail before they are read. The page reads "Failed to load reconciliation data. Please try again later." and Run Reconciliation fails the same way. The page has no site picker and is not in the menu.

Real-time meal updates go to a channel that is switched off

When a meal record is created, corrected or deleted, PTRS announces it on a CACFP channel that is never switched on, so the announcement reaches nobody. Real-Time Feed connects to a different channel, the dashboard's, which is on. So the page shows Connected in green and can show check-ins, check-outs and OCCL deadline warnings, and can never show a meal count. See Read the records and offline screens.

Nine claim and meal actions are built and reachable from no screen

Check a claim without submitting it (the panel says "Run validation to check this claim." and offers nothing to press). Amend an approved or paid claim. Override a failed check (the Override button does nothing when pressed). Add an adjustment. Create a consolidated claim. Three claim reports. Record nonprofit food service costs. In all, 29 of the 54 things PTRS can do with meals and claims are reachable from no screen. See Who can do what with meals and claims.

The audited correction path is out of reach, and the reachable one records no reason

PTRS has a correction that asks for a reason and writes the old and new counts to the audit log, and a removal that keeps the record and notes why. No screen uses either. The Edit button on Meal Records records that a correction happened and not what changed. The Delete button erases the record outright; the audit line survives, the record does not.

The eligibility tier is typed by hand, and nothing that runs ever reads it

The enrolment form's Eligibility Tier is a three-option dropdown starting on Free. Whatever you choose is stored as typed. PTRS does not check it against an income application, an area eligibility record or the determination method beside it, and no screen can change it afterwards. The one reimbursement estimate that runs prices every meal at the Free rate regardless. So the tier is entered by a person, supported by nothing PTRS holds, and used by nothing PTRS works out. See How a participant becomes eligible.

The household income application, the only place a tier is worked out, has no screen

PTRS can take a household's size, income and pay frequency, annualise the income, compare it against the thresholds and produce a tier. It can approve or deny it. None of this has a screen, a dialog or a menu entry. An approved application never expires, although PTRS records the expiry date. An approval cannot be reversed and a denial cannot be appealed. The last four digits of the signing adult's Social Security number are stored as typed, in a field whose name says encrypted; nothing in PTRS encrypts anything.

The income thresholds have never been loaded, so a built-in fallback decides every tier

The threshold table PTRS would compare income against can be filled only by a route no screen offers. It is empty in every installation, so a built-in set of FY 2025 figures with no citation decides every tier. They are printed, with the arithmetic, on How a participant becomes eligible, as what PTRS contains rather than as the published guideline. Unlike the rates, PTRS holds one threshold table, not two.

The income verification cycle has no screen, and one of its four outcomes cannot be recorded

Drawing the 3% sample, requesting a verification, completing it and listing what is outstanding are all built and none has a screen. The sample is 3% of approved applications, rounded up, at least one, drawn against whatever is approved at the moment rather than an as-of date, and a second run draws a further 3%. The "no response" outcome, the one the follow-up process exists for, is spelt one way by the form check and another by PTRS's own list of outcomes, so no input can record it.

Area eligibility can be read and cannot be recorded

The Area Eligibility card on CACFP Enrollment reads a record no screen can create, update or list. Its amber state, "This ARAS site requires area eligibility documentation (50%+ free/reduced enrollment from feeder school)", names a requirement the screens cannot help you meet. A site that does not reach 50% cannot be recorded at all, so there is no way to note that it was assessed and did not qualify. An update is not re-checked, so a record made at 60% can be edited down to 10% and kept. The expiry date is recorded and never applied, so a lapsed certification looks current. And any account that can use CACFP can mark a site state-approved.

An enrolment cannot be corrected, withdrawn or deleted

The form is the only enrolment control there is. Changing a tier or status and withdrawing a participant are built and reachable from no screen; deleting does not exist. Every enrolment PTRS has ever made is Active, which is why the Inactive tile is a label over a constant zero and the status filter's other choices return nothing. Three of the seven fields on the detail page never appear. Nothing links to the detail page.

Nothing puts a meal into the offline queue, and nothing takes one out

Offline Mode & Sync is a viewer for a queue with no producer. No screen and no background process ever adds an entry, and nothing turns a queued entry into a meal record. Three of its four tiles read figures PTRS does not send, and its Online / Offline pill reads Offline when PTRS answers and Online when it does not.

A DENARS package holds no document, and neither button that asks for one works

Asking for a package records that a package was asked for, marked Generated, and produces no file. Nothing in PTRS builds the document. Both places that ask, Recordkeeping & Document Retention and Review Readiness, send "all" where one site is needed, so both fail before PTRS reads the request. Two of the three package buttons also name a package type PTRS does not have.

Eleven more actions with no screen: compliance records and closing the year

Creating, editing, moving and deleting the CACFP compliance records that the Compliance Radar's CACFP Compliance card reads have no screen, so that card shows data nobody using PTRS can put there. Closing a programme year, reconciling it and producing its final report have no screen either. Closing the year reports "Closed" with a count of claims frozen, and freezes nothing. All three compare twelve months of meals against twenty-four months of claims. The final report carries four fixed zeros and reports 100% compliance whenever no corrective action exists.

Nothing in PTRS can add a food item, so the meal pattern check has nothing to match

The food catalogue can be filled only by a route no screen offers, and no built-in items exist. The meal pattern check matches typed menu items against that catalogue by name. With it empty, every item is unrecognised, every required component is missing, and every meal fails with one warning per item. Eight details of a food item, including milk fat and sugar content, can be recorded by no path at all, so four of the ten cross-component rules, including both milk rules, can never fire.

The seventy meal pattern rules exist only in development copies, and the check never reads them

The rule sets are given to a development copy for one organisation and to nothing else. The check itself keeps its required components as a fixed list and reads the rules for no purpose. Sixty-two of the seventy are exact duplicates; the PM snack set has one rule where the AM snack set has seventeen. And the Meal Pattern Rules screen shows its empty state in every copy, because it reads the list under the wrong shape.

Every create form on the menu and inventory screens fails

Seven forms across five screens, and not one reaches PTRS. Each sends a site or staff member it never asked you for, as a blank, or offers a dropdown whose values PTRS does not recognise, or leaves out something PTRS requires.

Screen and button	Why it fails
Cycle Menu Planning, New Cycle Menu	Who created it is never sent. The programme "CACFP" and the scope "All" are not names PTRS knows
Menu Template Library, New Template	The pre-validation status is never sent. Low, Medium and High are not complexity values PTRS knows
Inventory Management, Record Transaction	Who transacted it is sent blank
Procurement & Vendors, Vendor	The site is sent blank
Procurement & Vendors, New Order	The site is sent blank, and the total is sent as 0 on a form with no amount field
Buy American Compliance, New Record	The site and the food item are sent blank
Special Dietary Accommodations, Record Meal Substitution	The site and the meal record are sent blank, and all four basis values are refused

The inventory tiles fail the same way, and that failure is protecting the page: if they loaded, they would read figures PTRS does not send and break the page. The full list is on Who can do what with menus and inventory.

A cycle menu holds no meals, and a menu template holds no items

Creating a cycle menu makes one empty day per day of the cycle. Nothing in PTRS writes a meal into a day. A template's item list is fixed at empty and never shown. The three components built for exactly this exist and are used by no screen, as are thirteen of the twenty-six components in this part of PTRS. Approving a cycle menu, from any status to any other with no rule between, is reachable from no screen.

A first-in-first-out inventory ledger with no way to create a lot

Issuing stock is one of the better pieces of PTRS: it takes from the oldest lot first, refuses the whole issue if the total is short, and keeps a running balance per lot. No screen can create a lot. The order is the order lots were entered, not their expiry date, so a lot entered later but expiring sooner is issued last. A site transfer moves nothing: it records the transfer and changes no lot at either end.

Procurement analytics is the one thing staff members cannot see, and no screen shows it to anyone

Three procurement reports are correctly worked out, remembered for five minutes, refused to staff members, and reachable from no screen. On-time delivery is a fixed 14 days from the order date. The spend report's Buy American percentage comes from a different record than the Buy American Compliance screen's, so the two can never be reconciled. See Procurement analytics.

Buy American compliance reads 0.0% for ever, and the screen is not in the menu

The compliance flag is copied from the form as sent, never worked out from the domestic tick or the country of origin, and the form never sends it. So it is off on every record, the Compliance Rate tile reads 0.0% above rows that each read "Domestic: Yes", and the list hides the column that would show the contradiction. An exception can be requested and never granted. The page uses the calendar year as the fiscal year, so it is wrong from 1 October, and keeps the value for the life of the tab. Nothing links to the page.

Ten special dietary actions have no screen, and one would show every organisation's data

A physician's dietary statement and an allergy emergency protocol, including a meal-service banner for life-threatening allergies, are built with no screen. The only allergy information a user can reach is the cross-reference panel, which shows an allergen name and no severity, response steps or medication location. One approved-items list would return every organisation's food catalogue to anyone who asked; nothing asks, and the catalogue is empty everywhere, so the exposure today is nil, by accident.

Nothing on a screen can record a temperature reading, and four of the five log types are refused

PTRS works out whether a reading is in the safe range, stores the corrective action and updates the log. No screen has a reading form. The log form offers Receiving, Cooking, Holding, Cooling and Reheating; PTRS knows Receiving and Meal Service, so four of the five are refused and the one for a meal service cannot be chosen. An out-of-range reading raises no notification, opens no corrective action and fails no compliance check. The thresholds are on Temperature and production fields.

Meal service windows and site CACFP settings are stored and read by nothing

Both are fully built, with duplicate checks and audit lines, and nothing else in PTRS reads either. A service window governs no meal count: the five cards on Meal Records carry fixed times. A configured correction window changes nothing: the 60 days are fixed. The one screen that would set them, Vended Meal Management, is not in the menu and sends "all" on every request, so all three fail. And there is no vended meal delivery at all: the agreement and delivery records exist in the database and nothing in PTRS reads or writes them.

Not one civil rights record can be created, and the FNS-101 breakdown never appears

Recording demographics, a complaint, forwarding it, resolving it, certifying the annual log, a poster record, a poster check and civil rights training all have no screen. Civil Rights Compliance is four read-only tabs. The FNS-101 breakdown looks for a shape PTRS does not send, so it never appears. Display Location and Method are blank on every row for the same reason. Certifying the annual complaint log would count zero complaints, because it compares a four-digit year against the nine-character programme year every screen sends. There is a second, unrelated poster record with three more actions and no screen; the readiness check reads the first, so a poster recorded through the second counts for nothing. PTRS names no required poster.

The CACFP training compliance rate does not measure training

The rate counts role assignments marked Authorized, not training records. Every new assignment starts Unauthorized, and the only action that changes it has no screen. So the tile reads 0.0% in any database whose assignments were not entered by hand. Creating and completing a training record has no screen. PTRS holds no annual training hour minimum.

Every site coverage card is red, and PTRS holds two unrelated food safety certificate models

The Site Coverage grid on CACFP Training & Staff Management looks for three names PTRS does not send, so every card reads "No food safety certification", including a site with five current certificates. A certificate cannot be created from any screen. A second certificate model with four more actions has no screen and is read by nothing. Nothing warns before a certificate or training expires: the alert record with its 30, 14 and 7 day reminders is written and read by nothing, and CACFP schedules no task.

The corrective action form fails five ways, and no plan can be updated, verified or closed

The form sends a blank site and a blank responsible person, both of which it never asked for. Past those, Source Type starts on "Select source…", which is refused; of its four choices only Self-Audit is a name PTRS knows; none of Minor, Major or Critical is a severity PTRS knows (its three are Observation, Finding and Serious Deficiency); and Finding Category refuses its own example, "Meal Pattern", because PTRS spells it without the space. Every card links to a page that does not exist. Every plan stays Open. The Completed filter returns every plan. The severity chip is always grey. Overdue is never applied to the stored plan.

A self-audit can never be completed, and there is no site monitoring screen

Submitting self-audit results is built and reachable from no screen, so every audit reads Needs Attention and Complete: No. The New Audit form sends a blank site, so no audit can be created from a screen either. A sponsor's own monitoring review of a site, seven actions in all, has no screen and no page. The five programme calendar actions are in the same position.

Review readiness is the best reporting in CACFP, and no screen has ever shown it

Nineteen checks in eight categories, naming every missing item, and a score whose eight weights add up to exactly 1.00. Review Readiness asks for "all" sites where one is needed, so both fail before PTRS reads the request, and the page shows "No readiness data available." and "No compliance data available." Eight of the nineteen checks can never pass in an installed copy, because nothing in PTRS can create what they count, so a perfectly run site cannot score above 11 of 19. One check is backwards: Health and Safety awards half its marks for having no open corrective action, so recording a finding honestly lowers the score.

Sixteen more actions with no screen: documents, non-participant meals and a second cross-organisation read

Attaching, listing, downloading and deleting a document have no screen, which is why the Administrative Records readiness category scores 0 of 1 everywhere. Adult and visitor meals, which must be counted separately, cannot be recorded from any screen. One background-jobs list is not limited to your organisation; it is harmless only because nothing ever writes a background job record. Ten actions in this group check nothing about what they are sent, and none of the 31 that do check sets a maximum length, so an over-long value is an error rather than a message.

There is no reviewer workflow, and the OCCL auditor role reaches nothing here

The component that would show a state reviewer what they looked at has no page and no data. The OCCL auditor role satisfies no CACFP permission, so a visiting reviewer would have to be given one of the five working roles, which grants the whole of CACFP, claim approval included.

Where these are recorded

These are defects in PTRS, not in this guide. They are written up for the PTRS team in the CACFP findings document. This guide describes PTRS as it behaves today.

Where to go next

Do one task:

• Record your first meal service day, the one working path, end to end
• Record a meal count, and why the three CACFP screens that offer to cannot
• Correct or remove a meal count, the 60-day window and the edit dialog that adds instead of replacing
• Enrol a participant, the one eligibility flow that completes
• Work the menu and food screens, the inventory and procurement screens, the special dietary screen, the food safety and records screens, the civil rights and training screens and the review and corrective action screens

Read a screen:

• Read the CACFP meal service screens, which figures mean anything
• Work the enrolment screens, what the three panels count
• Read the records and offline screens

Look something up:

• The reimbursement arithmetic, the rate tables and the one formula that runs
• Meal and claim fields and Enrolment and eligibility fields
• Who can do what with meals and claims and Who can do what with enrolment and records
• Who can do what with menus and inventory, Procurement analytics, Who can do what with operations and compliance and Temperature and production fields

Understand why:

• How a claim moves through its lifecycle
• How a participant becomes eligible
• Why counts must be point-of-service
• What makes a meal reimbursable and What a CACFP review asks for

When something goes wrong: CACFP troubleshooting.