Enrolment and eligibility 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.

This page covers the seven records in the eligibility and records half of the CACFP module. The meal record, the claim and the daily-limit configuration are on Meal and claim fields.

Four of these seven records have almost no rules at all

The older compliance record, the offline queue entry, the income guideline and the sample-drawing action check almost nothing about what they are sent. Where that is so, it is stated in the table, because it means the only real limit is how much text a column can hold.

CACFP enrollment

PTRS needs	Required	What PTRS accepts
The child	Yes	Must exist in your organisation, or PTRS refuses naming the id
The site	Yes	Not checked against your organisation
The programme	Yes	ARAS or SFSP, case-insensitively
The program year	Yes	The shape YYYY-YYYY. Up to 9 characters
The eligibility tier	Yes	Free, Reduced or Paid, case-insensitively. Typed by the person filling in the form, never worked out by PTRS
The determination method	Yes	Income Application, Categorical Eligibility, Area Eligible or Default. Not checked against the tier

Set by PTRS, not by you:

Field	Value
Organisation	From your account. Without one, PTRS refuses saying an organisation is required
Enrolment date	Always today
Status	Always Active

Duplicate rule. One active enrolment per child, site, programme and program year. PTRS checks this itself before saving, so you see a clear message naming the child, site, programme and year, rather than a raw database problem.

Fields with no writer

Four fields exist on every enrolment, are returned whenever you look one up, and are never written by any path in PTRS:

Field	Meant to hold	Consequence
Linked income application	The approved application that determined the tier	The enrolment is never linked to an income application. The action built to set it has never been called
Age group at enrolment	The federal age band at enrolment	The Age Group block on the detail page never appears
Carried over from a prior enrolment	Eligibility carried over from a prior year	Carryover is not built
Carryover expiry date	When carried-over eligibility lapses	The Carryover Expiration block never appears

Updating and withdrawing

Both actions work and neither has a screen anywhere in PTRS.

Updating an enrolment:

PTRS needs	Required	What PTRS accepts
A new eligibility tier	No	When given, must be Free, Reduced or Paid, or PTRS refuses listing the three
A new status	No	When given, must be one of the five real statuses, or PTRS refuses listing them

Each is applied only when it is both present and recognised. This action does not touch the income-application link either.

Withdrawing a participant:

PTRS needs	Required	What PTRS accepts
A reason	Yes	Up to 500 characters. Stored only in the audit trail, not on the enrolment itself, there is no reason field on the record
The effective date	Yes	A real date. No check that it falls after the enrolment date

The values you will see

Kind	Values	Reachable
Eligibility tier	Free, Reduced, Paid	All three, from the form
Determination method	Income Application, Categorical Eligibility, Area Eligible, Default	All four, from the form
Enrolment status	Active, Inactive, Waitlisted, Withdrawn, Completed	Only Active. The other four have no reachable writer
Programme	ARAS, SFSP	Both

Household income application

No screen reaches this, direct system access only.

PTRS needs	Required	What PTRS accepts
The primary contact	Yes	Must exist in your organisation
The site	Yes	Not checked against your organisation
Household size	Yes	1 or more. No upper bound
Reported income	Yes	0 or more
Income frequency	Yes	Annual, Monthly, Twice Monthly, Bi-Weekly or Weekly
Signing adult's name	Yes	Up to 200 characters
Last 4 digits of the signing adult's Social Security number	Required unless the no-SSN box is checked	See the warning below
No-SSN indicator	No	Waives the SSN requirement
Signature date	Yes	A real date. No check against today, a future date is accepted
Signature type	Yes	Exactly "Wet" or "Electronic," matched exactly as typed. "wet" in lower case is refused
Privacy Act acknowledged	No	Stored and read by nothing. Leaving it unchecked is accepted
Non-discrimination acknowledged	No	Stored and read by nothing. Leaving it unchecked is accepted
Program year	Yes	The shape YYYY-YYYY. Matched against the income guideline table

The SSN digits are stored in plain text

The field's own name says it is encrypted, and it is not. PTRS stores exactly what is typed, with no encryption applied anywhere in PTRS. The field name promises a protection the code does not apply.

The field that would hold proof of an electronic signature has no writer anywhere, so an electronically signed application stores no signature at all.

Worked out when it is created

Field	How
Annualised income	The reported amount multiplied by 1, 12, 24, 26 or 52 depending on frequency
Eligibility tier	Compared against the income guideline table, or the fallback figures built into PTRS when that table is empty, the arithmetic in full
Status	Pending
Date received	Today

Approving and denying

Both refuse anything that is not currently Pending, saying it has already been processed, and neither has a screen.

Approving:

PTRS needs	Required	Effect
Determination date	Yes	Stored as given. No check against today
Effective date	Yes	Stored, and the expiry date is set to twelve months after it

