Meal and claim fields

PTRS checks nothing on the screen before you press Save. Every rule on this page is applied only once PTRS receives what you sent, so a mistake is discovered only after you submit, and the message you see is the one quoted here.

Two things on this page are worth reading even if you never fill in a form: the four incompatible age-group conventions sharing one field, and the fields nothing ever writes.

Logging a meal count

This is the one action every meal-entry screen tries to use, working or not.

PTRS needs	Required	What PTRS accepts
The site	Yes	Must be a real site
The date	Yes	Must be a real date, in the usual year-month-day shape
The meal type	Yes	Breakfast, AM Snack, Lunch, PM Snack, Supper, or a sixth value the screens never offer and PTRS itself does not recognise once it looks closer, see the warning below
The counts by age group	Yes	Up to 10,000 characters
The menu items	Yes	Up to 50,000 characters
The staff member who took the count	Yes	Must be a real, existing staff record

Two traps in this table

A sixth meal type is accepted at first glance and rejected a moment later. PTRS's first check lets an "Evening Snack" value through, and then finds it is not one of the five real meal types after all and refuses it, saying so by name. No screen offers it, so this only matters to someone with direct system access.

The staff member must be real. Whoever recorded the count must already exist as a staff record. Sending anyone else fails as a database problem rather than a friendly message. This is what breaks two of the three CACFP meal-entry screens, see Record a meal count.

After the first checks pass, PTRS then:

1. Checks for a duplicate. A meal record already existing for the same organisation, site, date and meal type is refused, naming the existing record and telling you to edit it instead.
2. Adds up the total. The total served is the sum of every count you send, whatever the age bands are called. Sending something that is not a proper set of counts, a value that is not a number, or a negative number is each refused with its own message.
3. Marks the record not validated, always, with no stored check result.

The counts, and the four age-group conventions

PTRS stores whatever age-band counts it is given, under whatever names they arrive with, and adds up every number in the set regardless of what it is called. Four different screens write four different sets of names:

Screen	On-screen labels
The header's + → Meal Count (the working one)	Ages 5–8 · Ages 9–12 · Ages 13–18
The Log Meal Count composer on CACFP Meal Service	5-7 · 8-10 · 11-13 · 14-18
The Log Meal sheet on Meal Records	5 – 7 · 8 – 10 · 11 – 13 · 14 – 18
The point-of-service form	Infant · 1-2 · 3-5 · 6-12 · 13-18 · Adult
The edit dialog	0-1 years … Adult

The header dialog's bands are the ones PTRS's own design intends. The other three disagree with it and with each other.

None of these matches the age bands the federal meal pattern rules are keyed on. The total is unaffected, it is a plain sum, but no one reading a meal record can break it down by age group reliably, which is precisely what a state reviewer asks for.

The edit dialog adds to the total instead of replacing it

The edit dialog starts from the record's existing counts, held behind the scenes, and then shows you boxes for its own six age bands. If the record was created by any other screen, its original counts are held behind the scenes and not shown to you.

Saving sends everything back, what was already there plus what you typed. A record created with 10 in one band and 5 in another, total 15, edited to show 3 in a band the original screen never used, is saved with all three counts together, total 18.

The person doing the correction sees a form showing 3 and a record that now says 18. On a federal meal count. Do not use Edit to reduce a count; see Correct or remove a meal count.

Correcting and deleting a meal count

PTRS needs	Required	What PTRS accepts
The counts by age group	Yes	Up to 10,000 characters
The menu items	Yes	Up to 50,000 characters

The 60-day correction window is real and enforced on both correcting and deleting. A record whose meal date is more than 60 days ago is refused with a message saying meal records older than 60 days cannot be corrected. The Meal Records table also disables both buttons past the window and shows a clock icon with the tooltip "Past 60-day correction window."

A correction clears the record's check result and marks it not validated again, so a corrected record is un-validated, and nothing can re-validate it.

Deleting removes the row itself, not just marks it hidden. The audit trail survives; the row does not. The gentler removal that keeps the row and records a stated reason is built and has no screen.

What a meal record holds

The site, the date, the meal type, the counts, the menu items, whether it has been validated, the total served, the staff member who took it, and when it was created.

Whether it has been validated is always no, and no check result is ever stored against it, see the module landing page.

Looking up a site's meal records returns every meal record ever recorded for that site, with no date limit and no way to see one page at a time. A site running five meal periods a day for three years returns roughly 5,400 rows on every visit to CACFP Meal Service and Meal Records.

The same response carries allergy alerts, which cover the whole organisation and are not limited to the site you asked about, every child's allergies, on a screen meant for one site.

Claim

Starting a claim

PTRS needs	Required	What PTRS accepts
The site	Yes	A real site. Not checked against your organisation
The claim month	Yes	Used directly to build a date; a value outside 1 to 12 fails
The claim year	Yes	Same
The programme	Yes	Must parse to ARAS or SFSP, case-insensitively, or PTRS refuses naming the value

Your organisation is taken from your session. PTRS checks for a duplicate among Drafts only, for the same site, month, year and programme, and refuses if found.

