Work the food safety and records screens

Tom wants a temperature log on file before the health inspector's next visit, and Denise wants to know why last week's production records never show up. This page is how to read Temperature Logs, Production Records and Vended Meal Management, two of the three are in the CACFP menu, and the third is not.

Who can do this

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

Temperature Logs and Production Records show their forms to everyone PTRS admits. Vended Meal Management hides its New Service Window button from staff members, though PTRS itself would accept the same request from a staff member's account.

Before you start

Both Temperature Logs and Production Records read from the site selected in the header, falling back to your first site. With no site selected and no single-site account, they show "No Location Selected" and make no request.

Temperature Logs

New Temperature Log, Date, Log Type, Notes, Create Log.

Then a list of readings, drawn from every log the site has, flattened into one sequence.

Create a log

1. Leave Date at today, or pick the service date.
2. Set Log Type. Choose Receiving. The dropdown offers five values and PTRS recognises two, so Receiving is the only one that saves.
3. Add Notes if you want them.
4. Press Create Log. A green "Temperature log created successfully" means the row was written.

Four of the five log types are refused

The dropdown offers Receiving, Cooking, Holding, Cooling and Reheating. PTRS only recognises two log types: Receiving and Meal Service.

Cooking, Holding, Cooling and Reheating are each refused. The form shows "Failed to create temperature log. Please try again," which does not name the field, so retrying does not help.

Meal Service, the kind of log a reviewer asks about most, cannot be selected at all.

Cooling and Reheating are actually names PTRS uses for a reading's own type, not a log's type. The dropdown is offering reading types where a log type belongs.

Record a reading, you cannot

Nothing in the interface can add a temperature reading to a log

Adding a reading to a log is built completely: it records the reading type, works out whether it is in the safe range, stores any corrective action text, updates the log's two summary flags and records it in the audit trail.

No screen calls it, and there is no reading form on this page or anywhere else. The green-or-red pill built to show one reading is used by no page.

The consequence: a log created here has no readings, so the list below the form stays empty in a new copy of PTRS, and the log's "has out of range entries" and "all corrective actions documented" flags stay at their starting values.

Marking a log complete is in the same position, built and reachable from no screen.

What the list shows

The page takes every log for the site, flattens their readings into one sequence and shows one row per reading: food item, the temperature in °F coloured green or red, the reading type, a tick or a cross, the corrective action, and a timestamp.

Two things about it:

• There are no column headings. The row is built without a proper table around it, so the six values appear in order with nothing labelling them.
• The list is not grouped or dated by log. Readings from different logs and different dates appear in one sequence, newest log first, then in the order the readings were added.

The thresholds behind the green and the red are printed in full on Temperature and production fields.

Nothing happens when a reading fails

An out-of-range reading is stored, rolled up onto its log and shown in red. It raises no notification, opens no corrective action plan and fails no compliance rule. The only place an out-of-range reading has any further consequence is completing a log, which refuses to complete one with an undocumented out-of-range reading, and no screen calls that action either.

Production Records

A date range picker, a New Production Record form, the record list, and a second copy of the New Temperature Log form at the foot of the page.

The date range picker changes nothing

The picker holds a start and end date, and the list request never actually sends them. So the list is whatever PTRS returns with no date limit at all: every production record the site has, newest first, 25 at a time, with no way to see the next page.

New Production Record fails on every submit

A production record cannot be created from this form

The form collects Date, Meal Type, Meals Prepared, Meals Served and a free-text Staff ID. On submit it sends an all-zero meal record id, and PTRS requires a real one.

There is no meal record picker on the form, so there is no value you could supply instead. Every submit fails and the form shows "Failed to create production record. Please try again."

A second problem sits behind it: Staff ID is a free-text box sent straight through as if it were a real staff record's id, so anything not shaped like one fails before PTRS even checks it. There is no staff picker.

And a third: the form sends a blank record of which USDA components the meal met. That passes PTRS's check for something being present, so it would not block the save, but the field is the record's statement of which components the meal met, and the form records none of them.

The record list

One card per record: meal type, production date, review status, and "Prepared: n · Served: n."

Records only ever exist if created outside PTRS, so a fresh copy of PTRS reads "No production records found."

Review a record, you cannot

Production record review has no screen, and its screen piece would fail if it had one

