How a claim moves through its lifecycle

A CACFP claim is the document that asks the state for money. Everything about its handling, who signs it, who approves it, what has to be true before it leaves, exists because the answer will be checked years later.

PTRS is designed to handle the lifecycle properly. This page describes that design, including the parts no user can reach, because the design is what a fix would restore.

No claim exists to move

Starting a claim from nothing is the only way to create one, and the one screen that does it always sends a programme name PTRS does not recognise. See the module landing page.

Read this page as the design PTRS implements, not as a description of something happening in your own copy of PTRS.

The seven states

PTRS defines seven statuses: Draft · Submitted · Under Review · Approved · Rejected · Paid · Amended.

Four of the seven can be set by PTRS itself, and two are reachable by a user.

State	Set by	Reachable?
Draft	Starting a claim, or amending an approved one	By design, but the one screen that starts a claim always fails
Submitted	Submitting a claim	Yes, if a Draft existed
Under Review	A dedicated action	No. Nothing anywhere calls it
Approved	Approving a claim	Yes, if a Submitted claim existed
Rejected	Rejecting a claim	Yes, if a Submitted claim existed
Paid	A dedicated action	No. Nothing anywhere calls it
Amended	Nothing	No. No code anywhere assigns it

Two consequences worth naming. Under Review appears in the status filter on Claims Management and in both the approve and reject rules, and nothing can put a claim into it. And Amended, the status a superseded claim would carry, is never set: amending a claim creates a new Draft pointing back to the original, and leaves the original in whatever status it already had.

Draft

Starting a claim needs a site, a claim month, a claim year and a programme. Your organisation comes from your session, never from what you send, without one, PTRS refuses saying an organisation is required.

What PTRS checks, in order:

1. The programme parses to ARAS or SFSP. This is where every real attempt fails today, the Create New Claim button sends "CACFP" and PTRS refuses, naming it as invalid.
2. No Draft already exists for the same site, month, year and programme. A duplicate is refused. Note this only blocks a second Draft, a second submitted claim for the same period is caught separately, by one of the twenty checks.

What PTRS works out. The submission deadline: the last day of the claim month, plus 60 days.

What PTRS writes. The claim itself, marked Draft, plus a line in its status history and in the audit trail.

What PTRS does not write. No line items, no totals. A new Draft's reimbursement total and meals claimed are both zero, and nothing in PTRS ever changes them.

Validation

Two ways in: checking a claim on demand, and checking it automatically at the moment of submission. The on-demand check has no screen, so in practice checking only happens at submission.

What running the checks does:

1. Load the claim with its line items. If it does not exist, stop.
2. Load every active check rule for the claim's organisation.
3. Number this run one higher than the last run for this claim, so each run is a separate, numbered attempt and earlier results are kept.
4. Run every rule, record a result for each, and save them all.
5. Count the failures that are marked blocking and not overridden.
6. Report whether the claim can be submitted, yes only if there are no blocking failures.

The rules table has one writer, and it only runs when PTRS is set up for development

The only thing that ever puts a rule into this table is a routine that runs automatically the moment PTRS starts up in its development setting, for one specific, fixed organisation. There is no screen that creates a check rule.

Outside that development setting the rule list is empty, so step 4 above runs zero times, and the report always says zero checks, zero blocking failures, and that the claim can be submitted.

Inside that development setting, for that one organisation, twenty rules load , and one of them, the "Zero Operating Days" check, fails on every claim, because it counts validated operating days and no meal record is ever marked valid. That check is blocking.

In a development copy of PTRS no claim can be submitted; in an installed copy no claim can be blocked.

What each rule actually tests

Twenty rules are built in. Only nine different kinds of check actually exist behind them, so eleven of the twenty rules are pointed at a check meant for a different rule, meaning their name, description and regulation citation describe a test PTRS does not run for them.

