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.

Only one of the four can be created from the interface today

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

The four quantity fields are the least constrained regulated figures in the module

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