Scope and Locations — where stock sits, and the four ways every movement is labeled¶

What this covers. Every time stock moves — received, sold, transferred, wasted, counted, prepped — the system has to answer two kinds of question: where did it go, physically? and whose numbers does it belong to? This chapter teaches both. First, locations: the storage locations inside a warehouse where goods actually sit, and the small set of virtual ones (a vendor, a customer, the bin, the prep line) that stand for "the outside world" on the other side of every entry. Then the four labels stamped on every movement — Company (the tenant it belongs to), Warehouse (the accounting contour whose books hold its value), Restaurant (whose profit-and-loss it lands in), and Channel (how a sale reached the business). Along the way: why a business chooses how finely its stock is valued by how many warehouses it creates rather than by any setting; the storage locations that split physical quantity inside one warehouse without splitting its value; and the many-to-many relation, with the explicit transfers that ride on it, that lets one shared prep warehouse supply several restaurants without misstating any of them.

1. Every movement is a move between two locations¶

Before the four labels, you need the thing they label. The whole stock system is built on one humble primitive: a stock movement — a quantity of one item going from one location to another. Receiving, selling, transferring, wasting, counting, prepping a batch — every one of them is the same shape, a from → to. Nothing is created or destroyed; quantity just moves.

This is the discipline of double-entry: in bookkeeping, every entry touches two accounts so the books always balance. Here the two "accounts" are two locations. If 10 kg of flour leaves a storage location, those 10 kg have to arrive somewhere — even if "somewhere" is the scrap bin or a customer's plate. There is no such thing as stock that simply vanishes; if it's gone, it went to a named place, and that place is the second half of the entry.

Why insist on this? Because "stock disappeared and I don't know where" is exactly the hole every inventory system is built to close. Forcing a destination on every movement means the books always answer where did it go, which in turn makes the month-end count a reconciliation rather than a mystery.

Worked example. You waste 2 kg of spoiled lettuce. That is not "−2 kg lettuce, reason unknown." It is one movement: 2 kg lettuce, from the walk-in fridge, to scrap. That location's on-hand drops by 2 kg; the scrap side records that 2 kg arrived there. The entry balances, and "where did the lettuce go" has an answer.

2. Storage locations vs virtual locations¶

Locations come in two flavors, and the difference is the key that unlocks the rest of this chapter.

A storage location — an internal location, in the model's own word — is a count area the business manages inside one warehouse, where goods physically sit: a walk-in, a back room, a bar. Each carries its own quantity, so it can be counted and corrected without pretending stock sits somewhere else. The warehouse remains the accounting contour: the storage locations inside it share one value pool, one average cost, and one period close.

A virtual location is not a place you own or count. It is a stand-in for "the other side" of a movement — the counterparty an entry needs in order to balance. The system seeds a small, fixed set of them per company, and they exist purely so that every movement has a legitimate second half. You never count them; their job is to absorb or supply the goods that cross your boundary.

There are seven location usages in all — one real, six virtual:

Usage	Real or virtual	What it stands for
internal	real	a storage location inside a warehouse — managed and counted by the business
supplier	virtual	the outside vendor stock comes from on a goods receipt
customer	virtual	the outside buyer stock goes to on a sale
scrap	virtual	the bin — where waste, spoilage, and expired stock go
production	virtual	the prep line — the in-between place during a batch prep
transit	virtual	"in the van" — the in-between place during a transfer between warehouses
inventory loss	virtual	the reconciling counterparty for count differences (shortage and overage)

Why have these at all? Because a movement needs two locations, and not everything that touches your stock is a place you own. When flour arrives, the real warehouse gains it — but where did it come from? Not another location of yours. It came from the vendor, which isn't yours to count, so "supplier" stands in as the source. When a dish is sold, the real warehouse loses ingredients — but they don't move to another location of yours; they go out the door to the customer, so "customer" stands in as the destination. The virtual locations let the books stay balanced and one-way without pretending the outside world is part of your inventory.

The walk-in, the bar, and the back room are therefore not annotations beneath a location: they are the warehouse's storage locations. A receipt put away in the walk-in lands there, and a relocation from the walk-in to the bar changes the quantity in each. Because both ends belong to the same warehouse, that relocation changes neither warehouse quantity nor value.

Here is how the everyday operations decompose — note that each is the same primitive, distinguished only by which location is real and which is virtual, and on which side:

