Temperature and production fields
Four records, in the order a kitchen produces them: a temperature log (one per site, per day, per log type), the temperature readings inside it, a daily production record (one per meal service), and the line items on that record.
This page states what PTRS stores and what it refuses. What each screen can and cannot submit is on Work the food safety and records screens.
A temperature log can be created. A temperature reading cannot, the action is built and no screen calls it, so a log created through the interface stays empty. A production record's create form fails on every submit, and production record items have no screen at all.
The fields are documented anyway, because they are what a reviewer asks for and what a data load or an outside system would have to supply.
The safe-range thresholds
This is the one figure in the CACFP module where a wrong number is a physical risk rather than a financial one, so it is printed here exactly as PTRS holds it.
PTRS works out whether a reading is in the safe range the moment it is written, and stores that result on the reading:
| Reading type | Passes when |
|---|---|
| Holding hot, service hot, receiving hot | 135.0 °F or above |
| Holding cold, service cold, receiving cold | 41.0 °F or below |
| Reheating | 165.0 °F or above |
| Cooling | 70.0 °F or below |
| Anything else | Never |
From the regulation Attribution, and it matters here. These four thresholds are what PTRS itself contains. PTRS cites no regulation for any of them, no federal code, no FDA Food Code section, no Delaware citation. Treat the table above as what PTRS applies, and check the required holding temperatures against your own current regulatory source before relying on them operationally.
The cooling rule is explicitly incomplete, and PTRS's own design says so. A cooling reading is judged on temperature alone, within an assumed two-hour window that PTRS does not actually check, because it stores no elapsed time on a reading. A reading at 70 °F passes whether it reached 70 °F in two hours or in eight.
Nothing acts on a failing reading. Whether it is in range is stored, rolled up onto the log, and shown in red. No notification, no corrective action plan and no compliance rule is triggered by an out-of-range reading anywhere in PTRS.
Temperature log
One row per site, date and log type.
| PTRS needs | Required | What PTRS accepts |
|---|---|---|
| Site | Yes | Supplied by the page from the header's site picker |
| Log date | Yes | A real date. Defaults to today in the form |
| Log type | Yes | Receiving or Meal Service, and the form offers five values, four of which are refused. See below |
| Notes | No | Free text, no length limit |
Set by PTRS, never by you: whether the log has out-of-range entries and whether every corrective action is documented, both recomputed every time a reading is added; when and by whom it was completed; and its link to a meal record, which nothing ever sets.
The log type dropdown
The form offers Receiving, Cooking, Holding, Cooling and Reheating. PTRS recognises exactly two log types: Receiving and Meal Service.
So Receiving is the only option in the dropdown that saves. Cooking, Holding, Cooling and Reheating are each refused, which the form shows as "Failed to create temperature log. Please try again," text that does not identify the field. And Meal Service, the log type that covers a meal service, cannot be chosen at all.
Note that Cooling and Reheating are actually names PTRS uses for a reading's own type, not a log's type. The form is offering reading types where a log type is required.
Temperature reading
One row per food item measured, and no screen calls this action.
| PTRS needs | Required | What PTRS accepts |
|---|---|---|
| Food item name | Yes | Free text. Not linked to the food catalogue |
| Temperature | Yes | No check at all. No range, no sign check, no precision limit. A reading of -500 or 9999 is stored |
| Reading type | Yes | Decides which threshold applies, see the safe-range table |
| Staff member who took it | Yes | Must be filled in |
| Thermometer id | No | Free text |
| Corrective action taken | No | When given, stored exactly as typed |
Whether it is in the safe range cannot be supplied. It is worked out from the reading and its type, then stored. There is no way for anyone to assert a reading was in range.
A corrective action is what unblocks the log. PTRS marks a log as not fully documented when any out-of-range reading has no corrective action text, and completing a log fails hard, rather than with a clean message, when that is the case. Nothing catches that failure, so completing such a log would come back as a raw error rather than a clear message, unreachable today anyway because nothing calls the complete action.
The eight temperature types
Holding Hot, Holding Cold, Service Hot, Service Cold, Reheating, Receiving Hot, Receiving Cold, Cooling.
PTRS matches these without regard to how they are capitalised, so "holding hot" is accepted and "Holding-Hot" written differently is not.
Daily production record
One per meal record. PTRS's own design describes it as matching the federal rule for daily production records.
| PTRS needs | Required | What PTRS accepts |
|---|---|---|
| Site | Yes | |
| The meal record it documents | Yes | The form sends an all-zero id and has no picker, which is why every submit fails |
| Production date | Yes | A real date |
| Meal type | Yes | Breakfast, AM Snack, Lunch, PM Snack, Supper, all valid |
| Total meals prepared | Yes | Greater than 0 |
| Total reimbursable meals served | No | No check at all. May exceed meals prepared. May be negative |
| Which USDA components were met | Yes | Meant to record grain, protein, fruit/vegetable and milk as yes-or-no. The form sends an empty record, which satisfies the check for something being present and records nothing |
| Who prepared it | Yes | The form sends a free-text box straight through as if it were a real staff record |
| Notes | No | Overwritten by the review action's own notes |
| Line items | No | Each item's component must be one PTRS recognises; a bad value fails the whole request |
Two figures are returned and never written. How many meals were not reimbursable, and how many portions were left over, are both on the record and nothing ever sets either. They are permanently 0. Adult and visitor meals have their own action, built and reachable from no screen.
Three pieces of the record have no writer. A production record cannot carry its temperature readings or its substitutions alongside it; both fields exist and nothing ever fills them in. The link running the other way, from a temperature log to the production record it belongs to, also has no writer.
Review
| PTRS needs | Required | What PTRS accepts |
|---|---|---|
| Review status | Yes | Pending Review, Approved, or Needs Correction |
| Who reviewed it | Yes | Must be filled in |
| Review notes | No | When given, overwrites the preparer's own notes |
The review date is stamped as today by PTRS. There is no field for when the review actually took place.
The screen piece built for this action sends Approved or Rejected, which is not a status PTRS recognises, and a blank reviewer, which PTRS refuses. No page uses that screen piece, so neither button is reachable.
Production record line item
One row per food item on a production record, or included inline when the record is created, and no screen reaches this action on its own.
| PTRS needs | Required | What PTRS accepts |
|---|---|---|
| Item name | Yes | Free text. Not linked to the food catalogue |
| USDA component | Yes | Grain, Protein, Fruit/Vegetable, Milk, four values, where the meal pattern check itself works with five. There is no separate value for fruit alone or vegetable alone |
| Quantity planned | No | No check at all |
| Quantity prepared | No | No check at all |
| Quantity served | No | No check at all |
| Quantity leftover | No | No check at all |
| Unit of measure | Yes | Free text with no fixed list. "cups," "cup," "C," "oz" and "ounces" are all accepted and cannot be compared to each other |
| Whether it is a substitution | No | Shows an amber "Sub" chip. Carries no reason and links to no substitution record |
| Sort order | No | Whatever you send. PTRS does not set or reorder it |
A production record is what a reviewer uses to test whether enough food was prepared for the meals claimed. PTRS applies no rule at all to any of the four quantities: no check that they are not negative, no relationship checked between planned, prepared, served and leftover, and no fixed list of units. Prepared 10, served 400, leftover -3, unit "asdf" is a request PTRS accepts.
Nothing downstream reads them either. No claim check, no readiness check and no compliance rule looks at a line item; the readiness check only tests that some production record exists for the site in the last 30 days.
What each screen shows
| Screen | Shows | Note |
|---|---|---|
| Temperature Logs | Food item, temperature in °F (green or red), type, a tick or a cross, corrective action, timestamp | Shown without column headings, no table structure around the rows |
| Production Records | Meal type, date, review status, "Prepared: n · Served: n" | The date range picker sets a value the request never reads, so the range is fixed at whatever PTRS defaults to with none given |
| The safe-range pill | A green or red pill: temperature, then the type | No page shows it |
| The production line item row | Item, component, four quantities, unit, a Sub chip | No page shows it |
| The production review screen piece | Prepared, Served, Leftover, Status, then Approve and Reject | No page shows it. Its leftover figure is worked out as prepared minus served, rather than reading the stored leftover total |
Related
- Work the food safety and records screens
- Who can do what with operations and compliance
- What a CACFP review asks for
- What makes a meal reimbursable, the meal pattern side of the same question
- CACFP troubleshooting
Checked against PTRS on 7 September 2026.