Approving also records which staff member certified it, using your signed-in account's own identity rather than a chosen staff record.

Denying:

PTRS needs	Required
A denial reason	Yes. Up to 2,000 characters accepted by the check, and the field itself can only hold 1,000

The denial-reason limits disagree

A reason between 1,001 and 2,000 characters passes the check that runs first and then fails when PTRS tries to store it, as a raw database problem rather than a friendly message.

Statuses

Status	Written by
Pending	Creating it
Approved	Approving it
Denied	Denying it
Expired	Nothing. No code assigns it, and nothing reads the expiry date

Income guideline

No screen anywhere, and no way to check what you send.

PTRS needs	What PTRS accepts
Fiscal year	Not checked at all, no shape requirement, unlike every other fiscal-year field in the module
Household size, for each row	Not checked. Zero and negative numbers are accepted
The base income figure, for each row	Not checked. Zero and negative numbers are accepted
The increment for each additional household member	Not checked
Source	Up to 200 characters

Worked out, not stored: the free threshold is the base figure times 1.30; the reduced threshold is the base figure times 1.85.

How replacing the table works. Existing rows for the fiscal year are matched by household size and updated; anything new is added. Every row you touch is marked active. Rows you leave out of your request are left untouched, so a partial upload leaves stale rows active alongside the new ones. There is no way to remove a row or mark one inactive.

Two structural notes

The table has never been filled in. The only way to write to it has no screen. Every eligibility tier PTRS has ever computed came from the fallback figures built into the code, see the thresholds.

This table sits outside PTRS's usual organisation boundary. Every query that touches it happens to filter by organisation on its own, so there is no cross-organisation reading today, but the safety net every other table has is absent here. The same is true of income verification records.

Income verification

Three ways of acting on it, none with a screen.

Requesting a verification:

PTRS needs	Required
The income application	Yes. Must exist and be Approved, or PTRS refuses saying so
The fiscal year	Yes. The shape YYYY-YYYY

Sets the verification to Pending, dated today, copies that application's current tier as the starting point, and flips it to say it was selected for verification. There is no duplicate check, the same application can be given any number of verifications.

Drawing the sample takes a fiscal year and needs nothing checked about it, read in full.

Completing a verification:

PTRS needs	Required	What PTRS accepts
The outcome	Yes	Confirmed, Tier Changed, No Longer Eligible, or a fourth spelling that does not match the value PTRS actually stores, see below
The verified tier	Required only when the outcome is Tier Changed or No Longer Eligible	Free, Reduced or Paid
Verifier notes	No	Up to 2,000 characters

The check and PTRS's own stored value disagree on the fourth outcome

PTRS's own list of outcomes includes a fourth value for a household that never responds. The check that runs first accepts a different spelling of that idea, one PTRS does not actually store, so:

• Sending the spelling the check accepts passes the check and then fails, naming the value as invalid.
• Sending the spelling PTRS actually stores is rejected by the check itself.

The no-response outcome cannot be recorded by any input.

Fields with no writer

Field	Consequence
First notice date, second notice date	The two-notice follow-up these fields model is recorded nowhere
The "in progress" status	Read by the outstanding-list filter, written by nothing, that half of the filter can never match
The "no response" status	Written by nothing and read by nothing
Verification-exempt flag on an application	Read by the sample filter, written by nothing, no application can be marked exempt

Area eligibility record

No screen reaches this, direct system access only.

PTRS needs	Required	What PTRS accepts
The site	Yes	Not checked against your organisation
Feeder school name	Yes	Up to 300 characters by the check that runs first, and the column itself can only hold 200
Feeder school's federal id	No	Up to 50 characters. No check at all
School district	Yes	Up to 300 characters by the check that runs first, column limit 200
School year	Yes	The shape YYYY-YYYY. Up to 9 characters
Total enrolled students	Yes	Greater than 0
Free/reduced count	Yes	0 or more, and no more than total enrolled
Data source	Yes	School District, CEP Data, Direct Certification, or Census
Certification date	Yes	A real date
Expiry date	Yes	A real date. No check that it falls after the certification date
Whether this is a Community Eligibility school	No
Community Eligibility identified-student percentage	Required only when the school is a Community Eligibility school	0 to 100

Two mismatches between the check and the storage limit on this record

Feeder school name and school district both allow up to 300 characters at the check that runs first, and the field itself can only hold 200. A value between 201 and 300 characters passes the check and then fails as a raw database problem.

The threshold gate

After working out the free/reduced percentage, PTRS refuses to save anything below 50%, or, for a Community Eligibility school, an identified student percentage that, multiplied by 1.6, still falls short of 50, with a message naming the percentage and the threshold.

Consequence: a site that does not qualify cannot be recorded as assessed at all.