Goods receipt (the receiving of goods from a vendor): supplier → internal. Stock crosses in from the vendor; your warehouse gains it.
Sale: internal → customer. Stock crosses out to the buyer; your warehouse loses it.
Waste: internal → scrap. Stock leaves for the bin (spoilage, breakage, an expired lot).
Transfer between two of your warehouses: internal → transit → internal. Two legs, with "transit" as the in-between — goods leave one warehouse, ride in transit, then land in the other. (Both ends are real; transit just models the gap.)
Production (prepping a batch): internal → production to consume the inputs, then production → internal to yield the finished prep back into a storage location. (More in the recipes chapter; here the point is only that "production" is the virtual in-between.)
Count difference at close: stock loss → internal when the stock count finds more than the book said (an overage), or internal → stock loss when it finds less (a shortage). The difference is absorbed by the virtual loss location so the perpetual book is pulled to match the physical truth.

Worked example. You receive 100 kg of flour, then sell dishes that consume 8 kg, then a 1 kg sack splits and you bin it. Three movements, three different "other sides": supplier → dry goods (+100), dry goods → customer (−8 across the sold dishes), and dry goods → scrap (−1). That storage location nets to 91 kg on-hand; the vendor, the customers, and the bin are virtual and never counted. Every gram is accounted for.

3. Why a movement carries four labels, not one¶

Knowing where stock went (§1–2) is only half the story. The other half is whose books it belongs to — and that turns out to be not one question but four, because the answers sit at different grains.

A naïve system uses a single location concept and hangs everything off it: "the restaurant has 40 kg of flour worth €X and sold €Y of pasta this month." That collapses the instant two restaurants share a prep warehouse, because the question "what is a kilogram of flour worth right now?" and the question "which restaurant earned the margin on that pasta?" have different correct answers at different grains:

Value is a property of where stock physically sits. A kilogram of flour in the shared prep warehouse has exactly one current cost — its weighted-average cost (the running blended price of every unit on hand; abbreviated WAC). That cost is a function of what was received into that building and at what price — not of which restaurant will eventually eat it. If you valued flour per-restaurant you would have to invent a price the moment it crossed an internal boundary, and you would get two different "costs" for one identical sack.
Profit-and-loss is a property of who is responsible for the result. A restaurant's food-cost percentage, its margin, its cost of goods sold — these are management questions about a business unit, not about a building. One shared prep warehouse can supply three restaurants; each restaurant needs its own profit-and-loss; the warehouse itself earns no margin.

So a single stock movement gets stamped with four labels, each answering a different question, and they are deliberately independent — knowing one tells you nothing about the others:

Label	The question it answers	The grain it owns
Company	Whose tenant is this?	Isolation — every row belongs to exactly one company
Warehouse	Which books hold its value?	The accounting contour — valuation, on-hand, count, and close together: one cost pool, one WAC per company-and-warehouse-and-item
Restaurant	Whose profit-and-loss?	Profit-and-loss / cost-of-goods attribution — stamped onto the movement, never owns the stock
Channel	How did the sale arrive?	Reporting only — never a stock or valuation axis

The rest of this chapter takes them one at a time. The single most important idea, worth stating up front and returning to at the end: value rides the warehouse label; profit rides the restaurant label; and those are not the same axis. That separation is what lets one physical warehouse serve two profit-and-loss statements without double-counting a single gram of flour.

This is not a Sizl invention. It is the canonical separation, in every serious inventory system, between the valuation location (where stock is valued) and the profit center (the responsibility dimension a result is attributed to) — the latter stamped onto transactions rather than owning the stock. We adopt the standard, named pattern.

4. The four labels, one at a time¶

4a. Company — the tenant boundary¶

A company is the top of the world: the tenant that owns everything beneath it. Every warehouse, every restaurant, every stock movement, every cost figure, every accounting period lives under exactly one company and is invisible to all others. It is the isolation boundary, not a stock concept — it answers "whose data is this?" and nothing finer.

Why is it a hard wall rather than a soft filter? Because tenants must never see one another's stock or numbers, not even by accident. So the rule is fail-closed: every company-scoped read is filtered to the one resolved company, every write is stamped with it, and if no company is resolved the operation refuses rather than silently returning or touching another tenant's data. The active company is established from the authenticated session, never supplied by the caller.

