Scale Mode Scale thoughtfully

Restaurant Item Master: Keep Outlet Units and Codes Consistent

Give each ingredient one approved identity and base unit, record every pack and local name as a separate dated mapping, and test each conversion before it reaches purchasing, stock or recipes.

Conceptual central kitchen production areas linked to three restaurant outlets.
Conceptual illustration for the Scale Mode series.

When a group adds outlets, the same ingredient starts to collect names. One kitchen orders a case of tomato paste, another records tins, a third enters grams in its recipes. Each record makes sense locally, yet the group can no longer say how much it bought, holds or used without someone converting by hand.

An item master gives each ingredient one agreed identity and base unit, then records every pack, supplier code and local name as a mapping to it. This guide covers that shared definition. It does not cover negotiating with suppliers, tracking stock movements, checking deliveries or general procedure change control. The item, packs and figures are original fiction.

Define one identity before mapping anything

Give each canonical item a code, a specific definition with its specification revision, one base unit, an owner, a source for the definition and an approval record. In the fictional example, TP01 is a tomato paste of one stated specification, with grams as its base unit. The base unit is the unit every other quantity for this item will be expressed in.

Keep the definition precise enough that two people would agree whether a product meets it. A name such as tomato paste is not enough on its own when concentration, ingredients or packaging can differ. The code convention is a local choice; this guide does not prescribe one, and no particular product numbering scheme is required.

Record each pack as its own mapping

A pack mapping links a pack code and the supplier's identifier to the canonical item. Record units per inner pack, inners per pack, declared net quantity and the resulting factor in base units, with the evidence for each, the effective dates, any variant and its status.

The word case means nothing fixed. In the example, pack TP6 holds 6 tins of 1,000 g, so one case is 6,000 g. A later pack, TP4, holds 4 tins of 1,000 g, or 4,000 g per case. Both are cases; they are not interchangeable. When TP4 is introduced, add it as a new mapping with its own effective date. Do not overwrite TP6, because earlier orders, receipts and stock records still depend on it.

Worked example: two packs, one base unit

Two cases of TP6 convert to 12,000 g. Two cases of TP4 convert to 8,000 g. An outlet that records 2 cases without the pack code has recorded an ambiguous quantity: it could be 12,000 g or 8,000 g, and the difference is a third of the larger figure. That is the error the item master exists to prevent.

Fictional packStructureBase units per packTwo packsStatus
TP6 → TP016 tins × 1,000 g6,000 g12,000 gExisting mapping, retained
TP4 → TP014 tins × 1,000 g4,000 g8,000 gNew mapping, own effective date
Unqualified 'case'UnknownUnknownUnresolvedNot a valid conversion

Map two packs to one item only when they match

TP6 and TP4 can both point to TP01 only if someone with the authority to decide has approved that the contents are the same product to the same specification. A different formulation, concentration or ingredient list is a different item, even if the supplier and label look alike. Give it its own identity, or record the mapping as unresolved until the question is answered.

Matching names, matching suppliers or a matching base unit are not evidence of equivalence. The equivalence decision belongs in the record, with who made it and on what evidence, because recipes and costings will inherit it.

Scope every alias to its context

Outlets and systems will keep using their own names. Record each alias against the exact pack or item it means, the unit it is entered in, the system or outlet that uses it and the version it applies to. Supplier codes belong to that supplier; an outlet's shorthand belongs to that outlet.

Check for collisions before approving an alias. The same short code used by two outlets for different packs, or by one supplier for two products, will send quantities to the wrong item. A collision is resolved by scoping or renaming, not by assuming the more common meaning.

Leave unknown conversions unknown

A missing conversion is unknown. Never default it to a factor of 1, which silently treats a pack as a single gram or a single tin. Converting between mass and volume needs evidence specific to that product; a general rule of thumb is not enough. Yield after trimming or cooking is a separate measurement and must not be recorded as a pack size.

Variable-weight items, such as a case of produce sold by actual weight, have no fixed factor. Record the documented weight of each receipt instead, and handle them with a model designed for that. The worksheet in this guide tests only fixed pack factors; it does not calculate nested packaging or import data from any system.

Release a change with a transition plan

Before a new or changed mapping is used, have the responsible people check one real sample transaction through each affected path: a purchase, a stock entry, a recipe and a report. A correct calculation on paper does not prove that every system and form now reads the code the same way.

Plan the transition for anything already in flight: stock on hand in the old pack, open orders, recipes and reports that reference earlier mappings. Keep historical mappings for the period they applied, and record how to reverse the change and retest if a problem appears. A passing arithmetic test is evidence for the calculation, not approval of the mapping.

Where the principles come from

Microsoft's product information documentation describes the value of shared product definitions, identifiers and attributes, including units of measure and their conversions, that are maintained centrally as a continuing task. Its units of measure guidance distinguishes defining what a unit measures from setting conversions, and separates general conversions from those that apply to one product. Only these general principles are used. Software instructions, default settings and release processes are not applied, and no product feature is implied.

Put it into practice

Your action checklist

Your progress saves in this browser. No sign-up needed.

0 of 9 complete

From reading to doing

Item master and pack conversion review

The Item Master Review worksheet holds four manual records: a canonical item register with code, definition, specification revision, base unit, owner, source and approval; a supplier and pack mapping register with at least six slots for pack structure, factor evidence, effective dates, variant and status; an outlet and system alias map with collision checks; and a change, evidence and release record. Eight arithmetic test rows link by test ID to a manual mapping/version record. Each takes a unique test ID, a pack count, approved base units per pack, an independently evidenced expected base quantity and an evidence reference, then show the calculated base quantity, the difference and a validation result. Results appear only when the count is zero or more, the factor is above zero, the expected quantity is zero or more, the ID is unique and evidence is entered; blank rows stay blank. It produces no cross-unit total, readiness score, automatic identity match or master update, and a matching test is not an approval.

Open the Item Master Review tab in the launch workbook. Keep a copy for your own business.

Download the free workbook See what’s inside the toolkit →

Take the next step with Keystonne

Explore Keystonne OS

Explore Keystonne OS and assess the available offering against your operating needs.

Explore Keystonne OS

Sources & further reading

  • Product information overview (Microsoft Learn) ↗

    Page updated 1 July 2026, retrieved 8 November 2026. Used only for general principles of shared product definitions, identifiers, attributes, units and conversions, and ongoing maintenance of product data. Product release, configuration and software instructions are not applied. All items and figures here are original fiction.

  • Manage units of measure (Microsoft Learn) ↗

    Page updated 1 July 2026, retrieved 8 November 2026. Used only for the general distinction between defining what a unit measures and setting conversions, and between general and product-specific conversions. Software steps, defaults and any mandated base-unit setup are not applied, and no product feature is implied.

Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.