Rule	Name	Blocking	What it actually checks
CLM-001	Meals vs Enrollment Count	Yes	Real. Fails if total meals in the month exceed active enrolments times distinct meal days
CLM-002	Meals vs Attendance Count	Yes	Not built. Always passes, waiting on a connection to the Attendance module that does not exist yet
CLM-003	3-Month Rolling Average Variance	No	Real, with a defect, see below
CLM-004	DE Daily Participant Meal Limit	Yes	Counts entries in the per-child daily meal log. That log has no writer, so always 0
CLM-005	Zero Operating Days	Yes	Real. Counts distinct dates with a validated meal record. Always 0, so always fails
CLM-006	Missing Approved Meal Types	No	Not built. Always passes, waiting on a site-configuration record that does not exist yet
CLM-007	Duplicate Claim Detection	Yes	Real. Fails if another claim exists for the same site, month, year and programme, other than a Draft or a Rejected one
CLM-008	Reimbursement Rate Integrity	Yes	Real, and passes automatically when the claim has no line items, which is every claim
CLM-009	Enrollment Eligibility Verification	Yes	Real. Fails if the site has zero active enrolments dated on or before the period ends
CLM-010	60-Day Submission Deadline	Yes	Runs CLM-001's check instead. The real deadline check lives in the submit action, not here
CLM-011	Claim Certification Statement	Yes	Runs CLM-009's check instead. The real certification check lives in the submit action
CLM-012	Meal Pattern Compliance Check	No	Runs CLM-001's check
CLM-013	Production Record Documentation	No	Runs CLM-001's check
CLM-014	Temperature Log Documentation	No	Runs CLM-001's check
CLM-015	Attendance-Meal Time Reconciliation	No	Same stub as CLM-002, always passes
CLM-016	Cross-Site Daily Limit Enforcement	Yes	Counts an empty log, always 0
CLM-017	Weekend/Holiday Service Verification	No	Same stub as CLM-002, always passes
CLM-018	Vended Meal Delivery Documentation	No	Runs CLM-001's check
CLM-019	Non-Program Food Exclusion	Yes	Runs CLM-001's check
CLM-020	Fiscal Year Rate Transition	Yes	Runs CLM-008's check, which passes automatically with no line items

So of twenty rules: four run a real, distinct test (CLM-001, CLM-005, CLM-007, CLM-009); four are stand-ins that always pass; two count an empty log; two pass automatically before checking anything; and eight duplicate CLM-001's test under another name.

The practical shape of that: a claim can fail a rule called Temperature Log Documentation, with a message about meals possibly exceeding enrolment capacity, and pass a rule called Production Record Documentation with no production record existing anywhere.

Two defects inside the rules that do run

CLM-003's comparison has a logic ordering mistake. Its filter is written so that it means "this organisation, this site, and Approved" or "Paid, not this claim, not deleted", not the single combined condition the rule was meant to express. Two things follow: the first half never excludes the claim being checked, so an Approved claim can compare against itself; and the second half carries no site restriction, so Paid claims from every other site in the organisation enter the three-month rolling average. Your organisation's own boundary keeps it inside one organisation; it does not keep it inside one site.

The variance threshold itself is fixed at 15% in the code, and reported as being within that. The rule's own stored settings record a different configurable value, and nothing ever reads it. The number matches today by coincidence; changing the stored setting would change nothing.

CLM-001 compares a whole month's total against a per-day ceiling. It fails when the month's total meals exceed enrolled participants times the number of days with a meal record. That is a sensible ceiling for the month as a whole, but it is one number for the whole month, so a site that served three times its enrolment at one lunch and nothing for the rest of the month passes. The rule's own description says "on any single day"; what actually runs checks the whole month.

Overriding a failed rule

An action exists to mark a failed result overridden with a stated reason, which removes it from the blocking count on the next run.

The rules record which role would be allowed to override each one, a sponsor-level role for the federal ones, site director for the warnings, and nobody at all for three of them. The sponsor-level role named is not a role PTRS actually has, and nothing in PTRS reads that setting anyway.

This action has no screen. The Override link on a failed row in the Claim Validation panel does nothing when pressed, it is a control that looks functional and is not wired to anything.

Submitted

Submitting is done through the Claim Certification form, which only appears while the claim is a Draft.

The form collects three things: Certifying Official Name, Title, and a checkbox carrying the certification statement itself:

"I certify that all information on this claim is true and correct. I understand that deliberate misrepresentation may subject me to prosecution under applicable federal and state laws. I certify that records are available to support this claim."

The Submit button is disabled until all three are supplied.