For the stock domain, the practical consequences are:

Every cost figure is keyed by company, warehouse, and item together. The company prefix is always present — even when it goes unmentioned, it is implied by the fact that the warehouse and the item are themselves company-scoped.
"Company-wide" valuation is not a separate grain. It is only the degenerate case where a company happens to run a single warehouse. The moment there are two warehouses, there is no single company-wide cost for an item — there are two warehouse costs (see §4b).
A company carries a single trading currency and a single tax posture (US vs EU), which the costing layer reads. The company itself does no tax or currency math; it is purely the boundary. (Costing and tax live in the costing chapter.)

4b. Warehouse — the accounting contour¶

A warehouse is where stock physically sits: the set of storage locations a business values together (§2). It can be a restaurant's small back-of-house store, a bar's stock of bottles, or a large shared commissary (a central prep-and-hold warehouse that supplies several restaurants — by explicit transfer, §5). The warehouse entity does not distinguish these; the only difference is how many restaurants it supplies (§5).

The warehouse is the accounting contour — the grain at which value is computed, physical truth is asserted, and books are sealed. Three things that could in principle have lived at three different grains deliberately live at exactly one:

                    ┌─────────────────────────────┐
                    │        one warehouse        │
   what it is worth │  cost pools, one WAC each   │
   what is really   │  the count that walks it    │
     there          │                             │
   when it is final │  the period close           │
                    └─────────────────────────────┘

They are bound together on purpose, and the binding is what makes a close auditable. The value the close publishes is proved by a count; the count is complete for exactly the storage locations the pool covers; the pool is exactly what that count walked. Break the alignment — value one set and count another — and the closing figure stops being reproducible from any one walk, which is the same as saying nobody can check it.

What that grain owns, concretely:

One shared cost pool per warehouse. Within a warehouse, an item has exactly one weighted-average cost. Every unit of that item sitting in that warehouse is valued at that single number; there is no per-restaurant, per-lot, or per-receipt sub-price for valuation. (Lot and expiry detail are tracked separately for items that need it — see the stock-ledger and food-attributes chapters — but quantity and value live at the warehouse grain.)
The same item can cost different amounts in different warehouses. Flour received cheaply into the commissary and flour received at a higher price into a satellite store are two distinct cost pools. This is correct and intended: you value stock where it sits, at what it actually cost to get it there.
Counts, their overage and shortage adjustments, and period close happen at the warehouse grain. Each warehouse closes its own books on its own calendar, in its own timezone, at its own cadence — a rhythm it declares (weekly, monthly, quarterly, annual, or simply count-to-count) that pre-fills the next boundary without ever forbidding another date. A physical count reconciles one warehouse's perpetual book to its physical truth; any shrinkage found at close re-spreads value over the counted quantity in that warehouse (the reconciliation chapter has the detail).
The durable assets placed on it. A warehouse's books carry more than pools: the fixed assets placed on it are its responsibility too, confirmed serial by serial on the same walk and included in its balance at book value. A unit the company owns but has placed on no warehouse is nobody's responsibility yet, and in nobody's balance. See Fixed assets.

The reason value must sit here and nowhere else is the one from §3: a kilogram of flour in a warehouse has exactly one honest current cost, set by what was paid to land it there. Attach value to anything coarser (the company) and you lose the two-warehouse case; attach it to anything finer or sideways (the restaurant) and you have to invent a transfer price the moment stock crosses an internal boundary. The warehouse is the grain at which "what is this worth right now?" has a single, real answer.

Every warehouse works the same way: it holds standing stock and, from the opening count that starts its stock-keeping, counts and closes as described above. A site that has physically separated its prep does not need a different kind of warehouse for it — the production floor is simply another storage location inside the warehouse that feeds it, so raw goods walk onto it by relocation, a batch may draw its inputs from it, and it is counted and closed like any other. The full story is in Recipes & production.

4b.1 Valuation strategy is a shape, not a setting¶

Businesses differ in how finely they want stock valued. Some want one blended cost for the whole company — simple, one number to explain, one walk to organize. Others want to know exactly which site is losing money on olive oil, which needs each site valued on its own.

Many systems expose that as a mode: a company-level switch between "value everything together" and "value each site separately." This model has no such switch, and will never have one. The choice is made by how many warehouses the company creates — the same decision, expressed as a shape instead of a flag:

