> ## Documentation Index > Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # How to run stock across several locations > Put stock at a location, read per-location levels, and understand what location decides when an order arrives. inventory/stock-items Every stock item lives at exactly one location. That single fact drives more behaviour than it looks like it should: it decides what you see in the admin, what customers can book, and which unit gets picked when an order arrives. This guide is about running stock that already sits where it belongs. Moving units between locations is a separate thing, and one TWICE does not do yet — see the note at the end. ## Prerequisites **Required permissions:** `inventory:stock_item:view` to read, `inventory:stock_item:manage` to change a unit's location. All four system roles hold both. **Know which location you are looking at.** Almost everything in the inventory admin is scoped to the location selection in the top bar, and it is the single most common reason stock "disappears". If your account has more than one active location, check the selector before concluding anything. ## The Walkthrough A unit's location is set when you register it, in the **Entry Location** field. It defaults to the location you currently have selected, which is usually right and occasionally very wrong — registering a delivery while scoped to head office puts the stock at head office. To move a unit afterwards, change the location on the item itself. The location selector in the top bar drives the inventory views. It has two modes: * **One location** — every list, table, and timeline shows only that location's stock. * **All locations** — everything, with your default location's stock ordered first. Your choice persists between sessions, so the scope you left yesterday is the scope you return to. If the account has exactly one **active** location, "all locations" and that location are the same thing, and TWICE collapses them. The distinction only starts to matter once a second location is active. With **all locations** selected, the inventory table's location column is what turns a flat list into a per-location view. Group by it to get counts per location; filter by it to isolate one. That combination answers the questions worth asking across a fleet — where the shortage is, which location is carrying stock it never rents, whether a SKU is spread thin everywhere instead of being usable anywhere. Location is not just an admin filter. It participates in whether a customer can book at all, and a listing can be refused at one location while selling fine at another with the same stock on the shelf. The full set of checks is in [Check availability](/docs/guides/inventory/check-availability) — worth reading before you conclude that stock at the wrong location is a stock problem. Two location settings decide how an order is served. **The default location** is the account's fallback — the one flagged as default. It seeds your scope when nothing else is selected, and it is what new registrations default their Entry Location to. **Use auto assign** is per-location, on the location's fulfilment settings, and on by default. With it on, an item on an order is picked and held for you automatically, and reads as **Assigned** — *item is assigned to order, can be replaced*. With it off, the item stays **Unassigned** — *item is not assigned to order* — and someone chooses the unit by hand. Turning it off is a deliberate choice for operations where a person decides which unit goes out: graded stock, units on different service intervals, anything where the units are not interchangeable. ## How do I know it worked? * **A unit's location is on its record**, and it is the location you expect rather than the one you were scoped to when you registered it. * **Grouping the inventory table by location gives per-location counts** that match what is physically on each site. * **Switching the selector changes what you see** — if it does not, you have one active location and the selector is collapsed. * **An order at a location with auto-assign on shows items as Assigned** without anyone picking them. ## Troubleshooting / Common Pitfalls **Almost always the location scope.** The table shows the selected location. A unit at another location is not missing, it is out of scope. **What to do:** switch to all locations and look again. This is worth making a reflex before investigating anything else — it is also why an item's Events tab can look empty when the unit has a full history at a location you are not viewing. **Cause:** **Entry Location** defaults to your current scope, not to where the stock physically arrived. Register a delivery while scoped to another site and the stock lands there. **What to do:** change the location on the affected items — bulk edit if it was a whole batch. Then make selecting the right location the first step of any intake routine, before opening the register dialog. **Expected, and usually not about stock.** A listing has to be active, available at that location, and the location has to offer the right fulfilment for the purchase type. Failing any of those makes it unavailable there while the stock sits visible. **What to do:** work the checks in [Check availability](/docs/guides/inventory/check-availability). Fulfilment configured per purchase type is the one that catches people. **Cause:** the order is being fulfilled from the location it was placed at, using that location's auto-assign setting. Stock at another location is not a candidate. **What to do:** check the order's location before checking the stock. If a location genuinely cannot serve its own demand, that is a stock distribution problem, and today it is solved by receiving stock at the right location rather than by moving it — see below. **Cause:** you are on all locations, or the account has one active location and the selector has collapsed. **What to do:** check the selector. If a second location exists but is not active, activating it is what makes the distinction start to apply. **Not available yet.** Inventory transfers are not in production, so there is no move operation. **What to do today:** change the unit's location on the record to reflect where it physically is. That updates the record but does not produce a transfer, a movement history, or anything for the receiving location to check in. Do it when the stock has actually moved, not as a way of planning a move. Some published pages describe transfers as a shipped flow. They are ahead of the product — treat this as the current behaviour. ## Next Steps The full set of checks behind "available at this location". What a location is, and its fulfilment rules. Correcting the location on a whole batch at once. Where Entry Location is first set.