Inside VertexCost: why purchase units and recipe units must be explicit

The same item can use different transaction units

Separate at least the Item, Purchase UoM, Recipe UoM and Stock/Base UoM. A single ingredient may be purchased by case, received by pack and consumed by gram. “One unit of cheese” is not precise enough for cost or quantity control.

ERPNext describes UoM as the unit used to measure an item and stores conversion rates separately when transactions convert between units. The general lesson is that conversion belongs in controlled data rather than in someone’s memory.

References: [1]

Pack quantity should be data, not hidden in the product description

For “750 ml bottle × 12”, separate pack quantity = 12, purchase unit = case, inner unit = bottle and content per bottle = 750 ml. A reviewer should be able to reproduce the conversion without interpreting free text.

If the supplier changes a case from 12 bottles to 10, the item may still be the same while the purchase option has changed. A pack-quantity change after price approval should trigger review of the base-unit price instead of silently preserving the old comparison.

Normalize price to a common base before comparison or recipe costing

Suppose a cheese case costs THB 1,600 and contains 8 × 500 grams = 4,000 grams. The illustrative base price is 1,600 ÷ 4,000 = THB 0.40 per gram; a 30-gram recipe component therefore costs THB 12 before waste or other cost elements.

Retain the supplier-quoted price, purchase unit and normalized value with an effective date. Do not replace source evidence with a calculated number only. Discounts, freight and taxes need a defined price basis before supplier options are compared.

A recipe or BOM defines usage structure; it does not create actual cost by itself

ERPNext describes a BOM as a structure containing materials and operations, and BOM costing as an approximate manufacturing cost from those components. A correct recipe provides a standard, while the price snapshot and actual consumption still need their own definitions.

For restaurant use, distinguish Standard Recipe Cost from Actual Consumption and, where useful, Purchase Price Variance. Rewriting old recipes merely to make actual usage match can hide whether the difference came from portioning, waste, purchase price or unit-recording errors.

References: [2]

For VertexCost, confirm the identity that was approved—not merely the supplier name

A purchase-option identity should include supplier, item, purchase UoM, pack quantity and conversion used at approval. If any of those later change, mapping or approval should be reviewed rather than carrying an approved status to a materially different option.

Linda lists VertexCost for recipes, costing and purchase planning and states that modules, permissions and handoffs are confirmed before onboarding. Use this article as a demonstration checklist: test one item with several pack sizes, different purchase and recipe units, and a pack change after approval.

References: [3]

Apply it to your business

Reliable costing starts with item identity and units, not a more complicated formula. If purchase and recipe units are ambiguous, detailed-looking cost figures can create false precision.