one blended cost for the business
  → create ONE materials warehouse
    one pool per item · one average · one count · one close

see where each site's loss happens
  → create ONE warehouse PER SITE (or per room)
    independent pools, independent counts, independent closes

Why a shape rather than a flag: a flag would let the pool, the count, and the close come apart. Blend the pools across three warehouses while each one still walks its own storage locations on its own week, and the blended figure is confirmed by no single count — you could never point at one walk and say "this is the evidence for that number." Making the contour the only dial keeps the three permanently aligned, and it means there is exactly one set of close rules in the world rather than one per mode.

Two consequences worth internalizing:

Coarser is always available by arithmetic. A company-wide figure is just the sum of its warehouses' figures, and a company-wide unit cost is the value-weighted blend of theirs. You never lose the coarse view by cutting fine; you only lose the fine view by staying coarse.
Cutting finer later is honest work, not a re-computation. Splitting one warehouse into three is done the way a real business would: create the new warehouses, take an opening count in each, and transfer what belongs there. History is never re-priced retroactively — the old pool's past stays exactly as it was recorded, and the finer pools begin from an asserted truth on a stated date.

A newcomer's rule of thumb: start with as few contours as you can defend. One materials warehouse is a perfectly serious configuration for a single site or a small group — and if the business keeps durable assets, a second warehouse holding nothing but those assets, closing once a year, is the whole of "the annual asset check" with no extra ceremony invented for it. Cut finer only when you have a question the coarse books cannot answer.

4b.2 Storage locations — quantity below the contour, without a second value pool¶

Inside a warehouse, "where exactly?" is a real stock question. The walk-in, the bar, the back room, the dry-goods corner by the door — each is one of its storage locations. Every warehouse has one default storage location for documents that do not name a more precise destination; the others are named explicitly when goods are put away, moved, consumed, written off, or counted.

A storage location carries quantity but not its own value pool. All the storage locations in one warehouse share the warehouse's weighted-average cost and close together. Moving 12 bottles from the back room to the bar reduces one by 12 and raises the other by 12, while warehouse quantity and value stay unchanged.

warehouse   the contour: one value pool and one close
  └ storage location   the count area: "walk-in", "bar"
      └ note / label   free text: "shelf 3", "with Vasya"

Each active storage location gets its own stock count. A warehouse can close only after every storage location that existed at the period boundary has a qualifying full count; those archived earlier or created later are outside that walk. Each of those counts then settles that storage location against its own book — a difference is recorded where the walk happened, and one storage location's loss is never re-attributed to another. The warehouse's figure is the sum of the parts: it is derived, never a place a difference is posted to.

4c. Restaurant — whose profit-and-loss (the profit center)¶

