For Managers · 7-minute read

Vendor management & purchase orders

Most of a campus manager's relationship with procurement happens in one of two places: setting a preferred vendor for an item, and drafting a purchase order against the shortfall on the low-stock dashboard. This page covers both, plus what happens after you send a PO and how preferred-vendor changes quietly reprice your recipes.

What "preferred vendor" means

Every item in PrepTable can have exactly one preferred vendor: the supplier you buy it from by default. PrepTable uses that one vendor to:

• Drive the unit cost on the item — the value every recipe rolls up to compute plate cost (COGS).
• Pre-fill the vendor field on a purchase order for that item.
• Surface a single pricing change to track over time (the cost-outlier check on the menu-health report).

If you buy onions from two vendors — Sysco at $14/50lb and a local farm at $11/50lb — only one of them is "preferred." The other can be recorded as an alternate vendor for occasional ordering (see below) but doesn't drive the cost rollup. Choosing the preferred vendor is the single most leveraged decision a manager makes because it sets the cost number every recipe relies on.

You set the preferred vendor per item under Items → pick an item → Vendors tab. Admins own the vendor catalogue (creating new vendor records, adding SKUs); managers choose which of those vendors is preferred for each item at their campus.

How changing the preferred vendor reprices recipes

When you change an item's preferred vendor, PrepTable recomputes every recipe that uses that item at the moment of the change. The next time anyone looks at a recipe's plate cost, it reflects the new preferred vendor's price.

Two things follow from this that are worth internalizing:

1. Cost changes are immediately visible downstream. A recipe that used $1.10 plate cost on Tuesday morning will show $0.95 plate cost on Tuesday afternoon if you switched the onion's preferred vendor mid-day. There's no "morning price" / "afternoon price" — there's one cost per recipe, recomputed when it has to be.
2. The cost-outlier check on the menu-health report starts working for you. When a vendor sends you a price-change notification next month, you change the preferred vendor's pricing record; the next menu-health run flags every recipe that moved out of its expected band, with the new cost inline.

Pricing records vs. vendor records

There are two related but distinct concepts:

• Vendor — the supplier record (name, contact, payment terms, address). Created once. Tenant-global (you don't duplicate Sysco per campus). Admins own.
• Vendor pricing — the (vendor, item, price, unit) record that says "Sysco sells yellow onion at $14 per 50 lb case as of 2026-06-15." Multiple per vendor (Sysco has a pricing record for yellow onion, one for ground beef, one for canola oil). Updated whenever the vendor announces a change.

When you "set a vendor's price for an item," you're updating the vendor pricing record. The item's unit_cost_cents is then recomputed from the preferred-vendor's pricing record. The audit log captures every change to both.

Alternate vendors

A non-preferred vendor can still record pricing for an item. That's useful when:

• The preferred vendor is briefly out of stock and you're one-shotting from another supplier at a higher price.
• You want to record but not act on a competing offer, so the cost rollup clearly shows what you'd save by switching.

Alternate vendors don't drive unit_cost_cents. They show up in the "alternate pricing" list on the item. Switching the preferred vendor flips which one drives cost; you can switch back any time.

Drafting a PO from low-stock (the full loop)

The par-levels page covered the draft step. This page covers the rest:

1. Draft — from the low-stock dashboard, click Draft PO from shortfall. PrepTable pre-fills vendor and quantities.
2. Review — drop items already on order, substitute alternates if the preferred vendor is out, adjust quantities for special events or projected increases.
3. Send — click Send to vendor. The PO moves from Draft to Sent status and (in a real deployment) is emailed to the vendor. The audit log records the send with the actor and timestamp.
4. Receive — when the shipment arrives, an admin or manager marks the PO received. PrepTable updates each item's stock count by the received quantity and creates a stock_movements row attributed to the receiving user. The PO closes.

If you receive a partial shipment (3 of 5 cases arrived), mark each line with the actual received quantity rather than the full line. The remaining quantity stays on the PO as a back-order line.

What the audit log captures for the vendor flow

Every step of this loop is logged:

Event	Captured
Vendor pricing changed	Old price, new price, effective date, actor
Item's preferred vendor changed	Old vendor, new vendor, actor
PO drafted	Full PO contents, draft actor
PO sent	Send timestamp, recipient
PO line received	Per-line received quantity, receiving actor
PO closed	Closing actor, final state

If a manager asks "did we ever get the right price on the yellow onions?" — both the vendor-pricing change log and the per-PO line captures answer the question from the same audit log screen.

Common mistakes to avoid

• Setting preferred vendor on a campus that doesn't buy from them. Preferred vendor is per-item, tenant-global, so once you've set it, every campus reads that price. If Waco prefers Sysco and Harlingen prefers a local farm, set per-campus preferred vendors (admin configures the campus-level override) — contact your admin if this isn't already enabled for your install.
• Recording vendor pricing in the wrong unit. "Yellow onion at $14" is ambiguous between per-pound, per-50lb-case, and per-bag. Always record the unit explicitly. The cost rollup uses the unit to convert: a recipe saying "0.5 lb yellow onion" and a vendor pricing record saying "$14 per 50 lb" requires that unit translation to be right. The UI prompts for it but doesn't second-guess.
• Forgetting the receiving step. A PO in Sent status that never moves to Received means stock counts don't update, the item stays below par on the dashboard indefinitely, and the cost-outlier check sees stale data. Receiving is its own workflow stage for a reason; do it the day the truck arrives.

Where to go next

• Par levels & low-stock alerts — the inventory side of this workflow
• The menu-health check — the cost-outlier check that fires when a preferred vendor changes