The screen piece built to review a record shows meals prepared, served, a worked-out leftover figure, the status, a review notes box and Approve and Reject buttons. No page imports it, so it is not reachable.

If it were, neither button would work. Both send a blank reviewer, which PTRS refuses, and Reject sends a status PTRS does not define; its three statuses are Pending Review, Approved and Needs Correction.

So the review status is permanently Pending Review on every production record, and who reviewed it and when have no writer a person can reach.

The temperature form appears twice

The temperature log form is shown at the foot of this page under the heading Temperature Logging, and again as the whole of the Temperature Logs screen. It is the same form with the same five-value dropdown and the same one working option. A log created from either place appears on Temperature Logs.

Vended Meal Management

This screen is not in the menu. The sidebar lists eight of the nine screens in this group; this one is not among them. It is reachable only by typing its web address.

The screen has four configuration tiles, a New Service Window button, a service window form and a service window table.

Every request the page makes fails

All three of this screen's requests send 'every site' where PTRS needs one real site

The page asks for its configuration and its service windows across "every site," and PTRS needs one real site for both, so it refuses both requests outright.

The consequences on screen:

What you see	Why
The four configuration tiles do not show at all	They only show once configuration arrives, and it never does
"No service windows configured," always	The list request fails, so there is nothing to show
"Failed to load vended meal data. Please try again later."	The error banner, from the same failed request

New Service Window fails separately. The form starts with "every site" as its site, and the form has no site field, so that value is never replaced. A value that is not a real site id fails before PTRS even checks it, and the toast reads "Failed to create service window."

Selecting a site in the header changes none of this. The page never reads the header's site picker.

What these actions would do

The five actions behind this screen are correctly built. Creating a service 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 in the audit trail. Configuring a site is an upsert: it creates the setting on first use and updates it after, and also records the action. Both reads are kept in memory for 30 minutes.

Nothing reads what this screen configures

A meal service window and a site's CACFP configuration are stored and read by nothing

Nothing outside this one screen's own actions ever reads a meal service window. Nothing checks a meal count against one. The five meal-period cards on Meal Records carry the same fixed service times for every site, recorded on Who can do what with meals and claims.

A site's CACFP configuration is in the same position, with one addition: one of the twenty claim checks names it in its own placeholder comment and passes without checking anything, waiting for this configuration to be wired in. It never was.

So on this screen:

Setting you would configure	What reads it
Programme, counting method, site role, hub site	Nothing
Approved site capacity	Nothing. Site capacity is enforced elsewhere, from the site's own profile
Approved meal types	Nothing
Correction window days	Nothing. The correction window used elsewhere is fixed at 60 days, written directly into those actions
Effective and expiry dates, whether active	Nothing

There is no vended meal delivery

Vended meal agreements and deliveries are stored in PTRS and have no code using them

PTRS can hold a vended meal agreement: a vendor name, contract dates, a hub site, a list of satellite sites, a contract amount and a status. It can hold a delivery against that agreement: the sites involved, a delivery date, meal type, ordered, delivered and served counts, a delivery status, a receiving temperature, whether that temperature was acceptable, receiving staff and a rejection reason.

Neither is used by any action, screen or service anywhere in PTRS.

So the screen titled "Vended Meal Management," subtitled as managing meal service windows and vended meal delivery, contains no vended meal functionality of any kind. A satellite site receiving meals from a hub kitchen cannot record the agreement, the delivery, the counts or the receiving temperature.

What to do instead

You need to	Today
Prove a holding temperature was taken	Keep the paper log. PTRS can create the log header and cannot record a reading
Record a meal-service temperature log, not a receiving one	Not possible, Meal Service is not offered by the form
Produce a production record for a reviewer	Keep it outside PTRS. The form fails on every submit
Have a supervisor sign off a production record	Not possible, the review screen piece is on no page and both its buttons would fail
Record adult or visitor meals	Built and reachable from no screen
Configure a meal service window that governs anything	Not possible, the screen cannot save one, and nothing would read it if it could
Record a vended meal delivery from a hub kitchen	Not possible by any path

Related

• Temperature and production fields, every field, and the safe-range thresholds
• Who can do what with operations and compliance
• What a CACFP review asks for
• Record a meal count, the one meal-entry path that works
• CACFP troubleshooting