How Rinvy calculates product cost
The number on a product page, the number on a report, and the number on a recipe-output product are computed in three different ways. This article maps each one to what it actually means so you can read a report without second-guessing the numbers.
1. The case cost on the product page
This is the most recent per-case price Rinvy has seen, rolling forward.
- When you create a product, you enter case cost manually.
- Every time you receive a delivery, Rinvy overwrites the product's case cost with the per-case cost from the new receipt.
- Editing or deleting a receipt rewinds it to the previous receipt's value.
The product page's "unit cost" is just case cost ÷ case size — read-only, derived from this rolling value.
2. The weighted-average cost reports use
Reports don't read the product's case cost. They compute their own weighted average across the receipts that fall inside the report's date range.
The fallback chain:
- If there's at least one receipt in the report's date range, use the weighted average of those receipts (
total $ ÷ total quantity). - If no in-range receipts but at least one all-time receipt, use the most recent receipt's per-unit cost.
- If no receipts ever, fall back to the product's case cost (which is the value you originally entered).
This is why the Spending and Inventory Value reports can show a different per-unit cost than the product page — they're answering "what did this cost us on average" vs. "what's the last price we saw."
3. Recipe-output cost (computed recursively)
A recipe-output product (marinara, pizza dough) has no purchase price — it's made in-house. Its cost is computed by:
- Walking the recipe's ingredients.
- Looking up each ingredient's per-unit cost using the rules above (weighted average → fallback chain).
- Multiplying by the recipe quantity and unit conversions.
- Dividing by the yield quantity to get the output's per-unit cost.
If an ingredient is itself a recipe output, the calculation recurses.
How edits cascade
- Editing a receipt updates the product's case cost AND retroactively changes weighted-average cost on any report whose date range includes that receipt.
- Deleting the most recent receipt rewinds the product's case cost to the previous receipt and removes the receipt from report averages.
- Changing case size updates the displayed unit cost immediately (it's
case cost ÷ case size) but past receipts are unchanged — the weighted average in reports still reflects the cases as they were at receive time.
Where this matters
- Menu item food cost: uses the recipe-output cost (#3), which recurses to weighted-average ingredient costs (#2).
- Variance report: theoretical cost uses #2 from sales × recipes; actual uses #2 from inventory changes.
- Order list and product page: shows #1 (rolling latest).
Common mistakes
Editing the product's case cost to "fix" a report
The report doesn't read the product's case cost (unless there are zero receipts in range). Editing it changes the future starting point, not history. To fix a report, fix the underlying receipt or recipe.
Expecting a recipe-output product to have a fixed cost
Its cost moves every time an ingredient receipt lands. That's the point — food cost reports stay accurate.
Setting a case cost on a product that's never received
Reports will use the product's case cost as the fallback. That's fine for a quick starting estimate but you should add at least one real receipt as soon as you can — the weighted-average path produces much better numbers.