What PTRS checks, in order:

1. Name and title are not blank and no more than 200 characters, and the certification checkbox is ticked, or PTRS refuses saying the statement must be acknowledged.
2. The claim is a Draft, or PTRS refuses naming its actual status.
3. The acknowledgement is checked again.
4. The deadline. If today is past the submission deadline and no late exception has been approved, PTRS refuses saying the deadline has passed and a late exception is required. Nothing in PTRS can ever approve that exception, so once the 60 days pass, the claim is permanently unsubmittable.
5. Validation. Every check rule runs. If any blocking one fails, PTRS refuses naming how many.

What PTRS writes. The certifying official's name, title and the time certified; the claim's status moves to Submitted, with who submitted it and when; a line in the status history and the audit trail naming the certifying official.

The screen shows "Claim submitted successfully" only when it genuinely happened, so unlike some messages elsewhere in PTRS, this one reports something real.

Approved or Rejected

Both require the claim to be Submitted or Under Review, and nothing can ever produce Under Review, so in practice both act on Submitted claims.

Approving enforces the one real separation-of-duties control in the module: the person approving cannot be the person who submitted it. PTRS refuses with a message naming that rule, rather than a raw failure.

Rejecting requires a reason, up to 2,000 characters, which is stored on the claim, written into the status history and included in the audit trail.

Both write a line to the status history; approving also stores any approval notes, up to 2,000 characters, as the reason for that transition.

Who can actually approve

The Approve and Reject buttons on a claim's detail page are shown only to a site director and above.

The action behind the buttons is open to Staff as well. A staff member does not see the buttons and is nonetheless allowed to perform the same action. See the module landing page.

The identity compared for separation of duties is your signed-in account, not a chosen staff record, the same value ends up stored in the fields that name who submitted, approved and last moved the claim, so those fields do not actually hold staff record ids despite what their names suggest.

Paid

Marking a claim paid changes its status and nothing else, and nothing anywhere in PTRS ever calls it. There is no screen, no scheduled task and no import that records a payment. Paid appears in the status filter, in the amendment rule and in CLM-003's rolling average, and nothing can put a claim there.

Amended

Amending requires the original claim to be Approved or Paid, or PTRS refuses naming its actual status.

Creating an amendment copies the organisation, site, month, year, programme and submission deadline from the original, marks the new one Draft, links it back to the original, and numbers it as the next revision. It copies no line items and no totals, and the original is left in whatever status it already had, nothing ever sets Amended.

This action has no screen. There is no Amend control anywhere in the interface, so the federal remedy for a claim that has already been settled is unreachable.

Adjustments

Recording a claim adjustment takes a type, a reason, an amount, an optional meal type, an affected meal count and notes. The Claim Detail page shows the adjustment table and has no control that creates one.

The audit trail

Every transition writes two things: a line in the claim's own status history, and a line in PTRS's tamper-evident audit log. The status history carries the previous status, the new one, when it happened, who did it and an optional reason, and is what the Claim Status Timeline panel shows.

That part is genuinely sound. The audit log is a cryptographic chain, and the claim actions use it consistently at every step, starting a claim, submitting it, approving it, rejecting it, creating an amendment.

One inconsistency worth knowing if you are reading messages from PTRS directly: PTRS defines a full, clear set of messages for this lifecycle, and none of the five claim actions actually uses them. They build their own messages instead, with their own codes, and mostly without stating a clear technical status alongside the message. Do not rely on the defined message set; rely on the messages listed on Who can do what with meals and claims.

What a fix would need to restore, in order

Stated plainly because the order matters and the items are independent:

1. Send a valid programme from Claims Management, ARAS or SFSP. One word. Without it nothing else on this page is reachable.
2. Mark a meal record valid somewhere. Until then the Zero Operating Days check blocks every claim in a development copy of PTRS, and the reimbursement estimate is zero everywhere.
3. Write claim line items and add up a claim's own total. Until then every claim is worth $0.00 and two of the twenty checks pass without checking anything.
4. Get the check rules into an installed copy of PTRS. They exist only for one organisation in a development setting.
5. Call the Delaware daily limit calculation from the meal-count screens, or two of the checks keep counting an empty log.

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