Run a service day

This is the flow a club runs every single day it opens, and the only one on this whole site that is genuinely safety-critical while it is actually happening: staff-to-child ratio is the single heaviest item in DELACARE licensing, and a meal counted wrongly is a federal reimbursement mistake.

It crosses Attendance, Compliance and CACFP. Every step below has a working screen behind it. What this page adds is the one thing no single part of PTRS can tell you on its own: which of the day's own numbers you may actually rely on, and which you may not.

The day at a glance

#	Step	Part of PTRS	Documented in
1	Open the site and the day's session	Attendance	Run your first check-in day
2	Check children in, at the kiosk or from the header	Attendance	Check a child in
3	Watch the staff-to-child ratio	Attendance, Compliance	Read the ratio monitor
4	Count meals at the point of service	CACFP	Record a meal count
5	Correct a miscount before the day closes	CACFP	Correct or remove a meal count
6	Check children out, and close the session	Attendance	Check a child out
7	If the kiosk was offline, reconnect it	Attendance	Sync offline check-ins

Step 7 is not optional housekeeping. Until it actually runs, the whole day's check-ins exist in one browser only.

Steps 1 and 2: check-in

Checking in writes a permanent attendance record, and is the one step of the whole day that is entirely reliable: the record is written, it stays inside your own organisation, and it appears on the day's own roll. Check a child in covers the kiosk, scanning a QR code, the badge dialog and the header's own Quick Add, and Attendance fields covers what each one actually stores.

One property of check-in decides everything in step 3: a check-in only counts toward a ratio calculation when it names a room, and no screen in PTRS actually offers a room field at all, not the kiosk, not the Quick Check-In box, and not reconnecting after being offline. That is not a flaw in how ratio is calculated; it is simply an input that never arrives in the first place.

Step 3: the ratio, and why every ratio screen reads compliant

PTRS runs three different staff-to-child calculations, in three separate places, on three different sets of figures, and they disagree with each other. All three are set out at how ratio compliance is measured.

For a flow page, the actual chain of events matters more than the three formulas themselves, so here it is from end to end.

A check-in that named a room would write a room-occupancy record. No check-in ever actually names a room, so no occupancy record is ever written.

The ratio calculation and the compliance check both read from occupancy records. Finding none, both see zero children present and default straight to compliant.

A background job runs every 15 minutes and writes one ratio reading per room, always with a room actually set.

The ratio panel and the full-screen ratio monitor both read the newest reading per site, looking specifically where the room is not set. Those two conditions never actually overlap, so the monitor returns its own no-data result for every single site, every single time.

That is why the monitor shows a flat, zero-to-one ratio and a green "SAFE" badge under a "LIVE" indicator, no matter what is actually happening in the building.

Do not cite the ratio monitor to an inspector

It is not measuring anything at all, and it still says safe. Count the room yourself.

The background job's own readings are written, permanently, and do carry the required ratio, the actual ratio and a compliance flag. Those are what an inspection request should actually be answered from, read directly from the stored records, because the one screen that would show them asks PTRS for something it does not actually provide.

Nothing about a violation actually escalates to anyone. A ratio violation or warning is sent as a live event to every connected screen, and nothing listens for it under the name PTRS actually sends it. Nothing reaches anybody who is not already looking directly at the screen. See what happens automatically and Notifications.

Step 4: the meal count

Meal counts are recorded at the point of service, which is a CACFP requirement rather than a PTRS preference. Why counts must be taken at the point of service sets out the rule and what a reviewer actually asks for. The screens are on Record a meal count and read the CACFP meal service screens.

The count itself is written, and the money behind it is not. A meal record is created holding the counts you enter. Its own validity flag, the one every reimbursement figure in the CACFP module actually depends on, is set to false in every place that ever sets it and true in none, so the module's own estimated reimbursement stays permanently at zero.

The very same records are read by two other things that do not require that validity flag at all, and those two produce figures that are not zero. That disagreement is step 4's real consequence, and it lands at the end of the month. See Close a month.

Steps 5 and 6: corrections and check-out

Correct a miscount the same day, on correct or remove a meal count. A CACFP reviewer treats a same-day correction as ordinary practice; what they will not accept is a count reconstructed later from memory.

Checking out writes the departure onto that same attendance record and runs the check-in calculation in reverse. See check a child out. It raises no event of its own, so a room coming back inside its own limit is never actually announced anywhere.

Step 7: the offline kiosk

The kiosk keeps working with no connection at all, and holds check-ins in the browser until it can reconnect. Until then, they exist on that one device only: not on the roll, not in any count, and invisible to anyone else. The queue, its conflicts, and what reconnecting actually does with them are on sync offline check-ins.

Reconnecting writes no room either, so a check-in recovered this way counts toward a ratio calculation exactly as much as a live one does, which is to say, not at all.

What the day's own numbers are worth

At the end of the day	Trust it?
The attendance roll, who was here and when	Yes. Written on every path, including once reconnected
The meal counts you entered	Yes, as counts
The ratio monitor's own figure and its safe badge	No. It is a no-data result shown as though it were a real reading
The compliance score	There is no compliance score. The calculation fails outright on every run, and writes neither a score nor an alert. See how the compliance score is calculated
CACFP's estimated reimbursement	No. Permanently zero
The dashboard's own daily attendance figure	No. The table it reads from has no writer at all. See why analytics figures read zero

Two different attendance records, and only one of them is ever written

Checking in writes one row per child per day, and that is the roll you can actually rely on. The separate, rolled-up summary that the dashboard, Analytics, the monthly statistical report and every funder report all read from is a different table, and nothing anywhere writes to it. The roll is real; the headline figure built to summarise it is not.

What to do about it

Count the room yourself, on paper, at the times your own licence requires. No screen in PTRS can actually tell you whether a room is within ratio.

Record the count you made in a note against the day, so there is a record that survives being questioned later. See Write a note.

Reconnect the kiosk before you leave for the day. A queue left unsynced is a day nobody else can see.

Take the meal count at the moment of service, not afterward, and correct it the same day if it was wrong.

Do not quote a reimbursement figure from any screen. Neither of the two figures PTRS produces is an amount you could actually claim.

Related

• Attendance overview, Compliance overview, CACFP overview
• What each panel on the home screen shows
• Prepare for an OCCL inspection
• Close a month, where the day's own meal counts end up