The submission deadline is worked out, not something you supply: the last day of the claim month, plus 60 days.

The interface always sends an invalid programme

The Create New Claim button always sends "CACFP" as the programme, which is not a programme PTRS recognises, so no claim can be created from the interface. It also always uses the current month and year, so a claim for a past month cannot be started even if the programme were fixed.

Submitting a claim

PTRS needs	Required	What PTRS accepts
The claim	Yes	Must exist
The certifying official's name	Yes	Up to 200 characters
Their title	Yes	Up to 200 characters
Acknowledging the certification statement	Yes	Must be ticked, or PTRS refuses saying the certification statement must be acknowledged

PTRS then requires the claim to be a Draft, checks the acknowledgement again, checks the 60-day deadline, and runs every validation rule. The full sequence is on How a claim moves through its lifecycle.

Approving and rejecting

Action	PTRS needs	Required	What PTRS accepts
Approve	Approval notes	No	Up to 2,000 characters when supplied
Reject	A rejection reason	Yes	Up to 2,000 characters

Both require the claim to be Submitted or Under Review. Approving additionally fails when the approving person is the same person who submitted it, with a message about separation of duties.

What a claim holds

The parts a reader will look at:

Field	Meaning	State today
Status	One of seven possible statuses	Only Draft, Submitted, Approved and Rejected are ever reached
Total reimbursement	The claim's money	Always $0, there are no line items, and nothing ever recalculates it
Total meals claimed	Meals on the claim	Always 0, same reason
Total meals disallowed	Meals removed by review	Always 0, nothing ever writes it
Submission deadline	Worked out when the claim starts	Real
Late-submission exception approved	Would let a past-deadline claim submit	Always no, nothing ever writes it
Certifying official, title, and when certified	The certification	Real, written on submission
When submitted, when approved, rejection reason	The transition record	Real
Amendment link and revision number	The amendment chain	Real in the design; the amend action has no screen
Line items	The claim's detail	Always empty

The claims list shows the same shape, minus the certification, transition and line-item detail.

Claim line item

Each line item would carry a meal type, an eligibility tier, a meal count, the rate applied, a line total, a cash-in-lieu total and the number of operating days.

Nothing in PTRS ever creates a claim line item. There is no action, screen or built-in starting data that produces one. Every field above is documented here because the claim's line item table shows them and because a fix would need to fill them in, not because any of them has ever held a value.

Note that the line total is a stored figure, not a worked-out one: nothing in PTRS multiplies the meal count by the rate applied. See The reimbursement arithmetic.

Claim adjustment

Built completely, and reachable from no screen.

PTRS needs	Required	What PTRS accepts
The adjustment type	Yes	Upward or Downward
The reason	Yes	Data entry error, audit finding, edit check correction, state agency directed, or self-identified error
The amount	Yes	Any figure. No check on whether it is positive or negative
The meal type	No	When given: Breakfast, Lunch, Supper or Snack, a different, shorter list than the five used on a meal record
Meals affected	Yes	Any whole number. No range check
Notes	No	Free text

PTRS's own description of a downward adjustment says it should be a negative amount, and nothing enforces that, a downward adjustment with a positive amount is accepted.

Every adjustment starts out Pending, and stays there: nothing ever marks one applied or moves it anywhere else.

Daily limit configuration

Reachable from no screen.

PTRS needs	Required	What PTRS accepts
The site	Yes	Must be a real site
Max meals per day	Yes	Greater than 0. No upper bound
Max snacks per day	Yes	Greater than 0. No upper bound
Max total meal events per day	Yes	Greater than 0. No upper bound, and not checked against the two above
A justification for an override	No	Free text. Not required even when the values are an override

Any set of values other than 2 / 2 / 3 marks the site as using an override and sets its state-approval status to Pending. Nothing ever moves it to Approved.

Looking up a site's limits returns the 2 / 2 / 3 defaults when nothing has been configured. See the Delaware daily limit.

Fields nothing ever writes

Collected in one place, because each is something a reviewer or a report would reasonably expect to be filled in:

Record	Field	Consequence
Meal record	Whether it is validated	Never yes. No meal can be reimbursed by the one calculation that runs
Meal record	The stored check result	The validation block on a meal record's detail page never appears
Claim	Total reimbursement, total meals claimed	Always 0, nothing ever recalculates them
Claim	Total meals disallowed, the disallowance summary	No disallowance can be recorded
Claim	Late-submission exception approved and its reason	A past-deadline claim can never be submitted
Claim	The retention expiry date	No retention date is stamped on a claim
Claim	When and by whom it was reviewed	The Under Review status is never reached
Claim line item	(the whole record)	Every claim is worth $0.00
Claim adjustment	When applied, any status past Pending	An adjustment can never be applied
The claim check rules	Who is allowed to override, and the check's own settings	Written when PTRS is first set up, read by no code. The one check's 15% threshold is written into the code, not read from its own settings
The per-child daily meal log	(the whole record)	The Delaware daily limit is never measured
Daily limit configuration	Whether an override was state-approved	An override stays Pending forever

Each is recorded, with the technical detail behind it, for the PTRS team.