Multi-Shop

If you run more than one location and want one Mise Manager database to handle all of them, this is for you. If you run a single shop, you can skip this — the "Main" shop you start with covers you.

The mental model

Catalog is shared. Pricing, inventory, sales, and money tracking are per-shop.

You define a menu item (e.g. "Pork Adobo") once. Both shops see the same item, the same recipe, the same ingredient list. But each shop independently:

• Buys ingredients at its own prices, from its own (or shared) suppliers
• Holds its own inventory
• Logs its own sales
• Has its own rent, utilities, payroll
• Can set its own target food-cost %
• Sees its own dashboard numbers

The cost engine recomputes per shop. Change a price in Manila → Manila's recipe and menu costs recompute; Provincia's are untouched.

What's shared, in detail

Table	Shared?	Notes
suppliers	shared	Same vendor directory for all shops; their prices are per-shop
items (catalog: name, type, base unit, selling price, photo)	shared	Same item ID seen by all shops
recipes + recipe_lines	shared	One definition; cost numbers underneath are per-shop
processing + processing_outputs	shared	Same yield templates everywhere
unit_conversions	shared
supplier_items (pricing)	per-shop	Each shop attaches its own pricing rows; each shop has its own default supplier per item
price_history	per-shop	Tracks per-shop price changes
shop_menu_settings (target_cost_pct)	per-shop	A chain might run different targets per location
shop_item_costs (cached)	per-shop	The cost cache for each shop
inventory + inventory_moves	per-shop
sales_entries	per-shop
par_stock	per-shop
expenses (including payroll)	per-shop
production_runs	per-shop	Production events happen at one shop

Important corollary: selling_price is currently shared (sits on the items catalog). If you want to price the same menu item differently per shop, file that as a feature request — it would move selling_price to per-shop similar to how target_cost_pct is. For most chains, prices match across locations; if yours don't, let us know.

When to add a second shop

Add a shop when you need to track its operations independently. Common cases:

• Second branch / location
• Catering arm (separate kitchen, separate inventory)
• Commissary that supplies multiple outlets (tracks its own costing, then exports finished items as "RAW" inputs to retail shops — see advanced patterns below)
• Demo / testing shop where you try recipes before pushing prices

Don't add a shop just to separate menus. The same shop can serve breakfast and dinner menus, lunch combos and à la carte — they're all just menu items with their own recipes.

How to add a shop

1. Sidebar → Shops → New shop
2. Name (e.g. "Tapsi Joint - BGC") + location (optional)
3. Save
4. Top of sidebar — switch the dropdown to the new shop

The new shop starts with:

• Full access to the shared catalog (you see all items, recipes, processings)
• Zero pricing (every cost shows ₱0.00 until you attach suppliers)
• Zero inventory (no on-hand, no par stock)
• Zero sales
• Zero expenses
• Zero target food-cost % settings (target column blank in Items)

First-time setup of a new shop

To get the new shop operational:

1. Items tab: for each RAW item the shop uses, click in → Attach supplier with the new shop's pricing. Use the same supplier as another shop if your vendor is the same; the pricing row is per-shop regardless.
2. Items tab → MENU items: edit each menu item → set this shop's target food cost %. (Selling price is shared; only target % is per-shop.)
3. Inventory tab: receive your opening inventory using Receive actions.
4. Expenses + Payroll tabs: log this shop's rent, utilities, recurring salaries.
5. Sales: start logging sales.

After a few days of sales, the Dashboard for this shop will populate.

Switching shops

The dropdown at the top of the sidebar. Every per-shop page reloads to reflect the selected shop.

The catalog pages (Suppliers, Items, Recipes, Processing) also reload — same definitions, but the cost and target columns you see are resolved for the selected shop.

The selected shop is remembered across app restarts (stored in browser localStorage).

Deleting a shop

Sidebar → Shops → trash icon on a row

Confirmation modal makes the consequences explicit: wipes that shop's prices, inventory, sales, par stock, target settings, payroll, expenses. The shared catalog is untouched and stays available to remaining shops.

You cannot delete the last remaining shop. If you want to "reset" the only shop, delete its data manually instead (clear out supplier_items, inventory, sales via the relevant tabs).

Pricing differences across shops — common patterns

Same supplier, different prices (most common): Manila buys 2 kg for ₱600, Provincia buys 2 kg for ₱500 from the same vendor due to location. Attach the supplier in both shops, just with different prices. The vendor row in suppliers is shared; the pricing rows are separate per shop.

Different suppliers: Manila buys from Magnolia, Provincia from a local market. Attach Magnolia in Manila; attach "Provincia Market" (also defined in shared suppliers) only in Provincia.

One shop uses a substitute ingredient: this becomes a different item, not a different price. Create both "Beef tenderloin" and "Carabeef tenderloin" as RAW items. Each shop's recipe uses whichever applies. (If both shops have the same recipe but use different substitutes, you'd either have two recipes for two menu items, or just accept that "this shop substitutes when needed" and document it as a note.)

Reporting across shops

Currently the Dashboard reports on one shop at a time — the selected one. There's no roll-up view across all shops yet. If you want cross-shop totals (chain-wide P&L, chain-wide inventory value), file as a feature request — it's a Phase 11+ candidate.

For now: export each shop's data to PDF / screenshot the Dashboard for each, and combine externally.

Multiple computers in the same shop

Not supported as a live multi-user setup. Mise Manager is single-user-at-a-time. See Backup and Data → Multi-machine considerations for why and what the workarounds are.

Advanced: commissary pattern

If you have a central commissary that produces components and supplies retail outlets:

Approach A (single-DB): model the commissary as a shop. Its PROCESSED outputs and SUBRECIPE items exist in the shared catalog. The retail shops use those items in their recipes; the costs roll up. But: there's no automatic "transfer stock from commissary to retail" — you'd manually deduct from commissary inventory and add to retail inventory.

Approach B (separate-DBs): commissary runs its own copy of Mise Manager, retail outlets run theirs. They sync only the catalog (export commissary's items + recipes data and reimport on retail machines as updates). This is more bookkeeping but cleaner separation.

Approach A is what the current app supports natively. If you have a real commissary use case, talk to us — there are improvements we can make (like an "inter-shop transfer" inventory move type) that would make Approach A first-class.