Work the inventory and procurement screens

Tom is trying to work out why the pantry never shows what is actually on the shelf, and why last month's purchase orders never appear. This page is how to read Inventory Management, Multi-Site Inventory, Procurement & Vendors and Buy American Compliance, and which of the four Create buttons on them can save.

Who can do this

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

Record Transaction, Vendor and New Order are shown to everyone PTRS admits. Multi-Site Inventory checks nothing.

Every create form on these four screens sends a blank value where PTRS needs a real one

Four forms, one pattern, in four places. The page supplies a site or a staff member the form never collected, as an empty value:

Screen	The blank field
Inventory Management	who transacted it
Procurement & Vendors, Vendor	the site
Procurement & Vendors, New Order	the site
Buy American Compliance	the site and the food item

Each is a field PTRS requires to be a real record. A blank value fails before PTRS even runs its usual checks. The toast says "Failed to …" with no further detail.

This is the same pattern as the three CACFP meal-entry screens and the recordkeeping screen described elsewhere in this guide. It is now the most common defect in the module.

Inventory

Inventory Management, subtitled "Track food inventory, FIFO compliance, and stock levels." It shows a four-tile summary, a low-stock strip, a lot table and a first-in-first-out queue panel.

The four summary tiles never appear

The tile block only shows once a summary arrives, and the page asks for that summary across "every site," which PTRS refuses outright because it needs one real site.

That failure is currently protecting the page. If the request succeeded, the block would fail anyway: the page reads three figures under names that do not match what PTRS actually sends back.

The three panels that do render show a long code, not a name

The inventory table, the low-stock strip and the first-in-first-out panel all show the food item's own id in the column headed Food Item, because PTRS's answer carries no name for it and the list does not look one up. So that column reads a long code on every row, on all three panels.

Two smaller limits worth knowing:

• The list is not asked to show more than one page at a time, so PTRS's default limit of 25 applies. The low-stock strip and the first-in-first-out panel both come from that same 25 rows, so both are summaries of one page rather than of the site.
• The first-in-first-out panel shows only the first 20 of what it has and says nothing when it leaves the rest out. Its own heading count is the full list length.

Record Transaction

The form collects Item, Type, Quantity and Notes, and the four transaction types it offers, Receipt, Issue, Waste, Transfer, are all real. A fifth, Adjustment, is not offered.

It cannot save: the page sends a blank value for who transacted it, and PTRS requires a real staff member there. The item picker also lists lots by their own id and lot number, so you are choosing between long codes.

A lot cannot be created, so there is nothing to transact against

Creating an inventory lot works correctly when called directly, site, food item, lot number, received date, a quantity greater than zero and a unit, and no screen in PTRS calls it.

Updating a lot, looking one up, and reading the transaction ledger are all in the same position: built, and reachable from no screen. So a lot cannot be created, corrected or inspected, and the transaction ledger cannot be read.

Inventory Management therefore reads "No inventory items found." in every copy of PTRS, and the first-in-first-out panel reads "No items in FIFO queue."

What the first-in-first-out engine actually does

This is worth stating because it is one of the better-built pieces in the module, and none of it is reachable.

For an Issue, PTRS runs a real oldest-first deduction: it loads every lot at that site for the same food item with stock remaining, in the order they were entered, and if the total across every lot is less than what was asked for, it refuses, naming both figures. Otherwise it works through the lots oldest-first, taking from each until the amount is satisfied, and records one transaction per lot it touched. For the other four transaction types, it applies the movement to the one named lot, refusing a transfer or a waste that would take the balance below zero.

The order lots are issued in is the order they were entered into PTRS, not their expiry date. A lot entered later but expiring sooner is therefore issued last, and the panel's colour coding will show it expiring at the back of the queue.

Multi-Site Inventory

A four-tile summary over a per-site table. This one works: it lists every site in the organisation and fills in the inventory counts beside each, so a site with no stock shows as a row of zeros rather than being left out.

It reads "No inventory data available." only when the organisation has no sites at all.

Two notes:

• Its total-value figure is actually a sum of quantities, not a monetary value, and it adds together quantities that may be in different units. The page does not show it, and nothing else reads it.
• Low Stock counts lots with a reorder threshold set and a quantity at or below it. Since no lot can ever be created, every figure on this page is zero in practice.

Site transfers have three actions, no screen, and no effect on inventory

Creating a site transfer, listing transfers and updating a transfer's status are all built and reachable from no screen. The screen piece for showing transfers exists and is used by no page.

More importantly, a transfer moves nothing. Creating one records the transfer and touches no inventory lot at either site, and marking one received records who received it and touches no lot either. The sending site's stock is unchanged and the receiving site's does not appear.

Both who started and who received a transfer are recorded using a signed-in account's own identity, in fields named for staff records.

Procurement and Vendors

Procurement & Vendors, subtitled "Manage purchase orders, vendors, and Buy American compliance." It shows up to three budget tiles above a purchase-order list, with Vendor and New Order buttons.

The budget tiles

The figures behind them are correct: spent is the total of received orders, approved is the total of approved orders, pending is the total of drafts and submitted orders, and cancelled orders are left out of all three.