A restaurant is a profit center: the business unit whose food cost, cost of goods sold, and margin we report. It also carries a local clock — its own working hours and timezone — which is what stamps a sale with the right business date (the calendar day a sale belongs to in the restaurant's own local time, regardless of the raw timestamp). That business date drives which recipe version applies and which accounting month a sale lands in.

The restaurant is the profit-and-loss attribution grain — and nothing more in the stock domain. Critically:

A restaurant does not own a stock pool and is not a valuation grain. It never holds the authoritative on-hand or the authoritative cost of an item. There is no per-restaurant cost of a kilogram of flour. Per-restaurant profit-and-loss is a roll-up of attributed consumption — you sum the value of the consumption movements stamped with that restaurant over the period — not a second place where stock is valued.
The restaurant label is stamped onto a movement, not owned by stock. When a sale consumes stock, each resulting consumption movement is stamped with the restaurant that earned the sale (and with the warehouse the route resolved — one of that restaurant's own stores, §5). The restaurant rides on the movement as an attribution tag; it does not own the movement.
The restaurant is purely a business/reporting axis — it is not an authorization boundary. Tenancy is the company's job (§4a). This is exactly the right footing for a profit center.

A word the model deliberately avoids here: do not call a restaurant "the kitchen." A kitchen station on a dish (§5), or a warehouse named kitchen, are fine and appear below — but the restaurant is the business and its profit-and-loss, not a room.

The company roll-up (the whole-tenant profit-and-loss) is then the aggregate over restaurants and the company's warehouses — never a separately-valued grain of its own.

4d. Channel — how a sale reached the business¶

A channel records how a sale arrived — dine-in, a specific delivery marketplace, a till, a spreadsheet import batch — so that revenue and consumption can be sliced by channel in reporting. The order side of the business owns the notion of a channel; the stock side carries it as an attribution tag on the sale, alongside the restaurant.

The one hard rule: a channel is never a stock axis and never a valuation axis. Stock is not held "in a channel," is not counted by channel, and is not valued by channel. Two pasta plates sold through two different channels deplete the same warehouse cost pool at the same weighted-average cost; only the reporting dimension differs. Channel is therefore the lightest of the four labels — a slice for the profit-and-loss, with no claim on where stock sits or what it is worth. It is listed here so the set of four is complete and so no one is tempted to model a channel as a location.

5. The restaurant ↔ warehouse relation (consumes-from / supplies)¶

This is the relation that makes the whole separation pay off.

The shape: many-to-many¶

A restaurant consumes from one or more warehouses of its own; a warehouse may supply one or more restaurants. The relation is many-to-many, and it reads in both directions — "this restaurant consumes from these warehouses" and "this warehouse supplies these restaurants" are its two faces. The common case is a restaurant with a single primary warehouse (its own back-of-house store); the case that requires many-to-many is the shared commissary supplying several restaurants.

This is the textbook plant-to-profit-center relation: one warehouse assigned to several profit centers is a standard, supported topology, and the shared commissary is exactly that case. The relation is ordinary, not exotic.

Why many-to-many and not one-to-many¶

A one-to-many relation — "this warehouse belongs to this one restaurant" — cannot model:

A commissary that preps dough and sauces for Restaurant A and Restaurant B. It would have to belong to one of them, and the other could not legitimately be supplied at all.
A restaurant that consumes from two of its own warehouses — say a kitchen store and a bar store, each holding different materials.

Many-to-many is the minimum shape that expresses "this commissary supplies these three restaurants, and this restaurant draws on these two warehouses of its own."

What the relation carries — and what it does not¶

The two faces of the relation do two different jobs:

Consumes-from (restaurant → its own warehouses) establishes the eligibility set for consumption routing: which warehouses a restaurant's sales may deplete. One of them is marked as the restaurant's default consumption warehouse — the mandatory final fallback in the routing below.
Supplies (warehouse → restaurants) establishes the eligibility set for distribution: which restaurants a warehouse — typically a commissary — may legitimately send stock to.

The relation does not create a stock pool per pairing and does not value stock per restaurant. Valuation stays at the warehouse; the relation only governs eligibility and routing targets within the restaurant's own stores — which warehouses its consumption may deplete, and which restaurants a warehouse may supply. And it does not let a sale reach across the company into a pool the goods have already left — which is the next rule.

Goods travel by explicit transfer; consumption stays home¶

When a commissary preps dough for a restaurant, the dough physically leaves the commissary — so the books must say so. The dispatch is recorded as an explicit transfer (internal → transit → internal, see the stock-ledger chapter) into the restaurant's own store, and only then is it consumed. The hard rule that follows: a sale's consumption always depletes one of the selling restaurant's own consumption warehouses — never a remote pool the goods have physically left.

Why so strict? Because the alternative makes two books lie at once. Imagine Downtown's pizza sales depleting the commissary's dough pool while the dough physically sits in Downtown's own store: the commissary's book now claims dough it no longer holds, and Downtown holds dough its book has never heard of. Neither warehouse can be counted truthfully — and the physical count is the one moment the whole perpetual system is reconciled against reality. Recording the transfer keeps every warehouse's book equal to what its storage locations actually hold, at both ends, at all times.

Value rides along: the transfer carries the goods at the sending warehouse's weighted-average cost and re-blends into the receiving store's own pool — value-conserving, with no invented internal price. The worked example in §7 shows the full arc.

Stations — how a dish names its store¶

Routing needs one more concept. A station is a tag a dish carries — kitchen, bar, and so on — naming the part of the operation that makes it. The vocabulary is per-company and deliberately small; a station is a kind of work, not a place. Each restaurant then maps each station to exactly one of its own consumption warehouses: at Downtown, bar might map to Downtown's bar store and kitchen to its back-of-house store; Uptown maps the same stations to its stores. The dish declares its station once, company-wide; each restaurant decides locally which of its own warehouses that station means. That per-restaurant mapping is the dish-line default in the routing below.

Routing a sale's consumption to a warehouse¶

When a dish sale is unpacked into its raw ingredients (the recipe explosion — see the recipes chapter), each ingredient must deplete some warehouse's pool — always one of the selling restaurant's own. The warehouse is resolved by a three-level fallback:

Per-item override (opt-in) — a specific ingredient can be pinned to a specific warehouse, applied after the recipe is unpacked.
The dish's station, mapped by the selling restaurant — a bar drink draws from that restaurant's bar store, a kitchen dish from its kitchen store (each store being one of the restaurant's own warehouses). This resolves at the dish line when no ingredient override applies.
The restaurant's default consumption warehouse (mandatory) — used when neither of the above applies, so a sale is never left with nowhere to draw from.

Each level names a warehouse, and may also pin a storage location inside it — so two restaurants sharing one central store each draw from their own area of it. When the winning level pins none, the draw lands in the warehouse's default storage location. Either way it is the warehouse's one value pool that is depleted; the storage location only records where inside the quantity left from.

The restaurant supplies the attribution (whose profit-and-loss); the routing supplies the valuation source (whose cost pool — always one of that restaurant's own). The two answers come from two different labels — which is the entire point.

6. Valuation grain vs profit-and-loss grain — stated once, precisely¶

This is the rule to carry away:

Valuation grain = Warehouse. On-hand and value are computed per company-and-warehouse-and-item. One shared cost pool, one weighted-average cost, per warehouse. Counts, overage and shortage adjustments, reconciliation, and period close all happen here — which is why the warehouse is called the accounting contour, and why how many of them a business creates is its valuation strategy (§4b.1).
Profit-and-loss grain = Restaurant. Cost of goods and margin are a profit-center roll-up of the value of consumption movements stamped with that restaurant over a period. A restaurant is never a place where stock is valued.

A consumption movement is therefore stamped with both: a warehouse (whose pool it depletes — and therefore what it costs) and a restaurant (whose profit-and-loss it lands in). The same physical depletion answers the valuation question at the warehouse grain and the profit-and-loss question at the restaurant grain from one record. That is how a prep cost computed once at the commissary can travel — by transfer — into each restaurant's own store and still land in whichever restaurant's profit-and-loss sold the dish.

7. Worked example: a commissary serving two restaurants¶

Setup. One company ("Flow") runs two restaurants and one shared commissary:

Warehouses: Commissary (preps and holds dough), Downtown Store, Uptown Store.
Restaurants (profit centers): Downtown, Uptown.
Consumes-from / supplies (many-to-many):
Downtown consumes from Downtown Store (its default consumption warehouse); its kitchen station maps there.
Uptown consumes from Uptown Store (likewise).
Commissary supplies both Downtown and Uptown — it may transfer prepped stock into either restaurant's store. (A one-to-many "this warehouse belongs to one restaurant" link literally cannot express this — the commissary would have to belong to just one of them.)

Step 1 — Receive flour into the commissary. A goods receipt posts a supplier → Commissary movement: 100 kg of flour at €0.50/kg = €50. The commissary's flour weighted-average cost is now €0.50/kg. Note the cost belongs to the warehouse, decided by what was paid to land it there. No restaurant is involved yet — receiving is not a profit-and-loss event.

Step 2 — Produce dough at the commissary. A production move-pair consumes flour Commissary → production and yields dough production → Commissary. Say 80 kg of flour (€40 at €0.50/kg) plus other inputs yields 90 kg of dough; the input cost rolls into the dough's cost — suppose it works out to €1.20/kg. Dough is a stocked prep item — formally, a semi-finished good: an item the business makes and stocks in advance, with its own recipe — held at the commissary: again a warehouse-grain valuation, still no restaurant attribution. (Production mechanics live in the recipes chapter; the point here is that the cost pool is the commissary's.)

Step 3 — Transfer dough to each restaurant's store. The commissary dispatches 30 kg of dough to Downtown Store and 20 kg to Uptown Store — two ordinary transfers, each internal → transit → internal. The dough leaves the commissary at its €1.20/kg weighted-average cost (€36 and €24 of value respectively) and re-blends into each receiving store's own dough pool — here each store held no dough before, so each pool now also stands at €1.20/kg. Value is conserved end to end; nothing was bought or sold. The dough now physically sits — and is booked — in the restaurants' own stores, and the commissary's book dropped by exactly what physically left it.

Step 4 — Sell a pizza at Downtown. A guest orders a pizza at the Downtown restaurant. The sale is unpacked, against the recipe in force on the sale's business date, down to its raw ingredients; one of them is 200 g of dough. Routing resolves the warehouse: the pizza's station is kitchen, and Downtown maps kitchen → Downtown Store. The consumption movement is:

from Downtown Store (internal) → to customer (virtual)
item = Dough, quantity = 0.200 kg
Warehouse = Downtown Store — the valuation source: depletes its own pool at its dough weighted-average cost of €1.20/kg → 0.200 × €1.20 = €0.24
Restaurant = Downtown — the profit-and-loss attribution: Downtown earned this sale
Channel = dine-in / marketplace / … — the reporting tag

Step 5 — Sell the same pizza at Uptown. Identical unpacking, identical 200 g of dough — drawn from Uptown Store's own pool, also at €1.20/kg, also €0.24. But this movement is stamped Warehouse = Uptown Store and Restaurant = Uptown. Same dish, same cost, two truthful books.

Step 6 — Roll up. At period close:

Commissary (valuation / close grain): it produced 90 kg of dough and transferred 50 kg out; its book says 40 kg on-hand at €1.20/kg — exactly what its storage locations hold. It counts and closes its own book; any shrinkage found re-spreads over its counted quantity. There is one dough cost, computed once, regardless of which restaurant eventually serves it.
Downtown Store: received 30 kg, consumed 0.2 kg → book and physical truth agree at 29.8 kg. Uptown Store: likewise at 19.8 kg. Every warehouse's count is truthful, because the dough's physical journey was recorded as movements at every step.
Downtown profit-and-loss (profit-center grain): dough cost of goods includes its €0.24. Uptown profit-and-loss: dough cost of goods includes its €0.24. Each restaurant's food-cost percentage is computed from the value of consumption attributed to it, at a cost the commissary computed once.

The payoff. One sack of flour was valued exactly once (at the commissary, at what it cost to land there), and one dough cost was computed exactly once (at the commissary) — then that cost simply traveled with the transfers, re-blending value-neutrally into each store's own pool, so each pizza's €0.24 reads straight off the selling restaurant's own warehouse. Two restaurants each got a correct, independent profit-and-loss — valuation rode the warehouse label and attribution rode the restaurant label — and every warehouse's book matched what it actually held at every moment, because the dough's physical moves were explicit. The many-to-many relation is what lets one commissary legitimately supply both restaurants; the explicit transfers are what keep both ends countable. Without the transfer, Downtown's sales would have silently drained a pool whose goods left the commissary days earlier — and at least two counts would have stopped being true.

8. Common pitfalls¶

Valuing per restaurant. There is no per-restaurant cost of an item. If you find yourself computing one, you have collapsed the valuation grain into the profit-and-loss grain — value at the warehouse, attribute to the restaurant.
Treating "company-wide" as a real valuation grain. It is only the single-warehouse degenerate case. With two warehouses there is no single company cost for an item.
Hunting for a valuation-strategy setting. There isn't one, by design. If you want a single blended cost, create a single materials warehouse; if you want per-site isolation, create a warehouse per site. The topology is the strategy (§4b.1).
Treating a storage location as a small warehouse. A storage location has a quantity and its own count, but no average cost or close. The moment a place needs separate valuation and a separate period, it needs to be a separate warehouse.
Modeling a channel as a location. A channel is a reporting tag on the sale; it never holds, counts, or values stock.
Reaching for a one-to-many warehouse→restaurant link. It cannot express a shared commissary or a restaurant drawing from two of its own warehouses. The relation is many-to-many.
Consuming from a warehouse the goods have already left. If the commissary physically dispatched stock to a restaurant, record the transfer; consumption then depletes the restaurant's own store. A sale that reaches back into a remote pool makes two books lie at once — the commissary's book claims stock it no longer holds, and the restaurant holds stock its book has never seen.
Forgetting both stamps on a consumption movement. A consumption movement needs both a warehouse (cost pool / valuation) and a restaurant (profit-and-loss attribution); dropping either breaks one of the two reports.
Letting stock "vanish." Every movement has a real second location. If goods are gone, they went to a named place — a customer, scrap, a stock-loss adjustment — never nowhere.