Work the menu and food screens

Denise wants to plan next month's cycle menu before the delivery order goes in, and Tom wants to know why the food catalogue is always empty. This page is how to read the four screens under Menu Planning, and which of them can save anything.

Who can do this

• Front-line staff
• Site director
• Regional director
• Organisation admin
• Super admin

None of the four pages checks a role to show itself. The New Cycle Menu and New Template buttons are shown to everyone PTRS admits, so the gate excludes nobody.

Neither Create button on these screens can save

New Cycle Menu and New Template both fail before PTRS even looks at the rest of what they sent, because each page leaves out a field PTRS requires. Neither failure is a connection problem and neither is fixed by retrying.

Everything else on the four screens is read-only, and two of the four reads are empty in every copy of PTRS for reasons that have nothing to do with your data.

The four screens at a glance

Screen	What you can do
Food Item Catalog	Search and filter, nothing else. There is no add, edit or deactivate control
Meal Pattern Rules	Read. The rule-set grid is always empty; the age-group table below it works
Cycle Menu Planning	List cycle menus, and attempt to create one
Menu Template Library	List menu templates, and attempt to create one

All four are in the sidebar under CACFP → Menu Planning.

Food Item Catalog

Lists the organisation's food items, one row per item: name, component, standard serving, flags and source. It has a search box and a component filter offering Grain, Meat/Meat Alternate, Vegetable, Fruit and Milk. The list itself is correctly scoped to your organisation and correctly paged.

There is no way to add a food item

Adding, updating and deactivating a food item are all built completely, and none of the three has a screen anywhere in PTRS.

Nothing gives PTRS a starting set of food items either.

So Food Item Catalog reads "No food items found." in every copy of PTRS, and there is no control anywhere that would change that.

This matters beyond this screen. The meal pattern check matches typed menu items against this catalogue, so with it empty every meal it is asked about fails. See What makes a meal reimbursable.

Two details to know if the table is ever filled in:

• The Source column reads "USDA" for a food item PTRS itself provided and "Custom" for one someone added, and the way a food item is created always marks it "Custom", so the "USDA" label could never actually appear even with items in the table.
• The Next button turns itself off once a page comes back with fewer than 25 rows, rather than checking the true total PTRS sends back, so on a catalogue that happens to be an exact multiple of 25, the last click lands on an empty page.

Meal Pattern Rules

Subtitled "USDA CACFP meal pattern requirements and serving size rules per 7 CFR 226.20." It has two sections.

The rule-set grid is always empty

The grid reads "No meal pattern rule sets configured." in every copy of PTRS, including a development copy where five rule sets and seventy rules exist.

There are two independent reasons, and fixing either alone changes nothing:

1. The page expects the wrong shape of answer. It checks for a plain list and PTRS sends back a page of results wrapped with a count, so the check the page runs always comes back empty-handed, whatever PTRS actually holds.
2. The rules themselves are left out of the answer. Even if the page read the shape correctly, the way PTRS looks up a rule set does not bring its individual rules along, so every card would print "Components (0 rules)."

Looking up one rule set by itself does bring its rules along, and no screen does that lookup.

The age-group table works

Below the grid, Age Group Mappings shows correctly. In a development copy of PTRS it shows the six rows built in there.

In staging, production or an installed copy it shows nothing, because the section only appears once there is something to show, and nothing gives PTRS that starting data there. See What makes a meal reimbursable for the six mappings and why nothing actually uses them.

The rules exist only in a development copy of PTRS, for one organisation

The routine that gives PTRS its rule sets, rules, serving requirements and age-group mappings only ever runs when PTRS starts up in its development setting, and every row it writes is tied to one fixed organisation.

Staging runs the database update and not that routine. Production and an installed copy run neither. There is no screen, and no other way, to create a rule set, a rule, a serving requirement or an age-group mapping.

Cycle Menu Planning

Lists cycle menus as cards: name, cycle length, start date, programme, season and a status pill. The list itself is correct and correctly paged.

New Cycle Menu cannot succeed

The form collects four things, Menu Name, Start Date, Cycle Length (weeks) and Season, and sends more than that behind the scenes. Three separate problems sit between what it sends and a saved record.

First, and this is the one you will hit: PTRS requires knowing who created the menu, and the page never asks for or sends that, so the request fails before PTRS looks at anything else. The toast reads "Failed to create cycle menu."

Behind that, two of the values the page sends are not ones PTRS recognises:

Field	What the page sends	What PTRS recognises
Programme	"CACFP"	ARAS, SFSP
Site scope	"All"	All Sites, Specific Sites

The first is the same mistake as Create New Claim on Claims Management, which sends "CACFP" to the same list of programmes, see the module overview.

A cycle menu can hold no menu items

Creating a cycle menu makes an empty day for every day of the cycle. The meals that would go into them have no path anywhere in PTRS that creates one.

So a cycle menu is a name, a date range and a grid of empty days. The screen pieces built to edit those days exist and are used by no page.

Two more things about a cycle menu, if one is ever created:

• Its status can be changed to anything from anything, with no rule about which change makes sense, and no screen offers this.
• The approver recorded is not a staff member's own record. Approving one records your signed-in account's own identity in a field named for a staff member. The same pattern is recorded on meal records.

Menu Template Library

Despite its name, this is a list of template cards, not an editor. The screen piece that would edit a template exists and is used by no page.

Each card shows the template name, meal type, prep complexity, a status chip and one of two lines of text: a green tick reading "Meets meal pattern requirements," or a red cross reading "Missing required components."

The tick is not a verdict

Whether a template shows the tick or the cross is a value supplied by whoever created it, stored exactly as given. No meal pattern check ever runs on a template, not on create, not on cloning, not on reading it back.

So the tick means "somebody typed Compliant," and the sentence next to it is asserting something PTRS never checked.

New Template cannot succeed

The form collects Template Name, Meal Type and Prep Complexity. Two problems:

The required field it never sends. PTRS requires a pre-check status the form does not collect and does not send at all.

The values the dropdown offers. Prep Complexity offers Low, Medium and High. PTRS's own four values are named differently, and none of the three matches, so even with the missing field supplied, PTRS would still refuse, naming the value as invalid.

This is the third time this pattern has appeared in the CACFP module: a meal type accepted by one check and rejected by PTRS's own list; a verification outcome spelled two different ways; and now this.

A template cannot be cloned, and templates hold no items

Cloning a template is built and reachable from no screen; there is no clone control on the card.

The field that would hold a template's food items is fixed to an empty list by the form, never shown or edited. Nothing reads it back except the raw record.

Looking up one template by itself also has no screen: the cards do not link anywhere.

The food review queue

PTRS's design includes a queue that would hold an unrecognised menu item typed at the serving line, waiting for someone to match it to the catalogue.

Neither looking up that queue nor classifying an item in it has a screen, and the queue itself has no writer anywhere. Nothing creates an entry when a menu item fails to match, not the meal-count screens, not the meal pattern check.

So classifying an item is guaranteed to say the item could not be found, and there is no screen that would try in any case.

Where to go next

• What makes a meal reimbursable, the components, the serving-size table and the ten cross-component rules
• Read the CACFP meal service screens, the Meal Composer, the one screen where a meal pattern verdict reaches a person
• Who can do what with menus and inventory, every action on these screens and which have a screen
• CACFP troubleshooting, the exact messages these screens give