The page shows three tiles and one of them never appears. Total Budget only shows once a matching figure arrives, and PTRS's answer has no such figure. Total Spent and Pending are named correctly and work.

There is no budget anywhere in the CACFP module for Total Budget to have held.

Vendor

The form collects business name, tax id, contact name, email, phone, address and three ownership flags. Saving it sends a blank site, and PTRS refuses.

Two things about a vendor record worth knowing regardless. The duplicate check works: PTRS refuses a tax id already used by another vendor in your organisation, naming it. And the contact email has no format rule at all, so an overly long value reaches PTRS and comes back as a raw failure rather than a clear message.

Looking up one vendor, updating it and removing it are all built and reachable from no screen, so a vendor cannot be opened, edited or deactivated once created.

Removing a vendor would not remove it either: it only marks the vendor inactive, and does not hide it the way a proper removal would, so it survives every list that does not specifically ask for active vendors only. The vendor picker on this page asks for every vendor, so it would show deactivated ones alongside active ones.

New Order

Two problems beyond the blank site, and both are worth knowing because they would survive a fix to it.

The form has no amount field. It collects vendor, procurement method, order date, expected delivery, notes and a Buy American checkbox, and no money. The page then sends a total of zero, which PTRS refuses outright because it requires a real amount.

The expected delivery date is collected and thrown away: the request PTRS receives has no place for it.

Two of the four methods do not exist. The dropdown offers Micro-Purchase, Small Purchase, Formal Bid and Sole Source.

In the dropdown	Recognised by PTRS
Micro-Purchase	Yes
Small Purchase	Yes
Formal Bid	No, PTRS calls this Sealed Bid
Sole Source	No, PTRS calls this Competitive Proposal
(not offered)	Non-Competitive

The two mismatched choices are refused by name, and the two PTRS recognises under different names cannot be chosen at all. The procurement method is the classification a state reviewer checks first, and three of the five federal categories are unreachable from this form.

A purchase order cannot be approved or received from any screen

Approving and receiving a purchase order are both built and reachable from no screen. The order list shows the status as a badge and offers no action.

Both are correctly guarded: approving requires the order to be a Draft or Submitted, receiving requires it to be Approved. But creating an order always writes Draft, and nothing ever writes Submitted or Cancelled, so two of the five statuses PTRS defines have no writer at all.

Receiving an order stamps the delivery date as the day someone presses the button, not the day the delivery actually arrived. There is no field for the real date, and the date the form would send is thrown away regardless.

Buy American

Buy American Compliance, subtitled "Track domestic sourcing compliance per 7 CFR 226.22." Four summary tiles sit above a table.

This screen is not in the menu

It appears nowhere in the sidebar and nothing else in PTRS links to it. It is reachable only by typing its web address, the same position as Consolidated Claims, Recordkeeping & Document Retention and Offline Mode & Sync.

The fiscal year is the calendar year

The page works out its fiscal year from the calendar year alone.

Two consequences. The federal fiscal year begins 1 October, so from October to December the page asks for and shows the wrong year. And that value is worked out once when the page loads, so a tab left open across New Year's Eve keeps the old value until it is reloaded.

The page shows this value in its subtitle as "FY {year}" and in the table's empty state as "No Buy American records found for FY {year}." So the year a reader sees is a calendar year presented as a fiscal year. Reimbursement Rates has the same class of mistake, computed the other way.

The compliance rate is structurally 0.0%

The rate is worked out correctly: compliant records divided by total records, as a percentage, zero when there are no records at all.

Nothing ever marks a record compliant. The flag is copied straight from what the form sends, rather than worked out from the domestic tick, the country of origin or the USDA-commodity flag, and the form never sends it , so it is false on every record it creates.

So the Compliance Rate tile reads 0.0% while every row in the table below reads "Domestic: Yes," and the Compliant tile reads 0. The table does not show the compliance column at all, so the contradiction is never visible on screen.

The form

It collects Vendor Name, Purchase Date, Country of Origin (defaulting to USA), and two checkboxes: Domestic Product and USDA Commodity. It sends a blank site and a blank food item, both required, so PTRS refuses. There is no site picker and no food picker.

Country of origin is free text with no check at all, so nothing keeps it to an actual country.

A Buy American exception can be requested and never approved

Requesting and listing exceptions are both built and reachable from no screen. There is no exceptions panel on the page.

Beyond that, an exception has no way to be approved at all: every exception starts Pending, and none of who approved it, when, or when it expires has any writer anywhere, there is no approve action. PTRS defines Approved, Denied and Expired statuses, and none is reachable.

The three kinds of exception PTRS accepts are Limited Supply, Cost Differential and Product Unavailable. Nothing in the interface offers them.

The screen pieces built for a compliance card and a status badge here exist and are used by no page.

Where to go next

• Who can do what with menus and inventory, every action on these screens, and which have a screen
• Procurement analytics, the three reports with a narrower rule than the rest of the module
• Work the menu and food screens, the other half of this subset
• CACFP troubleshooting, the exact messages these screens give