Read the records and offline screens
Tom is about to rely on three screens he rarely opens. This page is how to know what Recordkeeping & Document Retention, Offline Mode & Sync and Real-Time Feed are showing him, and which of their numbers can ever change.
Recordkeeping & Document Retention and Offline Mode & Sync are absent from the sidebar and reachable only by typing their web address. Real-Time Feed is in the sidebar, under CACFP → Real-Time Feed.
Recordkeeping & Document Retention, DENARS packages
Subtitled "DENARS package management and CACFP document retention tracking." Two things on the page: three buttons and a table.
The three buttons always fail
Annual Package, Review Package and Audit Package, shown only to a site director and above.
All three ask for a package for "every site" and the current calendar year as the programme year. PTRS expects one specific site and expects the programme year as text in its usual shape, so the request fails before PTRS acts on it.
What you see: a red toast reading "Failed to generate package," every time, on all three buttons.
Two further mismatches sit behind that one, and would surface if it were fixed: PTRS only recognises four kinds of package, DENARS, Annual, Monthly and On Demand, so Review and Audit would then fail with a message saying that kind of package is invalid. Only Annual names a kind PTRS recognises.
Worth knowing before this is fixed. Asking for a package records that a package was asked for, marks it Generated, and stores no document with it.
Nothing in PTRS assembles that document. There is no service behind this action that produces a file, the action records a row and stops. Downloading a package returns the same blank result, and no screen offers a download either.
So a row marked Generated is a record that a package was requested, not a package. The DENARS documentation itself is not assembled by PTRS.
The table
Generated Packages, with Program Year, Type, Generated and Status. It shows every package in the organisation, newest first, 25 at a time, with no way to see the next page, so page 2 is unreachable regardless of how many packages exist.
Empty state: "No DENARS packages generated yet." Since the only two places that could create one both fail, this page, and the generator form on Review Readiness, that is the state it is in.
The status pill can show Generated · Pending · Failed · Draft. Only "Generated" is ever actually written.
Offline Mode & Sync, the sync queue
Subtitled "Manage offline meal entries and synchronization status."
Uploading a batch of offline entries is the only way anything gets added to this queue, and nothing in PTRS ever calls it, no screen, no offline handling, nothing.
The parts of PTRS that let you keep using it without a connection only remember what you have already loaded, for a while; they do not save a failed meal count for later. So a save made while offline is simply a save that failed.
The queue is therefore always empty, and every number on this page is zero or blank. The page is a viewer for a feature with nothing feeding it.
The header indicator is inverted
Top right, an Online / Offline pill.
The information PTRS actually sends back does not carry the one figure the pill is built to read. So the pill behaves like this:
| Situation | Pill reads |
|---|---|
| The request to check status succeeded | Offline |
| The request failed, or you are not signed in properly | Online |
| Still loading | Offline |
The pill reads Offline when PTRS is reachable and Online when it is not. It is not reporting your connectivity at all, nothing on this page reads your device's own connection state.
Ignore it.
Sync Status
Four tiles. Three of them look for figures PTRS does not send under those names.
| Tile | What you see |
|---|---|
| Queue Depth | The real count, always 0 |
| Failed | Blank |
| Last Sync | "Never" |
| Conflicts | Blank |
The red "n failed entries" banner can never appear.
PTRS's per-device breakdown, queued, synced, failed and conflict counts and a last-sync time for every device, comes back with the status and is read by nothing on this page.
Queued Entries
Empty state: "No entries in the offline queue."
If a row ever existed it would show the wrong label. PTRS has four sync states, Queued, Synced, Failed, Conflict, and this panel's colour map does not include Queued, so it falls through to an amber "Pending" instead.
Only Queued is ever written. Failed and Conflict have no writer anywhere in PTRS, and Synced is written only by the conflict-resolution action, which refuses anything that is not already Failed or Conflict, and so can never succeed.
The synced timestamp, the error message and the link to the resulting meal record therefore have no writer either.
And nothing turns a queued entry into a meal record
Worth stating separately, because it is the thing the page is named for. There is nothing anywhere in PTRS that reads a queued entry and turns it into a meal record.
If the batch upload action were ever connected to a screen, meals uploaded from a device would sit in this table and never become meal counts.
The screen piece built to resolve a sync conflict is used by no page, and its three buttons offer choices that do not match any sync state PTRS would accept anyway.
Real-Time Feed
Subtitled "Live meal counts, background job status, and system events." Two panels, and a connection indicator.
The connection is real
This page connects to PTRS's dashboard notification channel, the one channel of four that PTRS actually switches on. It joins your site's group automatically, with no action needed from you.
The indicator therefore genuinely reads Connected in green when the channel is up, and shows the connection error text beside an amber dot when it is not.
It can never show a meal count
Live Events listens for events on that channel. Seven kinds of event exist in PTRS, and only three can ever arrive here:
| Event | Reaches this page? |
|---|---|
| A child checking in | Yes, sent to your site's group |
| A child checking out | Yes, when a check-out happens |
| A ratio alert | No, nothing in PTRS ever triggers it |
| An incident created | No, nothing in PTRS ever triggers it |
| An incident submitted | No, nothing in PTRS ever triggers it |
| An OCCL deadline warning | Yes, sent to the whole organisation |
| A compliance alert | No, its one path forward is blocked earlier on |
So three of the seven can arrive: a check-in, a check-out and an OCCL deadline warning. A meal count is not among them and cannot be, meal-record events are announced on the CACFP notification channel, which PTRS never switches on.
Until an event arrives the panel reads "Waiting for events…" On a site with attendance activity you will see check-ins scroll past on a page titled "Live meal counts."
Recent Background Jobs is permanently empty
"No recent background jobs."
PTRS keeps a table meant to hold a record of every job it runs on a schedule. Nothing writes to it, none of the module's scheduled tasks logs into it.
This is a table with readers and no writer, the same shape as the three found in Compliance and Centers.
What to do instead
| If you need to | Do this |
|---|---|
| Assemble records for a state review | Outside PTRS. Asking PTRS for a package records the request and produces no document |
| Record meals when the site has no connectivity | Take them on paper and enter them afterwards through the header's + → Meal Count dialog, see Record a meal count |
| Watch meal counts arrive in real time | Not possible. Reload Meal Records for the date |
| See whether a background job ran | Outside PTRS, with your PTRS administrator |
Related
- Record a meal count, the one working entry path
- Who can do what with enrolment and records, every action in this half of the module and which have a screen
- Enrolment and eligibility fields, what a queue entry and a package row actually store
- CACFP troubleshooting
Checked against PTRS on 7 September 2026.