Duplicate rule. One record per site and school year. PTRS has no built-in check for this, so a second record for the same school year fails as a raw database problem rather than a clear message.

Updating

No screen.

Every field is optional on an update; each is applied only when given. The percentage is worked out again afterwards, and the threshold is not re-checked, so an update can take a record below the threshold and store it anyway.

Marking a site DDOE-approved is a plain switch on the update request, and setting it stamps today as the approval date. Nothing else guards it, any account that can reach the CACFP part of PTRS can mark a site state-approved.

CACFP compliance record

A simple item, status and date record kept from an earlier version of PTRS's compliance tracking. No screen anywhere touches this record, for any of its eight actions.

PTRS needs	Required	What PTRS accepts
The site	No	Not checked against your organisation
The item	Yes	Up to 200 characters. No check on length, an over-long value is a raw database problem, not a message
The status	Yes	Current, Incomplete or Overdue
Last submitted date	Yes	A real date, or PTRS refuses saying the date could not be read
Notes	No	Up to 2,000 characters. No check at all

Deleting one hides it rather than erasing it, a genuine soft removal, unlike deleting a meal record.

Changing many records' status at once reports how many it changed and how many it could not find, and sending the same record twice in one request inflates the "not found" count rather than the "changed" count. There is no rule about which status can follow which.

Summarising a site's records returns a count per status and the oldest still- overdue record's last-submitted date.

Where this record is read from. The CACFP Compliance card on the Compliance Radar reads it, that is the one place in PTRS that shows one. See Compliance.

Offline queue entry

Uploading a batch checks almost nothing, and checks each entry on its own rather than the whole batch together.

PTRS needs, per entry	Required	What PTRS accepts
The site	No	Not checked against your organisation
The meal data	Yes	Rejected with a message if blank. No maximum length
When it was queued	No	Any date, past or future
The device id	Yes	Rejected with a message if blank. Up to 200 characters, and length is not checked, an over-long value is a raw database problem

A rejected entry does not fail the whole batch: PTRS reports how many were submitted, how many accepted, how many rejected, and a message for each rejection, naming its position in the batch you sent. The page reading that response looks for the message under a different name than PTRS sends it, so the text would not actually appear.

PTRS sets the organisation and marks every accepted entry Queued.

Fields with no writer

Field	Consequence
When it synced	Only the conflict-resolution action writes it, and that action can never succeed (below)
Error message	No writer. The queue list's red error line never appears
The resulting meal record	No writer. Nothing turns a queue entry into a meal record
The "failed" and "conflict" statuses	No writer. Both are read by the status check and can never match

Resolving a sync conflict takes a resolution and the meal data:

• The resolution must be one of PTRS's own sync statuses, Queued, Synced, Failed or Conflict, not a resolution strategy like "keep mine" or "keep theirs."
• The meal data you send is accepted and thrown away. Nothing reads it.
• The entry must already be Failed or Conflict, or PTRS refuses naming the status as invalid. Since neither status can ever be written, this action can never succeed.
• When the entry cannot be found, PTRS reports a conflict rather than a not-found message.

DENARS package

PTRS needs	Required	What PTRS accepts
The site	Yes	Not checked against your organisation
Program year	Yes	No shape requirement, unlike every other program-year field in the module. Up to 20 characters
Package type	Yes	DENARS, Annual, Monthly or On Demand
Included sections	No	Up to 2,000 characters. Free text, no structure checked
Who generated it	No	Taken from what you send, not from your signed-in account. Nothing checks it
Notes	No	Up to 1,000 characters. No check at all

PTRS sets the organisation, the time generated, and marks the package Generated, leaving its document blank.

The status is plain text, not a fixed set of values, "Generated" is the only value any code ever writes.

Both places that ask for a package fail, and the row it would write is empty

Recordkeeping & Document Retention and Review Readiness both ask for "every site" where PTRS needs one, so the request fails before PTRS reads it. Full detail on Read the records and offline screens.

And nothing assembles a document: the field meant to hold it has no writer, and downloading a package returns it exactly as it is, blank.

What the organisation boundary does and does not cover

PTRS applies an organisation boundary to almost every table automatically, so a query naturally only sees your organisation's rows. Two things on this page sit outside that automatic boundary:

• The income guideline and income verification tables do not carry the usual audit columns that switch the boundary on. Every action that touches them happens to filter by organisation on its own, so there is no cross-organisation reading today, but the automatic safety net every other table has is absent here.
• One record's own boundary declaration is quietly replaced by the global one during setup, which changes nothing in practice, it is a leftover line, not a defect.

Related

• Meal and claim fields, the meal record, the claim, the adjustment and the daily-limit configuration
• Who can do what with enrolment and records, all 41 things PTRS can do here, and which have a screen
• How a participant becomes eligible, the tiers and the arithmetic behind them
• Enrol a participant
• CACFP troubleshooting